With fscrypt, there is another layer to consider. The surviving blocks may still contain the file data, but that data is encrypted. The original filename may also be encrypted. A useful recovery workflow therefore has to solve two different problems:

1. reconstruct the deleted filesystem objects;

2. obtain the fscrypt key material required to turn the recovered ciphertext back into usable files.

This makes fscrypt recovery fundamentally different from recovering ordinary deleted files from EXT4.

Disclosure: I work with Hetman Software. The practical examples below use Hetman Partition Recovery because this test was created to validate our implementation of EXT4 and fscrypt recovery. The goal of this article is to explain the storage and recovery workflow, including its limitations.

What fscrypt changes on EXT4

fscrypt is Linux filesystem-level encryption. It is integrated into supported filesystems such as EXT4 rather than operating as a separate encrypted block-device layer like LUKS.

That distinction matters.

With full-device encryption, the filesystem itself is normally hidden until the encrypted volume is unlocked. With fscrypt, encryption can be applied to selected directory trees while the rest of the filesystem remains accessible.

For a typical fscrypt configuration:

• file contents are encrypted before they are written to storage;

• filenames inside protected directories are encrypted;

• most ordinary filesystem metadata is not encrypted;

• different encrypted directory trees can use different policies and keys.

Modern fscrypt policies support several encryption-mode combinations. A common and recommended pair is AES-256-XTS for file contents and AES-256-CTS-CBC for filenames, although other modes are supported as well.

From a recovery perspective, the important point is that EXT4 metadata can still provide useful structural information even when the file contents themselves are encrypted.

Without the correct key, however, locating a deleted encrypted file and reconstructing its blocks does not mean the plaintext has been recovered.

The recovery model: filesystem first, decryption second

It helps to think about the problem as three layers:

Layer 1 — EXT4 structure

Can the recovery tool still identify the partition, superblock, allocation structures, inodes, directory records, extents, and other useful metadata?

Layer 2 — deleted encrypted objects

Can it reconstruct a deleted file or directory well enough to determine where its encrypted content is stored?

Layer 3 — fscrypt access

Is the required password, protector, raw key, or other fscrypt key material still available?

If layer 1 or 2 is destroyed by overwriting, the encryption key cannot recreate the deleted filesystem metadata.

If layer 3 is unavailable, correctly recovered ciphertext may still be unreadable.

That is why "the sectors are still there" is not enough when filesystem-level encryption is involved.

Test environment

For the lab test, we prepared a USB drive with several EXT4 partitions and focused on two data-loss scenarios.

The first test partition contained an fscrypt-protected directory. We copied a mixed dataset into it and then deleted part of the data.

For the second scenario, we prepared another EXT4 partition with fscrypt-protected data and then deleted the partition itself in Ubuntu.

The recovery phase was performed from Windows. This is useful in a lab because the recovery workstation does not need to mount the original Linux filesystem read/write.

The complete test is shown in this video:

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

Step 1: stop writing to the source device

The most important action after accidental deletion is not a scan. It is preventing additional writes.

Every write to the affected filesystem can reuse blocks that previously belonged to deleted files. On flash storage and SSDs, discard/TRIM and internal garbage collection can make the situation even worse by causing previously freed blocks to become physically unavailable.

For that reason, the safest workflow is:

• disconnect or unmount the affected storage when practical;

• avoid filesystem repair tools before imaging;

• do not reinstall software onto the source device;

• do not save recovered files back to the same storage;

• create a sector-level image and work from the image whenever possible.

Step 2: create a disk image

In this test, we first created an image of the USB drive.

Working from an image has two advantages.

First, the original device remains unchanged while you experiment with different scan settings.

Second, you can repeat the analysis without repeatedly stressing a failing or unstable source drive.

The image itself should always be stored on a different physical disk with enough free space.

After the image was created, it was mounted in the recovery software and appeared as a virtual disk.

Step 3: scan the EXT4 partition

The mounted image preserved the original partition layout, including the EXT4 test volumes.

For the first pass, we used a quick filesystem analysis.

This is a useful starting point when the partition still exists and the EXT4 metadata is mostly intact. The goal is to reconstruct the filesystem using the surviving structural information before resorting to a deeper scan.

When the scanner encountered the fscrypt-protected directory, it requested the credentials needed to unlock the encrypted data.

This is an important distinction: the password is not being "cracked." It is supplied by the user and used to access the corresponding fscrypt key material.

A recovery application should not imply that encryption can be bypassed simply because deleted encrypted blocks were found.

Step 4: inspect deleted files before saving them

After the key was supplied, the recovered directory could be browsed together with the deleted objects found during the scan.

Preview is especially useful here.

A filename alone is not proof that a file was reconstructed correctly. Files can be partially overwritten, fragmented, or associated with stale metadata. Being able to open a document, image, archive, or video before saving it provides a much stronger validation signal.

Only after checking the results should the selected files be copied to another physical disk.

Step 5: what if the whole EXT4 partition was deleted?

Deleting a partition adds another failure layer because the current partition table may no longer describe where the old filesystem begins and ends.

In our second scenario, the EXT4 partition was deleted in Ubuntu, but the previous filesystem structures were still detectable in the image.

The recovery workflow is similar:

1. identify the lost partition or previous filesystem boundaries;

2. analyze the reconstructed EXT4 volume;

3. locate the fscrypt-protected directory;

4. provide the required decryption credentials;

5. inspect and recover the files to another disk.

After unlocking the directory, the recovered folder structure became available again.

When a quick scan is not enough

A quick filesystem analysis works best when enough valid EXT4 metadata survives.

If the partition has been reformatted, heavily damaged, partially overwritten, or its primary metadata is missing, a deeper scan may be required.

A full analysis can search more broadly for previous filesystem structures and file signatures, but there is an important limitation with encrypted data:

content-based carving is much less useful when the file content is encrypted.

A normal JPEG, PDF, ZIP, or SQLite database has recognizable internal signatures and structure. Encrypted blocks are intentionally designed to look like high-entropy data. That means metadata-based reconstruction becomes even more important for fscrypt-protected files.

This is one of the reasons encryption can make deleted-file recovery much more dependent on surviving filesystem metadata.

Cases where recovery may fail

Even with the correct fscrypt password or key, recovery is not guaranteed.

The main failure conditions are straightforward:

The blocks were overwritten.
Once another file reuses the same physical blocks, the previous encrypted content is gone.

Discard/TRIM removed the freed blocks.
On storage where discard is supported and actually executed, deleted data can become unavailable much faster than on a traditional hard drive.

Critical EXT4 metadata was destroyed.
If the inode, extent information, directory records, or other structural data required to map the encrypted file are gone, reconstructing the original object may be impossible.

The fscrypt key material is unavailable.
Recovering encrypted file blocks without the matching key may preserve the ciphertext, but it does not restore readable plaintext.

The recovered file is only partial.
Large or fragmented files can survive only in part if some of their extents were reused.

fscrypt is not the same as LUKS

This distinction is worth emphasizing because it affects both incident response and recovery.

With LUKS, encryption operates below the filesystem. You normally unlock the encrypted block device first, and only then does EXT4 become visible.

With fscrypt, EXT4 itself remains the filesystem being analyzed. Encryption applies to selected file and directory contents inside it.

A simplified stack looks like this:

fscrypt on EXT4:

physical storage
└── EXT4 filesystem
    ├── ordinary directory
    └── fscrypt-protected directory
        ├── encrypted filename
        └── encrypted file contents

Compared with LUKS:

LUKS + EXT4:

physical storage
└── LUKS encrypted block device
    └── EXT4 filesystem
        └── files and directories

Those are different recovery problems, even if both ultimately involve an EXT4 filesystem.

Practical takeaways

The test confirmed several points that are useful beyond any single recovery tool.

The first is that filesystem-level encryption does not automatically eliminate the value of filesystem metadata. With fscrypt, much of the EXT4 structure remains outside the encrypted file contents, and that structure can be useful when reconstructing deleted objects.

The second is that locating encrypted data and decrypting it are separate stages. A tool may successfully reconstruct an encrypted deleted file while still requiring the legitimate fscrypt credentials before the file becomes usable.

The third is that imaging matters. When deleted encrypted data is involved, every unnecessary write to the source can reduce the amount of metadata and ciphertext that remains recoverable.

Finally, encryption makes metadata preservation more important, not less. Once encrypted content loses the metadata that describes how its blocks belong together, raw signature-based recovery has far less information to work with.

For the complete step-by-step test, additional screenshots, and a more detailed walkthrough, see the original guide.

But creating an image is only the first step.

If files were deleted before acquisition, a partition was damaged, or the filesystem metadata is incomplete, simply opening the image may not expose the data you need. In those cases, the image itself has to be analyzed as a storage device.

In this article, I’ll walk through a practical recovery workflow for three forensic image types you may encounter in real investigations and data recovery work:

• E01 — Expert Witness / EnCase evidence images;

• S01 — SMART / Expert Witness images;

• AFD — the directory-based AFF image variant.

The main goal is not to modify or “repair” the source image. Instead, we mount it, analyze the filesystem and unallocated space, preview recoverable files, and copy the required data to another storage device.

