Chapter 10 — Key Takeaways

The big idea

On a RAID, your data is not on any single disk — it is an emergent property of how the members are combined. A file system describes a logical volume that physically exists nowhere; it appears only when the right disks are assembled in the right order, with the right strip size, the right parity rotation, and the right starting offset. Recovery is therefore the disciplined act of rediscovering six parameters and assembling the volume in software, from images of the bare disks, without the original controller — and then verifying the result by opening real files, never by trusting the first plausible boot sector. The original is sacred, and on a RAID the original is all the disks at once.

How each level fails

Beyond the redundancy budget — two members in RAID 5, three in RAID 6, both members of a RAID 10 pair — the math is final; your only remaining move is physically resurrecting one more member.

The six parameters of any striped array

• Member set — which disks belong, and is one stale (lower event counter)?
• Disk order — the stripe sequence, which is not the bay order.
• Strip size — per-disk chunk; beware the "stripe size" factor-of-N trap.
• Parity layout — direction + symmetry; left-symmetric is the mdadm default and the one you will meet most.
• Start offset — where array data begins; --assemble honors it, --create guesses it.
• Special rules — parity delay, mdadm near/far/offset, nesting, reshape-in-progress.

Read these from metadata when you can (mdadm magic 0xA92B4EFC, DDF 0xDE11DE11, Intel IMSM); derive them empirically when you cannot.

The rule that saves arrays

• The forced rebuild is the most common RAID disaster. A degraded array has zero redundancy; a rebuild forces a full-surface read across aging, same-batch disks and surfaces a latent URE — turning one recoverable failure into two unrecoverable ones.
• Image every member first — including the "failed" one — behind a write-blocker, with a bad-sector-tolerant imager, then reconstruct virtually from copies.
• Never mdadm --create or controller-Initialize on originals. Those are write operations; one wrong click overwrites the data you came to save.
• A powered-off degraded array is stable; a rebuilding one is at maximum risk. When in doubt, stop.

Recovery vs. forensics

Same array, same six parameters, two postures. The recovery tech reconstructs to get files back and is done when they open. The examiner reconstructs to get admissible files back and is done only when the reconstruction is hashed, documented, scoped, and reproducible by a second examiner — because in court, how you combined the disks is part of your method.

You can now…

• ☐ Explain how RAID 0/1/5/6/10 fail and how many members each can lose before redundancy runs out.
• ☐ List the six parameters of a striped array and read them from metadata or derive them empirically.
• ☐ Reconstruct a single missing RAID 5 strip by XOR — and explain why two missing strips cannot be.
• ☐ Drive ReclaiMe, R-Studio, UFS Explorer, and mdadm/losetup, avoiding the --create/Initialize landmines.
• ☐ Recognize and prevent the forced-rebuild cascade, and reconstruct an array reproducibly enough to defend as evidence.

Looking ahead

Chapter 11 — Mobile Device Recovery. We leave spinning platters and parity behind for the locked, encrypted, soldered-flash world of phones and tablets, where the target is a single device that fights you at every layer.

One sentence to carry forward: On a RAID, the original is all the disks at once — image every one before you touch anything, because the rebuild, not the failed disk, is what kills arrays.