Use a RAID 6 recovery route only after identifying the actual members, layout and state. Begin with a complete, identifiable array that can be read. RAID 6’s parity design is not a promise that a file-recovery application can reconstruct any two missing disks or understand every controller implementation.
Preserve the failure history
Record member identities and original slots, the array configuration, the platform’s reported state and the sequence of disk failures or replacements. Use the member and image record to connect each input to its original role. Keep controller or NAS logs where available. An interrupted rebuild or later write may mean the members no longer represent one consistent point in time.
Do not initialize a new array, clear foreign-configuration information or repeatedly retry rebuilds while looking for files. Preserve the original set and separate any images or acquired copies from recovery output. Document unreadable regions rather than treating an image’s full size as proof of a complete read.
Confirm the supported source
Determine whether the original platform offers a stable logical volume or whether a supported reader must interpret preserved inputs. Confirm the known layout and correct member set before proceeding. If essential information is missing, stop that route and obtain an assessment rather than presenting a guessed reconstruction as established.
XRecovery’s documented RAID scope includes identifiable, readable RAID 6. It does not establish arbitrary dual-disk-loss reconstruction, all parity layouts or repair of a failed controller. RAID 6 uses two parity components per stripe. The recorded layout includes how data and parity are placed across members, so preserve the original controller metadata along with disk order and chunk size. A RAID 5 layout assumption is insufficient for a RAID 6 source; see the Linux MD layout documentation for one implementation’s separate RAID 5 and RAID 6 layout choices.
Export and validate content
Use a different storage destination. For a recognized source in XRecovery, follow the RAID source workflow. Inspect representative directories and export the files that matter. Check actual content in the intended application, including larger files and dependencies; names and a plausible directory tree are insufficient on their own.
Keep the original exported bytes while performing repair or consistency checks on copies. Record the source and checks for each useful output. Hash equality against a known-good original can establish an identical file; without that reference, the hash identifies the export but cannot prove it matches the lost original.
Example: assess a candidate from a readable RAID 6
Imagine a complete, identifiable RAID 6 source with the original member and layout records available. After selecting the recognized volume, export an important spreadsheet and a large archive to separate storage. Open the spreadsheet and test the archive’s required members; keep unmodified exports alongside the inspection notes. If the archive is inconsistent while the spreadsheet opens, preserve both results and investigate the input and layout before attempting source repair.
Know when to stop
Unstable reads, missing members, uncertain order or content inconsistent with the expected source require further investigation. Resolve the member and layout uncertainty before another scan. If the recorded parameters cannot be established, preserve the inputs for assessment.
Once important files are protected, decide separately how the array should be repaired, replaced or retired. Keep the original source unchanged until a separate repair plan has been established.
For the next step, see RAID File Recovery: Identify the Array Before Choosing a Route.