Disclosure: I work with Hetman Software, and the recovery examples below use Hetman Partition Recovery. The focus here is the image-handling and recovery workflow rather than a general product review.

Why a forensic image may still require data recovery

A bitstream forensic image can preserve much more than the files currently visible through the filesystem.

Depending on the format and how the image was acquired, it may also contain:

• deleted files whose clusters have not been overwritten;

• unallocated disk space;

• old filesystem records;

• damaged or partially overwritten metadata;

• lost partitions;

• fragments of files that are no longer referenced by the active directory structure.

This is why mounting an image and browsing its visible filesystem is not always enough.

If the operating system or forensic viewer cannot locate the original file through filesystem metadata, a recovery tool can analyze the image at a lower level and search for both filesystem records and file signatures.

E01, S01, and AFD: what is the difference?

All three formats are designed to preserve storage data for later examination, but their container structures differ.

One detail is worth clarifying: AFD should be understood as the directory-based form of the Advanced Forensic Format family. This is useful when an AFF image needs to be distributed across multiple files instead of being stored as one large .aff file.

Creating the test images in FTK Imager

For the test environment, forensic images can be created with Exterro FTK Imager.

After selecting the physical source device, FTK Imager lets you choose the destination image type.

For an Expert Witness image, select E01:

For a SMART image, select SMART:

For the AFF-based workflow, select AFF. Depending on the implementation and output configuration, AFF data may also be stored as a directory-based AFD image.

During acquisition, case metadata, evidence information, examiner details, destination path, compression, and image segmentation can be configured as required by the workflow.

For actual forensic work, preserve the acquisition logs and hashes together with the image.

Recovery workflow: work from the image, not the original disk

Once the forensic image has been created, the recovery stage should be performed against the image or, for evidence-sensitive work, against a verified working copy of that image.

This reduces the risk of accidental writes to the original storage device.

The workflow is straightforward:

1. attach the forensic image;

2. verify that its partitions are detected correctly;

3. scan the required partition;

4. preview the results;

5. recover files to a different physical storage device.

Let’s go through each stage.

Step 1: Mount the forensic image

In Hetman Partition Recovery, click Mount Disk.

The program groups supported images by type.

For the formats discussed here:

• choose EnCase / EWF images for E01 or S01;

• choose AFF directory images for AFD.

The same dialog also supports several other forensic, virtual-machine, and Apple disk-image formats, which is useful when evidence arrives from different acquisition or virtualization environments.

For a segmented image, start with the first segment or select the corresponding image set as required by the format. The software should treat the segments as one logical storage device.

Step 2: Verify the detected disk and partitions

After mounting, the forensic image appears in the disk list as a separate device.

Before scanning anything, check:

• image size;

• partition layout;

• filesystem type;

• expected volume size;

• whether lost or unallocated areas are present.

In this example, AFD, E01, and S01 test images are mounted at the same time and each exposes the expected NTFS partition.

This verification step matters.

If the image size or partition layout is obviously wrong, scanning immediately may waste time or produce misleading results. First confirm that the correct image, segment set, and partition have been selected.

Step 3: Start with a quick filesystem scan

When the filesystem is still structurally intact, start with Fast Scan.

A quick scan is appropriate when:

• the partition still exists;

• the filesystem is recognized correctly;

• files were deleted but the volume was not reformatted;

• you want to preserve the original directory structure and filenames wherever possible.

Starting with the faster method is useful because deep analysis is not always necessary.

If the required files appear with correct names, paths, sizes, and preview content, there is little reason to run a more expensive scan.

When to use Full Analysis

Use a deeper scan when the simple filesystem pass is not enough.

Typical cases include:

• the partition was formatted;

• filesystem metadata is damaged;

• the partition table was modified or deleted;

• the image contains unallocated regions that need deeper analysis;

• the original directory entries are missing;

• files must be searched by content signatures.

A full analysis may combine filesystem reconstruction with signature-based searching.

That distinction is important.

Filesystem metadata can often restore filenames, paths, timestamps, and fragmented file extents. Signature searching can find data even when those records are gone, but it may lose the original filename and directory structure and may be less reliable for fragmented files.

Step 4: Review and preview the recovered files

After the scan finishes, do not immediately copy every item the software reports.

First review the results.

Deleted files should appear alongside existing data, allowing you to compare their:

• names;

• paths;

• sizes;

• status;

• file type;

• preview.

Preview is particularly useful because a directory entry alone does not prove that the file content is intact.

For example, the filesystem may still contain a deleted filename while some of the clusters previously assigned to that file have already been reused. In that case, the entry may be recoverable but the content may be partially or completely corrupted.

For documents, images, video, archives, and other supported formats, previewing the file before export gives you a much better indication of the real recovery result.

Step 5: Recover to another physical device

Select the required files and click Recovery.

Save the recovered data to another physical disk.

Do not write recovered files:

• back into the source image;

• to the original evidence disk;

• to a storage device that is itself part of the recovery target.

This is standard recovery discipline even outside formal forensic work: avoid writing to the source from which data is still being extracted.

What determines whether a deleted file can actually be recovered?

A forensic image preserves the state of the source at acquisition time.

That means the most important question is not whether the file was deleted, but whether its content still existed when the image was created.

Recovery chances are generally better when:

• imaging was performed soon after the loss;

• the source disk was not actively used after deletion;

• the deleted clusters were not overwritten;

• filesystem metadata still references the original file extents;

• the file was not heavily fragmented;

• the image contains the complete relevant storage range.

If the original sectors had already been overwritten before acquisition, the forensic container cannot restore the previous bytes. The image can only preserve what was physically readable at the moment it was created.

A note about SSDs and TRIM

This is especially important with SSDs.

When TRIM or a similar discard mechanism is active, deleting a file may cause the operating system to notify the SSD that the corresponding logical blocks are no longer required. The SSD controller can later erase or remap those blocks internally.

As a result, an image acquired after the discard operation may already contain zeros or otherwise unrecoverable data in the deleted area.

For SSD investigations, minimizing activity on the source device and acquiring the image as early as possible can be critical.

Forensic recovery is not the same as forensic validation

There is also an important distinction between recovering data from a forensic container and conducting a complete forensic examination.

A recovery application can be useful for:

• reconstructing damaged filesystems;

• searching for deleted files;

• locating lost partitions;

• carving files by signatures;

• exporting accessible data from an image.

But a formal forensic investigation may require additional procedures such as:

• chain-of-custody documentation;

• write-blocked acquisition;

• independent hash verification;

• evidence handling logs;

• reproducibility of examiner actions;

• organization-specific or jurisdiction-specific forensic procedures.

For legal or evidentiary work, treat the original forensic image as immutable, preserve its acquisition metadata and hashes, and perform analysis on a verified working copy.

Video walkthrough

The video below shows the complete workflow for working with AFD, E01, and S01 forensic disk images and recovering deleted data from them.

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

Practical checklist

Before starting recovery from a forensic image, I use this checklist:

• confirm the image format;

• verify all required image segments are present;

• work from a copy when evidence preservation matters;

• check the detected disk size and partition layout;

• start with a filesystem-based quick scan;

• use full analysis only when necessary;

• preview important files before export;

• save recovered data to another physical disk;

• preserve the original image and its hashes.

Conclusion

Forensic containers such as E01, S01, and AFD are not only archival formats. They can also be practical sources for data recovery when the original disk should no longer be accessed directly.

The key is to treat the image as a complete storage device rather than as a folder of files.

Mount the image, verify its structure, start with the least invasive scan, move to deeper filesystem and signature analysis only when necessary, and always export recovered data elsewhere.

If the deleted content was still physically present when the image was acquired, this workflow can often recover files that are no longer visible through normal filesystem access.

For the full step-by-step guide, additional screenshots, and format details, see the original article.

If the encrypted data is still present, the correct credentials are available, and the affected sectors have not been overwritten, you may be able to unlock the volume and analyze the filesystem inside it.

This guide covers three practical recovery scenarios:

• recovering deleted files from a VeraCrypt container;

• recovering files from a VeraCrypt-encrypted USB drive, including a hidden volume;

• reconstructing and scanning a deleted VeraCrypt partition.

Disclosure: I work with Hetman Software. The examples below use Hetman Partition Recovery to demonstrate the recovery workflow. The same safety principles—stop writing, image unstable media, unlock before scanning, and save elsewhere—apply regardless of the tool you use.

Video walkthrough

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

Why VeraCrypt recovery is different

With an ordinary NTFS, FAT, or exFAT volume, recovery software can examine filesystem records and unallocated space directly. VeraCrypt adds another layer:

Physical disk or container file
        ↓
VeraCrypt encrypted volume
        ↓
Decrypted logical volume
        ↓
NTFS / FAT / exFAT filesystem
        ↓
Files and folders

The filesystem can be analyzed correctly only after the encryption layer has been unlocked. A raw scan of the encrypted bytes cannot identify normal file signatures because both filesystem metadata and file content are encrypted.

VeraCrypt volumes may require:

• a password;

• a custom PIM value;

• one or more keyfiles;

• the correct password for either the standard or hidden volume.

Recovery software does not bypass VeraCrypt encryption. You still need the correct credentials. If a custom PIM or keyfile was used when the volume was created, the password alone may not be sufficient.

Before you start: protect the source

