Recovery methodsTechnical

Understanding Storage Layers Before Recovery

A storage system rarely consists of “a disk and some files.” Modern data may pass through several mapping layers before an application sees it. Recovery becomes much more reliable when those layers are identified first and reconstructed from the bottom up instead of scanning the wrong representation as if it were a flat disk.

The same sectors can mean different things at different layers

A physical disk exposes sectors. A RAID controller may combine sectors from several disks into one virtual address space. A storage pool can remap that space again; encryption transforms its contents; a partition defines a region; a file system maps files to extents; a virtual disk can contain another partition table and another file system. Each layer interprets the output of the layer below it.

This is why seeing recognizable bytes is not enough. Data can be physically present while remaining meaningless until the mapping that gives those bytes their logical addresses is restored.

A practical storage stack

Typical dependency chain

Physical device(s) → RAID/storage mapping → pool or volume manager → encryption → partition/container → file system → virtual disk or database → application data

Not every system contains every layer, and some layers can appear more than once. A virtual machine, for example, may live on a host file system while its virtual disk contains its own partition table, encryption and guest file system. A NAS may place a file system on top of RAID and LVM, while also exposing snapshots or iSCSI LUNs above it.

Why recovery usually proceeds from lower layers upward

If a RAID layout is wrong, the file system assembled from it may contain convincing directory structures mixed with corrupt data. If an encrypted layer is skipped, scanning ciphertext for file signatures is generally meaningless. If a thin-provisioning map is missing, physical offsets do not necessarily correspond to logical offsets in the LUN.

The useful rule is not “always recover the lowest possible layer.” It is: start with the lowest layer that is damaged or uncertain, preserve it, and reconstruct enough of it to obtain a trustworthy representation of the next layer.

What to identify before scanning

What is the source? A physical device, member disk, disk image, logical LUN, virtual disk, exported volume or something else?
What capacity should it have? Unexpected capacity can invalidate every higher-level offset.
Is there RAID, pooling or virtualization underneath? Member disks should not automatically be scanned as independent file systems.
Is encryption present? Determine where encryption sits in the stack and preserve the keys, metadata and credentials needed to open it.
Which layer still parses correctly? A valid partition table does not prove that the file system is healthy; a valid file system does not prove that application data is consistent.

Choosing the correct recovery source

The original physical device is not always the object that recovery software should scan. After safe acquisition, the correct source might be a disk image, a reconstructed virtual RAID, an assembled storage pool, a decrypted volume, a virtual disk extracted from a host file system or a point-in-time snapshot.

Scanning too low can discard mappings and mix unrelated extents. Scanning too high can hide the layer that actually failed. When possible, keep the lower-level acquisitions so that the reconstruction can be revised without returning to the original media.

Examples where the layer changes the answer

RAID: scanning one member can produce fragments, but not the logical array address space.
NAS: vendor partitions may be visible on each disk while user data belongs to a RAID/LVM/Btrfs/ZFS layer above them.
SAN: physical pool data, a thin LUN and the host file system are different recovery sources.
Virtual machines: host storage can be intact while a snapshot chain is broken, or the VM container can be intact while the guest file system is damaged.
Encryption: file-system metadata may only become interpretable after the encryption layer is correctly opened.

When raw recovery is appropriate

Raw carving deliberately ignores much of this structure. That can be useful when higher-level metadata is destroyed, but it should normally be a fallback rather than the first way to flatten a layered system. Carving cannot recreate RAID geometry, encryption keys, thin-allocation maps, filenames or fragmented-file extent maps that were never reconstructed.

A safer decision rule

Preserve first, flatten last

Before scanning a complex source, draw the storage stack you believe exists. Mark which layers are confirmed, which are uncertain and which have failed. Acquire unstable physical sources first; then reconstruct the lowest uncertain mapping and validate it before moving upward.