Hello everyone,

In this thread, I plan to share results from our testing lab for Hetman RAID Recovery and Hetman Partition Recovery.

We test the software with different RAID configurations, NAS devices, storage controllers, file systems, virtual disks, encryption, disk images, and various data loss scenarios.

I would be interested in feedback from HDDGuru members, especially from people who work with data recovery in practice.

Please feel free to comment on the tests themselves. If you think the methodology is weak, an important scenario is missing, or the test does not reflect a realistic recovery case, I would like to hear it.

You can also suggest:

RAID, NAS, or controller configurations to test;

file systems or encryption technologies;

damaged or incomplete RAID scenarios;

virtual disks and VM storage;

forensic image formats;

other recovery cases that would be useful to reproduce.

If there is functionality you would like to see in Hetman RAID Recovery or Hetman Partition Recovery, you are also welcome to describe it here. We can review such requests and, where they make sense, consider them for future versions.

I will use this thread to post test results, technical notes, screenshots, and related videos.

Feedback and criticism are welcome.

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

We heard you the first time, after 4 posts it's beginning to feel like spam again.

_________________
Data Recovery Services in the UK.
https://www.usbrecovery.co.uk/

In the latest version, we added support for VeraCrypt containers and encrypted partitions, including both standard and hidden volumes. Hetman Partition Recovery can unlock VeraCrypt volumes using a password, PIM, keyfile, or their combination, and then analyze the decrypted filesystem for existing and deleted files.

In this test video: https://www.youtube.com/watch?v=NlgMI807V2I

we covered three scenarios:

a VeraCrypt container protected with a password, PIM, and keyfile, with some test files deleted before recovery;

a USB drive containing a standard VeraCrypt volume and a hidden volume, both password-protected;

the same USB drive after its partition information was removed with the clean command in DiskPart.

In all three cases, the volumes were unlocked and their contents were accessible for analysis and recovery.

If you work with VeraCrypt in practice, please share the scenarios or features you would like us to support — we can review them for future versions.

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Michael; your spamming now - a single thread can suffice.

One area we have been working on in Hetman RAID Recovery is support for RAID controller metadata. When supported metadata is present on the member disks, the software reads it and reconstructs the array automatically, so it is available for further analysis. In recent versions, we added support for Infortrend EonStor DS 1000 / ESDS 1012 RC metadata used in Infortrend storage systems.

In this test:
https://www.youtube.com/watch?v=tSKfPN-k2Ho

we covered:

• automatic RAID detection and manual reconstruction with RAID Constructor;
• the main parameters required for manual reconstruction;
• Thin and Thick volumes and SANWatch snapshots;
• recovery after deleting files or partitions inside an iSCSI LUN;
• recovery after removing Thin/Thick volumes in SANWatch;
• recovery of files from a SANWatch snapshot.

We have also tested RAID metadata from a number of other hardware and motherboard controllers:
Dell: PERC 6/i, H310, H700
LSI / 3ware: 3081E-R, MegaRAID SAS 84016E, 9280-4i4e, 9265-8i, 3ware 9750, 9650SE-4LPML
Adaptec: ASR-6405, ASR-6805T
Areca: ARC-1210, ARC-1260
HP/HPE Smart Array: P410/P410i, P822
IBM: ServeRAID M5016
Fujitsu: D3116, D2516-C11 GS1
Supermicro: AOC-USAS-S8iR
Dawicontrol: DC-624E
InLine: 76696C
AMD: RAIDXpert2
Intel: Rapid Storage Technology
Infortrend: EonStor DS 1000 / ESDS 1012 RC

The corresponding tests on our YouTube channel also contain practical information that can be useful for manual reconstruction, including disk order, stripe/block size, block/parity order, byte order, and disk offset.

If there is a controller or metadata format that you regularly encounter in real recovery cases and would like us to test, please suggest it.


WebClaw, Lardman,

Understood. The purpose of this new thread is exactly to keep all future Hetman Software tests and related technical updates in one place. I’ll contact the forum administrator and ask to have the other Hetman-created threads in this section removed, so that going forward I will use only this thread for our tests and updates.

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Another area we are working on is support for different disk image formats.