Every write to the affected device can overwrite recoverable data. Before attempting recovery:

1. Stop using the disk, flash drive, or container.

2. Do not format the device or create a new partition table.

3. Do not initialize an unallocated disk in Windows Disk Management.

4. Do not restore recovered files to the source device.

5. If the device is unstable, create a sector-by-sector image and work with the image.

If the VeraCrypt container file itself was deleted, recover that file first. Only then can you try to unlock and analyze the encrypted filesystem stored inside it.

Scenario 1: Recover files from a VeraCrypt container

A VeraCrypt container is a file that behaves like an encrypted disk after it is mounted. It may use the .hc extension, but an extension is not required.

Step 1: Add the container as a disk

Open Hetman Partition Recovery and add the container file. If it is not visible in the file picker, enable the display of all files. Add the container as a RAW disk.

The container should now appear in the list of available disks.

Step 2: Unlock the encrypted volume

Right-click the container and select Unlock VeraCrypt. Enter the password and, when applicable, the custom PIM and keyfile.

After successful authentication, the software exposes the decrypted filesystem as a separate logical disk.

Step 3: Scan the unlocked disk

Scan the unlocked logical volume, not the original encrypted container.

Start with Quick Analysis when files were recently deleted and the filesystem is otherwise healthy. Use Full Analysis when:

• Quick Analysis does not find the required files;

• the filesystem is damaged;

• the container no longer mounts normally;

• directory metadata has been lost.

Step 4: Preview and recover

Review the results and preview important files before recovery. A successful preview is a useful indication that the file content is intact and was decrypted correctly.

Select the required files and save them to another physical disk.

Scenario 2: Recover data from an encrypted USB drive

When a USB drive contains a VeraCrypt-encrypted partition, select the encrypted partition, not the entire physical device, and choose Unlock with VeraCrypt.

Enter the credentials for the standard volume. After it is unlocked, select the new decrypted logical disk and run Quick Analysis first. Switch to Full Analysis if the expected files are missing.

The scan results can include existing files, deleted entries, and folders reconstructed from the remaining filesystem metadata.

What about a hidden VeraCrypt volume?

A hidden volume exists inside the free space of an outer VeraCrypt volume and uses different credentials. Its presence is intentionally difficult to prove from the outside.

To scan it:

1. Return to the original encrypted partition.

2. Select Unlock with VeraCrypt again.

3. Enter the password, PIM, and keyfile associated with the hidden volume.

4. Select the newly unlocked hidden logical volume.

5. Analyze it separately and recover the files to another device.

The standard and hidden volumes are therefore two different recovery targets, even though they occupy the same encrypted partition.

Scenario 3: Recover a deleted VeraCrypt partition

Suppose a flash drive was processed with diskpart clean, or its partition table was otherwise erased. Windows may now display the entire device as unallocated even though the encrypted data still exists.

Do not create a replacement partition in Disk Management. Writing a new partition table or formatting the device can make recovery more difficult.

Step 1: Reconstruct the partition virtually

In Hetman Partition Recovery, right-click the physical device and select Create virtual disk.

Specify the original partition boundaries. Sector 2048 is a common starting offset on modern media, but it is only an example—not a universal value. If the device contained several encrypted partitions, reconstruct each range separately.

This virtual reconstruction should describe the lost partition without writing a new partition table to the source device.

Step 2: Unlock the reconstructed volume

Right-click the virtual partition, choose Unlock with VeraCrypt, and enter the corresponding password, PIM, and keyfile.

If the boundaries and credentials are correct, the software can decrypt the volume, recognize its filesystem, and expose it as a logical disk.

Step 3: Analyze the decrypted filesystem

Select the unlocked volume—not the physical flash drive and not the still-encrypted virtual partition—and run the analysis.

If the original partition also contained a hidden volume, repeat the unlock operation on the virtual partition using the hidden volume's credentials. The hidden volume will appear as a separate unlocked disk and must be scanned separately.

Choosing between Quick and Full Analysis

A deeper scan cannot recover sectors that have already been overwritten or discarded. It only provides a more thorough search of the data that remains.

Common mistakes that reduce recovery chances

• Formatting the device: even a quick format changes filesystem metadata.

• Creating a new partition: it writes new structures over the old layout.

• Scanning the encrypted device instead of the unlocked volume: encrypted bytes do not contain readable filesystem signatures.

• Using the wrong PIM or omitting a keyfile: the volume will not decrypt correctly.

• Saving recovered files to the source: this may overwrite other deleted data.

• Continuing to use a failing drive: repeated reads can accelerate physical degradation.

What this workflow cannot do

VeraCrypt uses strong encryption. Recovery is generally not practical without the correct password and any required PIM or keyfiles. This workflow also cannot restore data that has been overwritten, securely erased, or removed by storage-level garbage collection.

The goal is not to break encryption. It is to reconstruct the storage layout, authenticate normally, expose the decrypted filesystem, and recover whatever data remains inside it.

Final recovery checklist

• Work from an image when the source device may be unstable.

• Keep the original medium read-only whenever possible.

• Reconstruct deleted partition boundaries virtually.

• Unlock the VeraCrypt layer with all required credentials.

• Scan the resulting decrypted logical volume.

• Preview files before recovery.

• Save recovered data to a different physical device.

With the correct credentials and an intact encrypted data area, a deleted partition or damaged VeraCrypt container does not automatically mean permanent data loss.

For a more detailed step-by-step guide, see the original article: How to Recover Data from VeraCrypt Disks and Containers.

This creates a recovery problem with two separate layers:

1. The BitLocker volume must be unlocked with valid credentials.

2. The decrypted file system must then be analyzed for deleted or damaged data.

Treating these as separate stages is the key to safe recovery. Unlocking a volume only restores access to its decrypted sectors; it does not automatically restore deleted files or repair a damaged NTFS or exFAT structure.

This guide demonstrates a practical workflow for three common cases:

• A Windows system drive that no longer boots.

• An additional BitLocker-encrypted HDD with a damaged or missing partition.

• A BitLocker To Go USB drive that appears as RAW or asks to be formatted.

Important: Stop writing to the affected drive immediately. Do not reinstall Windows, format the volume, run CHKDSK, create new partitions, or save recovered files back to the same device.

The BitLocker Recovery Chain

The recovery process can be summarized as follows:

Physical drive → BitLocker volume → Valid key → Decrypted sector stream → File-system analysis → Recovered files

If the correct password or key is unavailable, a recovery tool sees encrypted sectors rather than recognizable NTFS, FAT, or exFAT metadata. Modern BitLocker encryption is not something a file-recovery scan can simply bypass.

For recovery, you will normally need one of the following:

• The password used for the encrypted volume.

• The 48-digit BitLocker Recovery Key.

• A BitLocker startup key stored in a .bek file.

When several recovery keys exist in a Microsoft account or an organization directory, compare their Key ID with the identifier shown for the locked volume.

Match the Key ID before entering a 48-digit recovery key.

Recovery keys may be stored in a Microsoft account, Active Directory, Microsoft Entra ID, a text file, a USB drive, or a printed copy. A .bek file may be hidden, so make sure that hidden and protected operating-system files are visible when searching for it.

Before Scanning: Preserve the Source Drive

The safest recovery workflow is read-only at the source, with all recovered data written to a different physical device.

If the drive is healthy and stable, connect it directly to a working computer through SATA when possible. A USB enclosure or docking station can also work, although it may be slower and can occasionally introduce connection resets during a long scan.

Connect the affected drive as a secondary device whenever possible.

If the disk disconnects, makes unusual sounds, reports a rapidly increasing number of bad sectors, or becomes extremely slow, stop repeated scans. Create a sector-by-sector image on healthy storage first or send the device to a hardware recovery specialist. Logical recovery software cannot repair physical media damage.

Before doing anything else:

• Disconnect the affected drive from normal workloads.

• Prepare another drive with enough free space for the recovered files.

• Find the password, Recovery Key, or .bek file.

• If the disk may be failing, work from an image rather than the original.

• Avoid tools that modify file-system metadata.

Scenario 1: The Encrypted Windows System Drive No Longer Boots

A BitLocker-protected system disk may request a Recovery Key after a BIOS or firmware update, TPM reset, Secure Boot change, or hardware replacement.

This does not necessarily mean that the files are damaged. The TPM may simply refuse to release the key automatically because the measured boot environment has changed.

A change in the trusted boot configuration can trigger the BitLocker recovery screen.

If the computer still cannot boot after the correct key is supplied, remove the drive and connect it to another working machine as a secondary disk. Do not initialize or format it if Windows offers to do so.

In Hetman Partition Recovery, select the locked BitLocker volume. The software displays an unlock dialog where you can enter the 48-digit Recovery Key or provide an available key file.

Check the Key ID to make sure you are using the correct recovery key.

Unlock the encrypted layer before analyzing the file system.

After successful authentication, the application decrypts sectors as they are read and exposes the underlying file system for analysis.

Start with Fast Scan. This is usually enough when the partition is intact and the problem is limited to deleted files or minor logical damage.

Use Fast Scan first. Run a deeper analysis only when its results are incomplete.

When scanning finishes, browse the reconstructed folder tree and preview important documents, photos, archives, and other files.

