Hardware and RAID configuration

A RAID was configured with 4 drives.

Problem:

The volume could not mount.

Diagnosis:

• The RAID configuration is quickly determined, thanks to the data patterns on the drives.
• The trace found the main Ext volume's superblock and all of its backup ones. However, they are very close to each other. This is a hint that some kind of virtualization method has been implemented.
• The LVM configuration file was found and parsed. It shows that the largest logical volume is thinly provisioned (in LVM technical terms, it's called "thin-pool").
• The LVM also stores details about the volume's metadata, which works like a mapping table of the main volume. This is crucial to the success of the recovery. The table maps all virtual chunks to the logical ones.

Solution:

• Using the LVM configuration file, the metadata is located and parsed. It is a b-tree. The tree maps the device to the device chunks and finally to the data ones.
• The metadata parser starts at the superblock (found at offset 0). Then it goes down to the root (data_mapping_root) of the b-tree and further down to the internal nodes and finally to the leaf nodes, where the actual mapping is stored.
• The mapping data is then converted to File Scavenger®'s RAID schema file. This great feature of File Scavenger® helps to define virtually any kind of RAID or Spanned volume.
• With this schema file loaded, File Scavenger® can scan the RAID (with thin-provision mapping) with ease as if it is a single drive.

Result:

• It is a complete recovery. Only symbolic link files are skipped, because they are not supported in Windows.
• Over 1 TB of data is restored. The folder structure is also reconstructed.