Forensic images. Recent versions added support for EnCase / EWF (.e01, .s01, .ex01), AFF (.aff, .afm, .afd), AFF4 (.aff4), and AFF4 Directory Volumes. Single-file, split/multi-segment and compressed images are supported where applicable.

In this test:
https://www.youtube.com/watch?v=UlN933-iRLA

we created forensic images of a USB drive with Exterro FTK Imager. The drive contained a prepared test dataset, with some files deleted before imaging. We then mounted the resulting images and tested recovery of both existing and deleted files.

Apple disk images. We also added support for .dmg (UDRO, UDRW, UDZO, UDBZ, ULFO, ULMO, UDSP, UDSB), .asif, .sparsebundle, .sparseimage, .cdr, .toast and .iso. Regular, split, sparse, compressed and encrypted images are supported where applicable.

In this test:
https://www.youtube.com/watch?v=jhkg52Tx2bY

we mounted several image types, scanned their filesystems and recovered files from them.

Support for .sparsebundle is also useful when working with Time Machine backups stored on devices such as Time Capsule, NAS systems or network storage. Another practical case is a partially damaged image that can no longer be mounted by its original software or operating system. In such cases, the image can still be opened and scanned to determine whether part of the filesystem and files can be recovered.

Raw / sector-by-sector images. The software can create a sector-by-sector image of an entire disk, a partition, or a selected range defined by starting sector and size. It can also work with raw byte-for-byte images created by other tools, including GNU ddrescue, FTK Imager, PC-3000 Data Extractor, Guymager and X-Ways Imager. This is particularly useful when repeated access to the original media should be avoided, for example when a drive has bad sectors or behaves unstably. Once mounted, an image is handled much like a physical disk: it can be scanned for existing and deleted files, encrypted volumes can be unlocked, and supported encrypted files can be processed. If RAID metadata is present, it can also be used to reconstruct the array. Physical disks and disk images can be combined when working with RAID arrays or storage pools.

I would be particularly interested in feedback from people working in digital forensics: which image formats, metadata, validation features or forensic workflows are still missing for your day-to-day work?

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Another area we are working on is support for virtual machine disks and snapshot chains.

Hetman Partition Recovery and Hetman RAID Recovery can mount either an individual virtual disk file or an entire virtual machine folder. In the latter case, the software analyzes the VM structure, identifies base disks, differencing/overlay files, snapshots, and the relationships between them.

Supported layouts include fixed/thick, dynamically allocated/thin/sparse, split/multi-part and differencing disks, as well as internal and external snapshots and multi-level snapshot chains.

Main platforms and formats

• VMware Workstation / Fusion / ESXi / vSphere — VMDK, including flat, sparse, split and snapshot/delta disks
• Microsoft Hyper-V — VHD, VHDX, AVHD, AVHDX
• Oracle VirtualBox — VDI, VMDK, VHD and differencing images
• Parallels — HDD, HDS
• QEMU / KVM — QCOW, QCOW2, RAW, IMG
• Proxmox VE — QCOW2, RAW, VMDK and other supported storage types
• XenServer — VHD and RAW disks
• VMware ESXi / VMFS — VMFS datastores and virtual disks stored inside them

For snapshot chains, the software determines parent-child relationships, finds the base disk and reconstructs the available disk states. For example, this may be a base VMDK plus delta VMDKs in VMware, VHDX plus AVHDX in Hyper-V, or a base QCOW2 plus external overlay files in QEMU/KVM. Each reconstructed state can then be analyzed as a regular disk for partitions, file systems, existing files and deleted data.

Example: Proxmox VE
In this test: https://www.youtube.com/watch?v=DYHb8K775yE

we created a Windows 10 virtual machine in Proxmox VE and attached disks in RAW, VMDK and QCOW2 formats. Test files were copied to the disks and some of them were deleted.

We then demonstrated:

• recovering the virtual disk files from an EXT4 storage volume
• mounting the recovered RAW, VMDK and QCOW2 disks
• analyzing the file systems inside the VM disks
• recovering both existing and deleted files

We also tested a scenario where the virtual disk files themselves had been deleted. The VM disk files were first recovered from EXT4, then mounted and analyzed for the data stored inside the guest system.


Example: Unraid and snapshot chains
In this test: https://www.youtube.com/watch?v=JyDpjjelim0