A successful preview is one of the best indicators that a file’s content can be recovered correctly.

Preview critical files before adding them to the recovery list.

If expected folders or files are missing, run Full Analysis. It searches more deeply for file-system structures and file signatures, but it takes longer and cannot restore content that has already been overwritten.

Scenario 2: An Encrypted Secondary HDD Is RAW, Formatted, or Missing

A secondary drive may contain one or more BitLocker volumes. The affected partition can disappear after an operating-system reinstall, an accidental format, damage to the partition table, or corruption that makes Windows identify the file system as RAW.

Do not recreate the partition merely to make it visible in File Explorer. Writing a new partition table or formatting the volume can overwrite metadata required for reconstruction.

If the volume uses an external BitLocker startup key, select the locked partition and specify the saved .bek file.

A valid .bek file can unlock the encrypted volume without changing the source disk.

Once unlocked, scan only the relevant volume first. This is faster than analyzing the entire physical disk and helps determine whether the original file-system metadata is still usable.

Use the following order:

1. Unlock the BitLocker volume.

2. Run Fast Scan.

3. Inspect the original folder structure and preview several important files.

4. Run Full Analysis if the required files are absent or the directory structure is severely damaged.

5. Save the selected files to a different physical disk or network location.

If the partition itself is missing, analyze the physical disk so that the software can search for lost partitions. Any candidate BitLocker volume still needs the correct key before its internal file system can be interpreted.

Scenario 3: A BitLocker To Go USB Drive Asks to Be Formatted

BitLocker To Go protects removable media such as USB flash drives. After a logical failure, Windows may report the drive as RAW or ask to format it.

Cancel the format prompt. Formatting is not required for recovery and may overwrite useful metadata.

Hetman Partition Recovery can detect a supported BitLocker volume and request its password or Recovery Key. Enter the password used when BitLocker To Go was configured.

Enter the BitLocker To Go password to expose the underlying file system.

After unlocking, run Fast Scan and check the results. Preview files before recovery, then save them to the computer’s internal disk or another healthy storage device—not to the affected USB drive.

Verify the recovered content in the preview pane before saving it.

USB flash memory adds another complication: some devices and storage stacks can discard deleted blocks. Once these blocks have been erased internally, no logical recovery tool can reconstruct their previous content.

This is another reason to disconnect the device immediately after data loss.

Video Walkthrough

The following video demonstrates BitLocker recovery for deleted files, lost partitions, and damaged drives:

https://www.youtube.com/watch?v=CbMA34Zr0ak&t=4s

Fast Scan or Full Analysis?

Choose the scan mode according to the failure rather than starting with the slowest option.

Common Mistakes That Reduce Recovery Chances

Formatting Because Windows Suggests It

Formatting creates new file-system structures. It does not decrypt or repair the original volume and can overwrite recoverable metadata.

Running CHKDSK Before Copying the Data

CHKDSK is a repair utility, not a recovery utility. It modifies the file system to make it internally consistent, and these changes may remove or rewrite records needed to recover deleted files.

Reinstalling Windows on the Same Disk

An installation writes large amounts of data and can overwrite deleted content, old metadata, and even the original partition layout.

Scanning Without Unlocking BitLocker

File-system scanners need decrypted sectors. Without a valid key, recognizable metadata remains encrypted.

Saving Recovered Files to the Source Drive

Every write can overwrite another file that has not yet been recovered. Always use a different physical device.

Expecting the Recovery Key to Restore Overwritten Data

The key grants access to encrypted sectors; it does not reverse deletion or overwriting. Normal data-recovery limitations still apply after the volume is unlocked.

What If the BitLocker Key Is Missing?

Check every legitimate key-storage location before assuming it is lost:

• The Microsoft account associated with the Windows installation.

• Active Directory or Microsoft Entra ID for an organization-managed device.

• Printed copies and password-manager records.

• USB devices and external disks.

• Text files containing the 48-digit key.

• .bek startup-key files.

• IT administration records for corporate hardware.

The Key ID helps identify the correct entry but is not itself a decryption key.

Without valid BitLocker credentials or usable key material, recovering the encrypted contents is generally not feasible.

Final Checklist

Before starting recovery, confirm that:

• No new data is being written to the affected device.

• The BitLocker password, Recovery Key, or .bek file is available.

• The Key ID matches the selected volume.

• The drive is physically stable or a sector-by-sector image has been created.

• Fast Scan will be tried before a deeper scan when appropriate.

• Important files will be verified with preview.

• Recovered data will be saved to a separate physical device.

BitLocker changes the order of operations, but not the fundamentals of data recovery: preserve the source, unlock the encryption layer, analyze the decrypted file system, verify the results, and save everything elsewhere.

For a more detailed walkthrough with additional screenshots, see the original guide: How to Recover Data from an Encrypted BitLocker Drive.

Disclosure: This workflow was prepared using Hetman Partition Recovery. I am affiliated with the team that develops the software.

A failed controller, corrupted RAID metadata, interrupted rebuild, accidental formatting, or the loss of several drives can leave an otherwise healthy set of disks inaccessible.

In this lab, we worked with an Infortrend ESDS 1012 RC and tested several recovery scenarios involving RAID 0, RAID 5, and RAID 6.

The recovery strategy changes considerably depending on whether the storage controller is still operational.

There are essentially two paths:

Working controller → Connect the logical volume through iSCSI → Scan the filesystem → Recover files

or:

Failed controller / damaged RAID → Connect the member disks → Create sector-by-sector images → Reconstruct the RAID → Locate the filesystem → Recover files

Disclosure: This lab uses Hetman RAID Recovery and Hetman Partition Recovery, software developed by our team at Hetman Software. The goal of this article is to document the RAID reconstruction workflow and the parameters we observed during the test.

The Test Environment

The Infortrend ESDS 1012 RC is a rack-mounted enterprise storage system with 12 drive bays and support for several RAID configurations, including RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50, and RAID 60.

For this experiment, we focused on three configurations:

This distinction becomes critical once the original controller is unavailable.

Scenario 1: The Infortrend Controller Still Works

A RAID controller does not need to be physically damaged for data recovery to become necessary.

The storage may still operate normally while files have been:

• accidentally deleted;

• removed with Shift + Delete;

• lost after formatting;

• lost after partition changes;

• made inaccessible because of filesystem damage.

In this situation, manually reconstructing the RAID is unnecessary.

The better approach is to let the original Infortrend controller assemble the array and work with the resulting logical volume.

Connecting the Storage Through iSCSI

The logical storage can be connected to a Windows workstation using iSCSI Initiator.

Open iSCSI Initiator, enter the IP address of the Infortrend storage system, and connect to the required target.

After the connection is established, Windows receives the logical disks exposed by the storage controller.

They should appear in Disk Management.

At this point, there is no need for recovery software to determine RAID geometry. The Infortrend controller is already handling disk order, striping, and parity.

The recovery task therefore moves one level higher in the storage stack — to the filesystem.

Scan the Logical Volume

For recently deleted files, start with a fast filesystem scan.

If the volume was formatted or its filesystem structures were damaged, a deeper analysis may be required.

After scanning, existing and deleted files can be reviewed before recovery.

One rule is particularly important:

Never save recovered files back to the source volume.

Use another physical disk or another independent storage system. Writing to the source can overwrite data that has not yet been recovered.

Scenario 2: The Controller or RAID Configuration Is Unavailable

The more interesting recovery scenario begins when the Infortrend controller can no longer provide the logical volume.

Possible causes include:

• controller failure;

• corrupted RAID metadata;

• lost RAID configuration;

• interrupted rebuild;

• incorrect disk order;

• firmware problems;

• multiple disk failures.

In this case, the individual RAID members have to be analyzed directly.

Image the Disks Before RAID Reconstruction

For important data, RAID reconstruction should ideally not be performed directly on the original drives.

A safer workflow is:

Physical RAID disks → Sector-by-sector images → RAID reconstruction → Filesystem analysis → File recovery

Create a sector-by-sector image of every available RAID member.

In Hetman RAID Recovery, this can be done by selecting a physical drive and using Save Disk.

The image should be stored on another physical device with sufficient free space.

This approach has two important advantages.

First, the original drives can be disconnected after imaging.

Second, different RAID configurations can be tested repeatedly without modifying or unnecessarily stressing the source media.

This becomes especially important when one or more disks have read errors or other signs of physical degradation.

Mounting the RAID Member Images

Once the member disks have been imaged, mount every image as a separate virtual disk.

For our test, we used RAW images.

After mounting, each image represents one original member of the Infortrend array.

From this point forward, RAID reconstruction can be performed entirely on the disk images.

Manual RAID Reconstruction

If usable RAID metadata is unavailable, several parameters need to be determined manually:

• RAID level;

• number of members;

• disk order;

• block or stripe size;

• parity layout;

• data offset, when applicable.

For the lab, we used the RAID Constructor in manual mode.

The values below are the parameters observed in our specific test arrays.

They should not be interpreted as universal defaults for every Infortrend ESDS configuration. Another array may use different stripe sizes, disk order, or other parameters.

Reconstructing RAID 0

RAID 0 is structurally simple because it has no parity, but from a recovery perspective it is also the least forgiving RAID level.

