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.