we created a virtual machine in Unraid on an XFS storage volume and attached RAW, IMG and QCOW2 disks. After writing test files to the disks, we created external snapshots and then deleted part of the data inside the guest system.

After recovering and mounting the VM folder, the software automatically identified the base disks and their related snapshot/overlay files. For the disks, both the state before the snapshot and the current state with the snapshot changes applied became available for separate analysis. Both states could be scanned for existing and deleted files.

We also tested a different case where the virtual disk files had been completely deleted from XFS. Instead of recovering the VM disk as an XFS file, a full scan of the physical storage detected the NTFS filesystem of the guest Windows system directly in the sectors that previously belonged to the virtual disk.

So there are two possible recovery paths:
Host filesystem -> recover VM disk file -> mount VM disk -> recover guest files

or, when the VM disk file itself cannot be recovered:
Host storage -> detect guest filesystem directly -> recover guest files

Another practical case is a partially damaged VMDK, VHDX, VDI or QCOW2 file that can no longer be opened by the original hypervisor. If enough of the disk structure remains readable, it may still be possible to mount and scan it without starting the virtual machine.

I would be interested to hear from people who deal with VM recovery in practice: which formats, snapshot chains, damaged-disk scenarios or unusual configurations would be useful to add to our future tests?

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Another area we are working on is support for physical NAS, DAS and SAN storage systems in Hetman RAID Recovery. For these systems, we have implemented support not only for RAID reconstruction itself, but also for the storage layers that may exist above it:

physical disks -> RAID -> volume management -> filesystem / LUN -> data

Depending on the storage architecture, snapshots may exist at the filesystem, volume or storage-pool level. The software can read RAID metadata directly from member disks or their images and reconstruct the array automatically. If the RAID metadata is damaged or unavailable, the array can also be reconstructed manually by specifying disk order, stripe size, offsets, parity layout and other parameters.


NAS

For NAS systems, we have implemented support for common Linux-based storage stacks, including Linux MD (mdadm), LVM, Ext2 / Ext3 / Ext4, XFS, Btrfs and ZFS. Vendor-specific RAID layouts are also supported, including:

• Synology SHR-1 / SHR-2
• NETGEAR X-RAID / X-RAID2

The software also handles multi-device storage configurations such as Btrfs and ZFS pools, mirrors and RAIDZ. For Btrfs and ZFS, the software can also work with snapshots. After RAID reconstruction, Hetman RAID Recovery can continue through the higher storage layers, depending on the layout: partition tables, LVM, filesystems, snapshots and LUNs.

Example: Synology SHR-2 and LUN recovery

In this test:
https://www.youtube.com/watch?v=NZP2e7991t0

we demonstrated automatic SHR-2 reconstruction from the member disks and also examined the standard parameters required to reconstruct the same array manually. We also tested recovery of a deleted LUN file. After the LUN was recovered, it was mounted in the software as a separate block-level source, analyzed, and the files stored inside it were recovered. In this particular test, the recovery path contained several storage layers:

SHR-2 -> filesystem -> LUN -> filesystem inside LUN -> files

NAS devices used in our tests:

• Synology: DS409, CS407, DS415+, DS418play, DS2422+
• QNAP: TS-412, TS-219P+, TS-439U-RP/SP
• NETGEAR: ReadyNAS, ReadyNAS Duo RND2000
• Buffalo: LS-WXL236, TS5400D, WS-6V12TL/R5, HD-H1.0TGLR5
• Thecus: N4100Pro, N7700Pro
• D-Link: DNS-343
• ZyXEL: NAS542
• Western Digital: ShareSpace WDA4NC40000, My Cloud Mirror
• Seagate: BlackArmor 440/420
• Promise: SmartStor NS4300N
• Iomega: IX4-200D
• Linksys: NSS4000
• Cisco: NSS3000
• Intel: Entry Storage System SS4000-E
• Plextor: XStore PX-NAS2X500L / PX-NAS2X750L / PX-NAS2X1000L
• Dane-Elec: My-Ditto
• TERRA: NASBOX 5G2
• LaCie: 5big Network 2