Data is striped across all members.

If one disk is missing, portions of virtually every sufficiently large file may be missing as well.

For our two-disk RAID 0 test, the relevant parameters were:

• RAID type: RAID 0

• Block size: 128 KB

• Disk order: original member order

Disk order and block size are especially important.

An incorrect configuration may still produce something that superficially resembles a filesystem, but files can be corrupted because their blocks are being read from the wrong locations.

For example, with an incorrect stripe size you might encounter:

• directories that appear valid;

• small files that open correctly;

• larger images that are partially corrupted;

• archives that fail integrity checks;

• videos that stop playing after a certain point.

Once the RAID 0 parameters are configured correctly, scan the reconstructed volume.

The ability to preview known files is useful here because it provides a practical way to validate the RAID geometry before recovering the entire dataset.

Reconstructing RAID 5

RAID 5 adds distributed parity.

This makes the layout more complex than RAID 0, but it also allows the array to tolerate the loss of one member.

In our test, RAID 5 consisted of three disk images.

The detected parameters were:

• RAID type: RAID 5

• Block order: Right Asynchronous

• Block size: 64 KB

• Disk order: original member order

After creating the virtual RAID, a useful next step is to search for the original partitions.

Finding a valid filesystem at the expected location is one of the first indications that the RAID parameters are likely correct.

In other words:

Correct disk order + Correct stripe size + Correct parity layout → Coherent filesystem structures

If the partition is found successfully, scan it and inspect several known files before starting a large recovery operation.

RAID 5 can theoretically be reconstructed with one missing member because the missing blocks can be calculated from the remaining data and parity blocks.

However, if all members are readable, using all of them is preferable.

Reconstructing RAID 6

RAID 6 uses two independent parity blocks.

This allows the array to tolerate the simultaneous loss of up to two members, but it also makes the RAID layout more complex.

Our test RAID 6 used four disk images.

The reconstruction parameters were:

• RAID type: RAID 6

• Block order: Right Asynchronous

• Block size: 32 KB

• Disk order: original member order

After creating the virtual RAID, we performed the same type of partition search used for RAID 5.

When the filesystem was located, the resulting volume appeared inside the reconstructed RAID and could then be scanned normally.

The ability to tolerate two missing disks does not mean that every damaged RAID 6 can always be recovered completely.

For successful reconstruction, there still needs to be enough valid information to determine the original layout and calculate the missing blocks.

How to Tell If the RAID Parameters Are Wrong

A RAID constructor accepting the configuration does not automatically mean that the array has been assembled correctly.

Several symptoms may indicate an incorrect configuration:

• no recognizable partition;

• filesystem signatures at inconsistent offsets;

• folder names mixed with corrupted entries;

• small files opening while larger files fail;

• partially displayed images;

• corrupted archives;

• broken videos;

• databases that fail consistency checks;

• virtual machines that no longer boot or mount correctly.

If this happens, review the parameters approximately in this order:

Disk order → Block size → Parity layout → Starting offset → RAID level

Disk order is particularly important.

Even when the RAID type and block size are correct, swapping two member disks can make the reconstructed filesystem unusable.

Validate Before Recovering Everything

One useful mistake to avoid is starting a multi-terabyte recovery immediately after the first apparently successful reconstruction.

First validate the result.

Check:

• filesystem structure;

• several directory trees;

• JPEG or PNG images;

• ZIP or RAR archives;

• large video files;

• documents;

• virtual disks, if present.

For archive formats, an integrity test is especially useful because a file may have the correct filename and size while still containing incorrectly reconstructed blocks.

The same principle applies to databases and virtual machine disks.

Seeing a correct directory structure is encouraging, but successfully opening known files provides much stronger evidence that the RAID geometry is correct.

Video Walkthrough

The complete experiment shows the Infortrend configuration, iSCSI access, disk imaging, and manual reconstruction of RAID 0, RAID 5, and RAID 6.

https://www.youtube.com/watch?v=94_DMSOr7-c

What This Experiment Demonstrates

The main lesson from this lab is that RAID recovery is not a single operation.

The correct workflow depends on which layer of the storage stack has failed.

When the original controller is still operational:

Infortrend controller → Logical volume → Filesystem scan → Files

When the RAID itself can no longer be assembled:

Member disks → Disk images → RAID reconstruction → Partition → Filesystem → Files

The differences between the three tested RAID levels are also fundamental:

• RAID 0 requires every member for complete reconstruction.

• RAID 5 can tolerate one missing member.

• RAID 6 can tolerate up to two missing members.

However, redundancy alone is not sufficient for recovery.

The correct disk order, stripe size, parity layout, and filesystem location still need to be established.

And whenever possible, the first operation should be preservation of the source disks rather than experimentation on them.

Full Step-by-Step Infortrend Recovery Guide

This article focuses on the RAID reconstruction methodology and on the differences between RAID 0, RAID 5, and RAID 6.

For the complete step-by-step procedure, additional screenshots, iSCSI configuration, and recovery workflow, see the original Hetman Software technical guide.

That creates a practical recovery challenge: the operating system no longer sees the logical RAID volume, but the individual disks may still contain enough metadata and filesystem information to reconstruct the array.

In this article, I’ll walk through a practical workflow for recovering data from RAID arrays created on an LSI 3ware 9750 controller.

The main example focuses on RAID 5, but the same general logic can be applied to RAID 0, RAID 1, and RAID 10 as well.

Disclosure: I work with Hetman Software, and the recovery examples below use Hetman RAID Recovery. This article focuses on the RAID reconstruction workflow and the reasoning behind each step.

Why RAID recovery on 3ware controllers can be tricky

The LSI 3ware 9750 is a hardware RAID controller designed for SAS and SATA drives. In normal operation, it presents the array as a single logical disk to the operating system.

When something goes wrong — for example:

• the controller fails;

• the RAID configuration is lost;

• one of the drives drops out;

• the array is no longer detected;

• the rebuild process is interrupted;

you may lose access to the logical volume even though the data on the member disks still exists.

The key principle is simple:

Don’t rush to rebuild or reinitialize the RAID on the original hardware.

Instead, preserve the source disks first and analyze them separately.

1. Disconnect and label the RAID member disks

If the original controller is unavailable or unreliable, disconnect the drives from the LSI 3ware controller and connect them directly to another machine.

Before doing that, label each drive carefully.

For example:

• Disk 0

• Disk 1

• Disk 2

That matters because disk order is often critical during manual RAID reconstruction.

A direct motherboard connection is preferable. If needed, USB-to-SATA adapters can also be used, but direct access is usually more stable.

For RAID 5, one missing drive may still be acceptable.

For RAID 0, all member disks are required.

2. Create disk images before repeated testing

If any drive shows instability, bad sectors, or signs of physical degradation, it’s better not to keep scanning the original device.

Instead, create a sector-by-sector image and work from that image.

In Hetman RAID Recovery, you can select the disk, right-click it, and choose Save Disk.

This gives you a safer workflow:

Physical RAID disks
↓
Sector-by-sector images
↓
RAID reconstruction
↓
Filesystem analysis
↓
File recovery

This approach is especially useful when you need to try more than one RAID configuration and want to avoid repeated reads from a questionable source disk.

3. Mount the image and let the software detect the RAID automatically

Once you have the images or the physical drives connected, the next step is to see whether the software can detect the RAID automatically.

In many cases, enough RAID metadata remains on the disks for the program to determine:

• RAID level;

• disk order;

• stripe size;

• offsets;

• parity rotation.

If that happens, the reconstructed array will appear as a single logical device.

This is one of the most useful things to understand about RAID recovery:

You do not always need the original controller to recover the data.

If the member disks are available and their metadata is intact, the logical RAID structure can often be rebuilt in software.

4. Start with a Quick scan

Once the RAID is recognized, the next task is filesystem analysis.

I normally recommend starting with a Quick scan.

That is often enough when:

• the RAID structure is valid;

• the filesystem metadata is still readable;

• the issue is logical rather than physical.

A Full scan is more appropriate when the filesystem is damaged, formatted, or its metadata is heavily corrupted.

After the scan finishes, review the results carefully.

When validating the result, look for:

• familiar folder names;

• correct filenames;

• realistic file sizes;

• previewable images and documents;

• larger files that open without corruption.

A folder tree alone is not enough.

The real test is whether real user files open correctly.

5. What to do if automatic RAID detection fails

Automatic reconstruction is ideal, but it doesn’t always work.

If RAID metadata is missing or badly damaged, the array must be reconstructed manually.

For a RAID 5 built on an LSI 3ware 9750, the critical parameters are:

• RAID level;

• number of member disks;

• disk order;

• block / stripe size;

• parity layout;

• data offset;

• missing disk position, if applicable.

In RAID Constructor, these values can be entered manually.

Typical values for this controller may include block sizes such as:

• 16 KB

• 64 KB

• 256 KB

But they should never be treated as guaranteed values.

They are only candidates.

The final validation must always come from the resulting filesystem and the integrity of the recovered files.

6. Disk order matters more than many people expect

One of the most common reasons a manually reconstructed RAID does not work is incorrect disk order.

For striped arrays, a wrong disk sequence causes adjacent stripes to be assembled incorrectly.

Example:

