Hardware and RAID configuration
A RAID was configured with 4 drives.
The volume could not mount.
- 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.
- 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.
- 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.