Across these systems, our tests covered RAID metadata detection, reconstruction of standard and vendor-specific RAID layouts, filesystem analysis and recovery after failure of the original NAS hardware.

DAS / external RAID storage

For DAS systems, Hetman RAID Recovery can reconstruct an array from directly accessible member disks or their images without relying on the original enclosure. Devices used in our tests include:

• Oyen Digital Mobius 5 / 3R5-EB3-M
• MicroNet Platinum FireWire800

For Oyen Digital, we also tested manual RAID 5 reconstruction from the member disks. With MicroNet Platinum FireWire800, we tested RAID 5 analysis and data recovery after loss of access to the array.

SAN

For SAN storage, Hetman RAID Recovery can also work with logical block storage presented above the underlying RAID, including LUNs. In our hardware tests, one such system was D-Link DSN-1100 with RAID 5. The software can reconstruct the underlying RAID and then continue with analysis of the block storage and filesystem inside the LUN.

I would be interested to hear from people who work with NAS, DAS or SAN recovery in practice: which vendor-specific metadata, storage layers, LUN structures or unusual RAID layouts would be useful for us to add to future tests and support?

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Another area we have been working on is support for encrypted volumes and encrypted files in Hetman Partition Recovery.

Encryption may exist at different levels of a storage structure. It may protect an entire volume, or only individual files and directories.

Hetman Partition Recovery handles both cases:

physical disk / disk image / virtual disk -> encrypted volume -> filesystem -> data

or

physical disk / disk image / virtual disk -> filesystem -> encrypted files / directories -> data

With valid credentials, the software can unlock supported encrypted volumes and continue filesystem analysis, including existing and recoverable deleted data.

At the volume level, we currently support BitLocker, LUKS and VeraCrypt. At the file and directory level, we support Windows EFS and Linux fscrypt.


BitLocker

https://www.youtube.com/watch?v=CbMA34Zr0ak

In this test, we worked with BitLocker encryption on a Windows system drive, an additional HDD and a BitLocker To Go USB drive. We tested access to encrypted storage and recovery after file deletion, formatting and filesystem corruption.


LUKS

https://www.youtube.com/watch?v=8CnT2iARsGE

In our LUKS tests, we covered LUKS1 and LUKS2 volumes containing Ext4, Btrfs and XFS filesystems, unlocking with a password or keyfile, LUKS container files, and detection of an encrypted volume after its partition entry had been deleted.


Windows EFS

https://www.youtube.com/watch?v=8-E0E0V7A_8

Unlike BitLocker, EFS encrypts individual files and directories on NTFS rather than the complete volume.

We tested detection and recovery of existing and deleted EFS-protected files after deletion, formatting, partition loss and NTFS corruption.

When the corresponding certificate and private key are available, Hetman Partition Recovery can decrypt the recovered files. In this test, the certificate and private key were supplied in a PFX file.


Linux fscrypt

https://www.youtube.com/watch?v=sDJd8C4E72k

fscrypt provides file and directory encryption at the filesystem level rather than encrypting the complete block device.

For this test, we used an Ext4 filesystem on a USB drive. We tested recovery after deleting files from an fscrypt-protected directory and after deleting the entire Ext4 partition containing that directory.

Hetman Partition Recovery detected the available filesystem structures and fscrypt-protected data. With valid credentials, both existing and recoverable deleted files could be accessed.

Filesystem metadata that is not protected by fscrypt can still be analyzed during recovery, helping the software identify encrypted objects and reconstruct the filesystem structures that remain available.


Valid credentials are still required

Recovery and decryption are separate tasks.

Hetman Partition Recovery can locate lost encrypted volumes, deleted partitions and encrypted files, reconstruct the available filesystem structure, and recover data whose contents have not been overwritten.

However, decryption still requires the correct password, recovery key, encryption key, certificate/private key, keyfile or other valid credentials.

The software is designed for recovery from encrypted storage, not for cracking or bypassing encryption.

I would be interested to hear from people who work with encrypted storage in real recovery cases: which encryption/filesystem combinations or failure scenarios involving encrypted storage would be useful for us to test next?

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/

Another area we have been working on in Hetman RAID Recovery is support for software NAS platforms that can turn an ordinary PC or server into network-attached storage. In an earlier post, I described our work with physical NAS, DAS and SAN systems. This time I would like to focus on platforms where the storage architecture is defined mainly by the operating system and the storage technologies it uses rather than by a specific NAS controller.