Correct order:
Disk 0 → Disk 1 → Disk 2

Incorrect order:
Disk 1 → Disk 0 → Disk 2

In RAID Constructor, you can reorder the disks and test different variants until the array begins to produce a coherent filesystem.

The best validation pattern is:

1. Check whether the expected partitions appear.

2. Check whether the filesystem is recognized correctly.

3. Open several directories.

4. Preview files.

5. Verify that larger files are not internally corrupted.

Once the correct configuration is found, the rebuilt array should appear in the main window and behave like a normal logical volume.

7. RAID 0, RAID 1, and RAID 5: recovery expectations

Different RAID levels give you different recovery chances.

RAID 0

RAID 0 has no redundancy.

If one member is unavailable, portions of almost every large file may be missing.

That means complete recovery is often impossible without all disks.

RAID 1

RAID 1 mirrors the same data across drives.

If one member is intact, you may still be able to access the full filesystem.

RAID 5

RAID 5 stores both data and distributed parity.

That means the array can generally tolerate one missing disk.

In a three-disk RAID 5, recovery from two surviving members is often possible — as long as the remaining disks are healthy and the RAID geometry is reconstructed correctly.

Video walkthrough

The full walkthrough is also available as a video:

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

A safer RAID recovery workflow

When dealing with a failed LSI 3ware 9750 array, I recommend the following order:

1. Stop writing to the RAID.

2. Label all member disks.

3. Connect the drives separately.

4. Create images of unstable disks.

5. Try automatic RAID detection.

6. Validate the filesystem and file previews.

7. Reconstruct the array manually if needed.

8. Recover files to another storage device.

The sequence matters.

Trying to make the original RAID operational before preserving the source can turn a recoverable case into a much harder one.

Final thoughts

The most important takeaway from this test is that the original LSI 3ware 9750 controller is not always required to recover the data.

If the disks are still available, recovery software can often reconstruct the array from the member disks themselves.

When the metadata survives, the process may be mostly automatic.

When it does not, recovery becomes a matter of correctly determining:

• RAID members;

• disk order;

• block size;

• parity layout;

• offsets.

Once those parameters are correct, the rest becomes standard filesystem analysis and file recovery.

If you want the complete step-by-step guide with more screenshots and additional details, see the original article on the Hetman Software website.

One advantage of mdadm is that the RAID configuration is implemented in software rather than being tied to a specific hardware RAID controller. If the original NAS, motherboard, or operating system fails, the member disks can often be connected to another computer and the array reconstructed there.

But RAID is not a backup.

A failed drive, damaged mdadm metadata, an interrupted rebuild, filesystem corruption, or accidental file deletion can still make an entire volume inaccessible.

In this guide, we'll look at a practical recovery workflow for RAID 0, RAID 5, and RAID 6 arrays created in OpenMediaVault.

OpenMediaVault provides a web interface for managing disks, filesystems, shared folders, and NAS services.

RAID 0 vs RAID 5 vs RAID 6

Before attempting recovery, it is important to understand how much redundancy the original array provides.

With RAID 0, data is striped across all members without parity. Every disk is required to reconstruct the complete data stream.

With RAID 5, distributed parity makes it possible to reconstruct the contents of one missing member.

RAID 6 stores two independent parity blocks and can normally tolerate the loss of two drives.

This difference is important during recovery. A degraded RAID 5 or RAID 6 may still contain enough information to reconstruct missing data, while RAID 0 does not have this protection.

A safe recovery workflow

A typical recovery process can be summarized as:

OpenMediaVault / mdadm disks
            ↓
Preserve the original drives
            ↓
Create disk images if necessary
            ↓
Detect or reconstruct the RAID
            ↓
Verify the filesystem
            ↓
Scan the logical RAID volume
            ↓
Preview recovered files
            ↓
Save them to separate storage

The most important principle is to avoid changing the original disks.

Do not create a new RAID over the old drives, rebuild the array unnecessarily, format the volume, or write recovered files back to the source storage.

Do not initialize Linux RAID disks in Windows

After connecting OpenMediaVault disks to a Windows computer, Disk Management may report some of them as unknown or uninitialized.

Windows may then offer to initialize the disks as GPT or MBR.

Cancel this operation.

A disk being unrecognized by Windows does not mean it is empty. Linux RAID members may contain mdadm metadata, filesystem structures, and user data that Windows cannot interpret directly.

Initialization can overwrite important structures and make subsequent reconstruction more difficult.

Create disk images when the drives are unstable

Whenever possible, recovery should be performed from disk images instead of repeatedly accessing unstable physical media.

This is especially important when a drive:

• reports SMART errors;

• contains bad sectors;

• disconnects intermittently;

• produces read errors;

• makes unusual mechanical noises;

• is suspected of degrading.

Disk images are also useful when the recovery workstation does not have enough SATA ports to connect every member simultaneously.

You can connect each disk individually, create an image, and then work with all images together as a virtual RAID.

Conceptually, the workflow looks like this:

Disk 1 → image1
Disk 2 → image2
Disk 3 → image3
Disk 4 → image4

             ↓

Virtual RAID reconstruction

Remember that a full sector-by-sector image requires approximately the same amount of storage as the capacity of the original drive.

A 4 TB RAID member therefore requires approximately 4 TB of destination space for its full image, regardless of how much user data is actually stored on it.

Automatic mdadm RAID reconstruction

The easiest recovery case is when enough mdadm metadata remains intact.

After the physical disks or their images are connected, RAID recovery software can analyze the available metadata and determine parameters such as:

• RAID level;

• number of members;

• disk order;

• stripe or chunk size;

• data offset;

• parity layout;

• filesystem.

In our OpenMediaVault test, the RAID 5 configuration was detected automatically and presented as a complete logical volume.

Once the RAID has been reconstructed, the logical volume can be analyzed in much the same way as a normal disk.

Start with a filesystem-aware Fast Scan.

If the filesystem metadata remains intact, a quick scan may be enough to reconstruct the directory tree and locate both existing and recently deleted files.

Before saving anything, preview several files.

This is an important validation step. Seeing correct filenames and directories does not necessarily prove that the RAID geometry is correct.

Try opening different types of files:

• JPEG or RAW photographs;

• documents;

• ZIP archives;

• database files;

• videos;

• large files that span multiple RAID stripes.

If several files preview correctly, the reconstructed RAID parameters are probably correct.

Video walkthrough

The following video demonstrates the recovery process in practice:

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

What if the RAID is not detected automatically?

Automatic reconstruction depends heavily on the availability of valid RAID metadata.

Detection may fail after:

• mdadm superblocks are damaged;

• the RAID configuration is deleted;

• a new operating system is installed;

• disks are accidentally initialized;

• RAID expansion fails;

• an interrupted migration corrupts metadata;

• one or more member drives are unavailable.

In these situations, the underlying filesystem and user data may still exist even though the metadata describing the RAID geometry has been lost.

The array must then be reconstructed virtually.

Manual RAID reconstruction

A RAID constructor can recreate the original geometry without modifying the physical disks.

The most important parameters include:

RAID level
Disk order
Stripe / chunk size
Parity layout
Sector size
Data offset
Missing disk positions

For example, a RAID 6 array may require parameters similar to:

RAID level:     RAID 6
Parity layout:  Left Synchronous P+Q
Stripe size:    512 KB
Sector size:    512 bytes

These values are only examples.

Never assume that another mdadm array uses the same parameters.

Actual values depend on the configuration used when the original RAID was created.

The correct disk order is particularly important.

Changing the position of even one drive changes the order of data blocks in the reconstructed stream.

Handling missing disks

A missing drive should normally remain represented in its original position.

For example, suppose the original RAID 5 consists of:

Disk 1
Disk 2
Disk 3
Disk 4

If Disk 3 has failed, the reconstruction should remain:

Disk 1
Disk 2
[MISSING]
Disk 4

You should not simply move Disk 4 into the third position.

RAID 5 can use parity to reconstruct the missing member logically.

RAID 6 can perform a similar reconstruction with up to two missing members, assuming the remaining disks are readable and the RAID geometry is known.

RAID 0 cannot reconstruct a missing member because it contains no parity information.

The data offset can be critical

Another parameter that is easy to overlook is the data offset.

The filesystem does not always begin at the first sector of each RAID member. mdadm may reserve space before the actual RAID data area for metadata and other structures.

If the RAID metadata has been damaged, the recovery software may not be able to determine this value automatically.

In our test configuration, the data offset was:

135266304 bytes

This value had to be specified for the corresponding RAID members during manual reconstruction.

This value is specific to the test array and should not be copied blindly to another RAID.

An incorrect offset may produce symptoms such as:

• no filesystem detected;

• corrupted directory structures;

• missing files;

• files that appear with correct names but contain invalid data.

Use the filesystem to validate the RAID geometry

One of the best indicators of a correct RAID configuration is a recognizable filesystem.

The validation process looks like this:

RAID members
     ↓
Correct disk order
     ↓
Correct stripe and parity layout
     ↓
Correct data offset
     ↓
Filesystem detected
     ↓
Directory structure appears
     ↓
Files preview correctly

A RAID Constructor can often show the resulting virtual volume before a complete scan is performed.

This allows you to test different combinations without immediately scanning several terabytes of storage.

The appearance of a valid filesystem is a useful signal, but file preview provides stronger verification.

Large files are particularly useful because they usually span several stripes and therefore depend on multiple disks being positioned correctly.

After the RAID has been reconstructed

Once the correct RAID configuration has been identified, add the reconstructed array as a virtual RAID volume.

Then scan the logical RAID volume rather than scanning individual member disks separately.

Start with Fast Scan.

If the expected files or directories are missing, proceed to a deeper filesystem analysis.

The order is important:

Reconstruct RAID correctly
        ↓
Verify filesystem
        ↓
Scan the logical volume
        ↓
Preview files
        ↓
Recover data

A deeper filesystem scan cannot compensate for incorrectly reconstructed RAID geometry.

If the disk order, parity algorithm, stripe size, or offset is wrong, the scanner receives an incorrect data stream.

Where should recovered files be saved?

Always save recovered files to another physical storage device.

Do not save them:

• to the original RAID;

• to one of its member disks;

• to an image being analyzed.

For example:

Source:
4 × RAID member disks

Recovery destination:
External HDD / SSD
Another NAS
Separate storage server

This avoids overwriting data that may still need to be recovered later.

Practical recovery checklist

Before starting a long recovery operation, verify the following:

• all available RAID members have been identified;

• unstable drives have been imaged where possible;

• Windows has not initialized or formatted the disks;

• the RAID level is correct;

• member disk order is correct;

• stripe size is plausible;

• parity layout is correct;

• data offsets are correct;

• missing drives occupy their original positions;

• the filesystem is detected;

• several files can be previewed successfully;

• recovered data will be saved to separate storage.

Spending time validating these parameters can prevent hours of scanning an incorrectly reconstructed array.

Conclusion

OpenMediaVault's use of mdadm makes its software RAID relatively portable because the storage configuration is not tied to a proprietary hardware controller.

That can be extremely useful when the original NAS motherboard, operating system, or other hardware fails.

The safest recovery strategy is to preserve the original state of the storage first.

Avoid rebuilding, initialization, formatting, and unnecessary writes. If a drive is unstable, create an image. Then reconstruct the RAID virtually, verify the filesystem and file contents, and only after that begin copying recovered data.

Correct RAID geometry matters more than scan depth: a full filesystem scan cannot repair a logical RAID that has been assembled with the wrong disk order, stripe size, parity layout, or offset.

For a complete step-by-step walkthrough with additional screenshots and detailed examples, read the original guide.

In this guide, we will look at the main ZFS storage objects and walk through a practical recovery workflow using a TrueNAS/ZFS pool and Hetman RAID Recovery.

Video: ZFS Data Recovery

The complete recovery process is also demonstrated in this video:

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

Understanding Datasets, ZVOLs, Snapshots, and Virtual Disks

Before attempting recovery, it is important to understand where the required data is actually stored.

A Dataset stores files directly:

Physical Disks → ZFS Pool → Dataset → Files

A ZVOL works as a virtual block device and may contain another filesystem:

Physical Disks → ZFS Pool → ZVOL → NTFS / Ext4 / XFS → Files

Virtual machine storage in ZFS can be implemented in two main ways: as a ZVOL block device or as a virtual disk file stored inside a Dataset.

A ZVOL acts as a virtual block device and may contain the guest operating system filesystem directly:

ZFS Pool → ZVOL → Guest Filesystem → VM Files

Alternatively, the virtual machine disk can be stored as a regular file inside a Dataset:

ZFS Pool → Dataset → VMDK / QCOW2 / VHDX / RAW → Guest Filesystem → VM Files

This distinction is important during recovery because a ZVOL and a virtual disk file are detected and analyzed at different levels of the ZFS storage structure.

Snapshots add another possible recovery layer:

ZFS Pool → Snapshot → ZVOL → Guest Filesystem → File

This layered structure is one of the main reasons why ZFS recovery may require more than one scan.

Safe Recovery Workflow

The first rule when recovering data from damaged ZFS storage is to avoid writing to the affected disks.

Do not format, initialize, rebuild, or copy new data to the damaged pool. If possible, create sector-by-sector images of the drives and perform further analysis using those copies.

A safe workflow looks like this:

Original Drives → Disk Images → Pool Reconstruction → Scan → Recovery to Another Disk

Recovered files should always be saved to a different physical storage device.

Connect the Drives or Create Disk Images

If the original TrueNAS or ZFS server is no longer working, remove the pool members and connect them to another computer.

Direct SATA or SAS connections are preferable. When there are not enough available ports, you can create images of some drives and combine physical disks with disk images during reconstruction.

Hetman RAID Recovery can create a sector-by-sector image directly from a connected disk.

Creating an image of a ZFS pool member before recovery.

The program treats disk images in much the same way as physical devices, allowing them to participate in automatic pool reconstruction.

This is especially useful for large NAS or server configurations where connecting every original disk to one workstation is inconvenient.

Reconstruct and Scan the ZFS Pool

After the surviving drives or their images are available, start Hetman RAID Recovery.

The software reads available ZFS metadata, analyzes the vdev configuration, and attempts to reconstruct the original pool automatically.

The detected pool appears in the RAID Volumes section.

Selecting the automatically reconstructed ZFS pool.

Open the pool and start with Fast Scan.

Fast Scan should normally be the first analysis method.

Fast Scan uses the existing filesystem metadata and is usually sufficient when the ZFS structure is still largely intact.

After scanning, the reconstructed filesystem may contain Datasets, Snapshots, ZVOLs, virtual disks, and regular files.

Datasets and the Snapshots folder detected inside the reconstructed pool.

If the required data appears here, there is usually no reason to immediately perform a much longer Full Scan.

Recover Files from a Dataset

A Dataset is the simplest recovery case because it behaves as a regular filesystem inside the ZFS pool.

If its metadata is still available, folders and files will appear directly in the reconstructed directory hierarchy.

The workflow is straightforward:

ZFS Pool → Dataset → Folder → File

Browse the Dataset, preview important files, select the required objects, and recover them to another disk.

Previewing files before recovery is useful because a valid preview confirms that the relevant data blocks are still readable.

Recover ZVOLs and Virtual Disks

ZVOL recovery is different because a ZVOL does not contain ordinary files at the ZFS level. It represents a block device that may contain another filesystem.

A similar situation occurs with VMDK, QCOW2, VHDX, RAW, and other virtual disk images stored inside a Dataset.

For example:

ZFS Pool → ZVOL → NTFS → Files

or:

ZFS Pool → Dataset → Virtual Disk → Guest Filesystem → Files

After Fast Scan, locate the required ZVOL or virtual disk.

A virtual disk image found inside the reconstructed Dataset.

Instead of recovering the entire virtual disk first, it can be mounted directly in the recovery application and analyzed as another storage device.

For example, if the virtual disk contains NTFS:

ZFS → Virtual Disk → NTFS → Deleted File

The filesystem inside the mounted disk can then be scanned separately.

For simple deletion, start with Fast Scan. If the guest filesystem was formatted or its partition structure was damaged, use Full Scan.

This two-stage analysis is particularly useful for recovering virtual machines from damaged TrueNAS or other ZFS-based storage.

Recover Data from ZFS Snapshots

Snapshots can provide an easier recovery path when a file, Dataset, ZVOL, or virtual machine was modified or deleted after the snapshot was created.

After Fast Scan, available snapshots appear in a dedicated Snapshots directory.

The Snapshots directory detected during ZFS analysis.

Open the folder to view the available recovery points.

Snapshots can be identified by their names and creation dates.

This makes it possible to recover an earlier version of an individual file without rolling the entire live Dataset back.

Snapshots can also contain ZVOLs.

In that case:

ZFS Pool → Snapshot → ZVOL → Guest Filesystem → File

The ZVOL can be mounted directly from the snapshot:

Mounting a ZVOL captured inside a snapshot.

After mounting it, scan the filesystem inside the virtual disk and recover the required files in the same way as from an ordinary storage device.

This is particularly useful in production environments because it lets you retrieve specific historical data without rolling the complete Dataset or virtual machine back to an older state.

Recover Deleted Datasets, ZVOLs, and Virtual Disks

If a Dataset, ZVOL, or virtual disk was deleted and the original metadata is no longer available, Fast Scan may not find it.

In this situation, run Full Scan on the reconstructed ZFS pool.

Running Full Scan when ZFS metadata is missing or damaged.

The recovery workflow becomes:

ZFS Pool → Full Scan → Deleted ZVOL / Virtual Disk → Mount → Guest Filesystem → Files

Full Scan analyzes the underlying storage more deeply and can locate objects that are no longer represented in the active directory structure.

If the original name of a virtual disk was lost, its expected size can be an important identification clue.

For example, if the missing VM had a 200 GB virtual disk, filtering the results by approximate size can greatly reduce the number of candidates. File type, date, and filename filters can also help.

Once a potential ZVOL or virtual disk is found, mount it and inspect its internal filesystem before recovering a large image unnecessarily.

Fast Scan or Full Scan?

Choosing the correct analysis mode can save a significant amount of time, especially with multi-terabyte ZFS pools.

The general rule is simple: start with Fast Scan and move to Full Scan only when necessary.

A Layered Approach to ZFS Recovery