From a recovery perspective, these systems are quite different. TrueNAS is built around ZFS, OpenMediaVault commonly uses Linux MD/mdadm for software RAID, Rockstor is based on multi-device Btrfs, while Unraid uses its own architecture with independent data disks and parity.


TrueNAS

TrueNAS uses ZFS as its primary storage technology. In this test, we worked with RAIDZ1, RAIDZ2, RAIDZ3 and Stripe, automatic ZFS pool reconstruction, missing drives and deleted data:

https://www.youtube.com/watch?v=x39jwpLwe4o

In another test, we focused on higher-level ZFS objects, including Datasets, ZVOLs and Snapshots, as well as virtual disks stored inside a ZFS pool:

https://www.youtube.com/watch?v=vMw3zFfzBwQ

A ZVOL is a block device provided by ZFS, while datasets provide filesystem-level storage. Snapshots can be associated with these ZFS objects and represent another source of recoverable data. For recovery, this means that reconstructing the RAIDZ layout is only one part of the task. The software also has to recognize the ZFS pool and the objects stored inside it.

A simplified view is:

physical disks -> ZFS pool / RAIDZ -> datasets or ZVOLs -> data

with snapshots associated with the corresponding ZFS objects.


OpenMediaVault

In this test with OpenMediaVault 8.2.8, we worked with mdadm RAID 0, RAID 5 and RAID 6:

https://www.youtube.com/watch?v=xz3rfgPD2J4

Hetman RAID Recovery reads Linux MD metadata from the member disks and can use it to reconstruct the array automatically. We also tested manual RAID reconstruction for cases where the available metadata is incomplete or the array parameters need to be specified manually. After the MD array has been reconstructed, the software can continue analyzing the storage layers above it, such as partitions, volume structures and filesystems.

A simplified structure is:

physical disks -> Linux MD/mdadm RAID -> volume/filesystem -> data


Rockstor

Rockstor takes a different approach. Its storage is built around Btrfs, where filesystem and multi-device storage management are closely integrated. In this test with Rockstor 5.1, we worked with Btrfs RAID 0, RAID 5 and RAID 6 profiles:

https://www.youtube.com/watch?v=MN2dgOMJ3IY

Hetman RAID Recovery automatically detected the multi-device Btrfs layout. We also tested recovery from Btrfs snapshots and analysis after deletion of a Btrfs pool. Unlike a traditional mdadm-based stack, there is no mandatory separate RAID layer here. Information about how data is distributed across the devices is part of Btrfs itself.

A simplified structure is:

physical disks -> Btrfs multi-device filesystem -> subvolumes / snapshots -> data


Unraid

Unraid uses a substantially different storage model. Unlike traditional striped RAID, complete files are stored on individual data disks, while one or two dedicated parity disks provide protection against disk failure. In this test, we worked with Unraid Single Parity and Dual Parity:

https://www.youtube.com/watch?v=hkCEM_dciYY

Hetman RAID Recovery can analyze the available XFS data disks individually, determine the original disk order and filesystem offset, and virtually reconstruct missing data using parity information. In our tests, we reconstructed one missing data disk in a Single Parity array and two missing data disks in a Dual Parity array. For this reason, an Unraid array should not be treated simply as another variation of RAID 5 or RAID 6.

A simplified view is:

independent data disks + parity disk(s) -> individual filesystems -> data

For Hetman RAID Recovery, supporting these platforms is therefore not just a matter of reading a particular filesystem. The software has to understand the relationship between physical disks, RAID or pool metadata, volume structures, filesystems, snapshots and block-level objects, and reconstruct the available storage layers before filesystem recovery can begin.

I would be interested to hear from people who work with software NAS systems in real recovery cases: which platforms or storage layouts would be useful for us to test next - complex ZFS pools, Btrfs configurations with missing devices, mdadm/LVM stacks, unusual Unraid arrays, or other NAS operating systems?

_________________
Michael Miroshnichenko — Data Recovery Software Developer at Hetman Software
RAID • NAS • File Systems • Virtual Disks • https://hetmanrecovery.com/