The most important thing to understand about ZFS recovery is that the required file may exist several storage layers below the physical disks.

A complete path can look like this:

Physical Disks → ZFS Pool → Snapshot → ZVOL → Guest Filesystem → File

or:

Physical Disks → ZFS Pool → Dataset → Virtual Disk → Guest Filesystem → File

Finding the ZFS pool is therefore not always the final step.

For ordinary Dataset files, one scan may be enough. For virtual machines and ZVOLs, the correct approach is often to reconstruct the ZFS layer first and then analyze the filesystem inside the recovered block device.

To maximize the chances of successful recovery:

• avoid writing to the damaged pool;

• create disk images whenever possible;

• reconstruct the ZFS pool from the surviving members;

• start with Fast Scan;

• check available Snapshots;

• mount ZVOLs and virtual disks for additional analysis;

• use Full Scan only when metadata-based recovery is insufficient;

• save recovered data to another physical storage device.

For a more detailed step-by-step walkthrough with additional screenshots and recovery scenarios, see the original technical guide.

Depending on the RAID level, the array can provide better performance, fault tolerance, or a combination of both. However, RAID does not eliminate the risk of data loss.

Access to a RAID volume can be lost because of:

• a failed RAID controller or server motherboard;

• one or more failed drives;

• accidental RAID configuration deletion;

• incorrect array recreation;

• interrupted RAID migration or expansion;

• disk initialization;

• partition deletion or formatting;

• file system corruption.

In this guide, we will examine how to approach data recovery from RAID 0, RAID 5, and RAID 6 arrays created with a Dell PERC H700, including situations where the original controller is no longer available.

How Many RAID Disks Are Required for Recovery?

Before attempting reconstruction, determine how many original RAID members are still available. The requirements are different for each RAID level.

With RAID 0, data is striped across all drives without parity. If one member is missing, parts of virtually every large file may also be missing.

With RAID 5, distributed parity allows the contents of one missing member to be reconstructed.

With RAID 6, two independent parity calculations allow reconstruction even when two members are unavailable.

This distinction is important because RAID redundancy determines whether reconstruction is mathematically possible before file-system recovery even begins.

Do Not Initialize the RAID Disks

After removing disks from a failed server and connecting them to another Windows computer, Windows may display a message such as:

You must initialize a disk before Logical Disk Manager can access it.

Do not initialize the disks.

Initialization, formatting, partition creation, or other write operations may overwrite RAID or file-system metadata that could still be useful during recovery.

A safer workflow is:

1. Stop using the failed array.

2. Record the original disk positions.

3. Label every disk.

4. Connect the available drives to a recovery workstation.

5. Avoid all write operations.

6. Create sector-by-sector disk images when possible.

7. Perform reconstruction and scanning from the images or original read-only media.

SATA drives can usually be connected directly to SATA ports or appropriate adapters. SAS drives require SAS-compatible hardware.

Create Disk Images Before Reconstruction

If the data is important or one of the drives shows signs of instability, working from disk images is preferable to repeatedly scanning the physical media.

In Hetman RAID Recovery, select a physical drive and use Save Disk to create an image.

The resulting image can then be connected to the recovery environment instead of the physical drive.

Select Mount Disk and choose the appropriate disk-image type.

This is particularly useful when:

• a source disk is unstable;

• the original server needs to be returned to service;

• several recovery attempts may be required;

• you want to preserve the original disks unchanged.

Once all available physical disks or their images are connected, RAID reconstruction can begin.

Automatic RAID Reconstruction

In many cases, enough RAID metadata remains on the member disks to identify the original configuration automatically.

A RAID recovery application can analyze the available drives and determine parameters such as:

• RAID level;

• number of members;

• disk order;

• stripe size;

• data offset;

• parity layout;

• missing disks.

In our example, the disks belonged to RAID arrays created with a Dell PERC H700.

After the available disks are connected, Hetman RAID Recovery identifies the RAID structures and displays reconstructed logical arrays separately from the physical disks.

This separation is important.

There are actually two different layers involved in RAID recovery:

Physical RAID members → reconstructed RAID volume → file system → files

A program must first interpret the RAID geometry correctly. Only then can NTFS, ReFS, Ext, XFS, ZFS, or another file system inside the resulting virtual volume be analyzed correctly.

Scan the Reconstructed RAID

If the RAID structure has been reconstructed correctly, select the resulting logical RAID volume rather than one of its individual physical members.

For an intact file system or recently deleted files, start with Fast scan.

A fast scan analyzes the available file-system metadata and directory structures.

If the array was formatted, partitions were deleted, or the file system is seriously damaged, use Full analysis instead.

Before saving recovered files, inspect several files with the preview function.

This is useful not only for checking the files themselves but also for verifying that the RAID has been reconstructed correctly.

If folders appear normal but most files are corrupted, one of the RAID parameters may still be incorrect.

What If the RAID Is Not Detected Automatically?

Automatic reconstruction depends on the information that remains on the disks.

If the RAID configuration was deleted, the disks were initialized, metadata was overwritten, or a new array was accidentally created, some parameters may need to be specified manually.

For this purpose, use RAID Constructor.

The most important RAID parameters include:

• RAID type;

• disk order;

• stripe or block size;

• sector size;

• data offset;

• parity layout.

For the PERC H700 configuration used in our example, the RAID Constructor shows:

• RAID 6 (Dual parity)

• Left Synchronous

• 64 KB block size

• 512 bytes per sector

These values should not be considered universal settings for every PERC H700 array. The original configuration can use different parameters.

The PERC H700 supports multiple stripe sizes, so the actual RAID geometry must be determined from the specific array being recovered. Your source article likewise notes that parameters can differ and should be verified rather than blindly assumed.

Reconstructing RAID 6 with Missing Disks

Suppose we have a four-disk RAID 6 and two members are unavailable.

Because RAID 6 provides dual parity, reconstruction may still be possible.

In RAID Constructor, add the available physical disks in their correct positions and use Empty disk entries for unavailable members.

Correct disk order is critical.

If the drives are arranged incorrectly, the RAID may technically be assembled, but the file system and files inside it will not be reconstructed correctly.

Once the parameters and disk positions have been specified, the complete configuration can be added to the application's list of RAID arrays.

Finding Unknown RAID Parameters

A common recovery scenario is having all or most of the disks but no record of the original RAID configuration.

You may know that the server used RAID 5 or RAID 6 while not knowing:

• the exact disk sequence;

• stripe size;

• offset;

• parity rotation.

Instead of manually testing every combination, the RAID Constructor can search for possible configurations.

The reconstructed results provide an important way to validate the configuration.

A promising configuration should reveal:

• expected partitions;

• a recognizable file system;

• meaningful directory names;

• realistic file sizes;

• files that can be previewed successfully.

Do not evaluate the reconstruction only by whether a partition appears. Verify the actual files as well.

Recovering the Files

Once the RAID has been assembled correctly, open the reconstructed logical volume and scan it.

The resulting array appears as a virtual storage device even though one or more physical members may be missing.

After scanning, navigate through the recovered directory structure and preview important files.

When the correct data has been identified, select the required folders and files and start the recovery process.

Always save the recovered data to another healthy physical storage device.

Do not save it back to the disks that belong to the original RAID.

Video Walkthrough

The complete procedure is also demonstrated in our video:

How to Recover Data from RAID 5, RAID 6, and RAID 0 Arrays Created on a Dell PERC H700 Controller

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

The video demonstrates:

• RAID 0, RAID 5, and RAID 6 scenarios;

• connecting RAID member disks;

• automatic RAID detection;

• disk-image workflows;

• manual RAID reconstruction;

• working with missing disks;

• determining unknown RAID parameters;

• scanning the reconstructed array;

• recovering files.

Practical Recovery Checklist

If a Dell PowerEdge server or PERC H700 RAID fails, a conservative workflow is:

1. Stop using the array.

2. Do not initialize, format, or recreate its disks.

3. Record the original drive order.

4. Check which physical disks are available.

5. Create disk images where possible.

6. Connect the disks or images to a separate workstation.

7. Attempt automatic RAID detection.

8. Verify the reconstructed file system and files.

9. If necessary, use RAID Constructor.

10. Determine the correct disk order, stripe size, offset, and parity configuration.

11. Scan the reconstructed logical volume.

12. Preview files to validate the configuration.

13. Recover the required data to another drive.

Key Takeaways

A failed Dell PERC H700 controller does not necessarily mean that the information stored on its RAID array has been lost.

Remember these basic rules:

• RAID 0 requires every member disk for complete recovery.

• RAID 5 can normally survive one missing member.

• RAID 6 can normally survive two missing members.

• The original RAID controller is not always required to reconstruct the array.

• Do not initialize disks when Windows prompts you to do so.

• Disk order, stripe size, offset, and parity layout can be critical.

• Work from disk images when drive condition is questionable.

• Verify the RAID reconstruction by previewing actual files.

• Never save recovered data to the source RAID.

Finally, RAID redundancy should never be treated as a replacement for a backup. RAID is designed primarily to provide storage availability after certain hardware failures; it cannot protect against every form of data loss.

For a more detailed step-by-step demonstration with screenshots, see the original technical guide on the Hetman Software website.