Hex-Level RAID De-Striping and Controller-Independent Recovery

What Is Controller-Independent RAID Recovery?

The phrase "you need the original controller" is a myth that costs people their data. Modern controllers write the structural metadata that defines an array onto the member drives themselves, so a dead card does not take the geometry with it.

We image each member once through a write-blocker, read or derive the geometry, and assemble the array in software against the image files. The original drives are never re-striped, never rebuilt, and never written to.

What Is Hex-Level De-Striping?

A striped array interleaves data across members in fixed-size chunks. To read it back, you need four numbers: which members are present and in what order, how large each chunk is, where the data region starts on each member, and how parity rotates between rows.

When the metadata is intact those numbers come straight from the on-disk headers. When it is gone, they come from the bytes. The snippet below is an illustrative, generic view of an LVM2 PV header region of the kind we read at the start of a physical volume; it does not represent any customer's data.

00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00   LABELONE........
00000210  20 00 00 00 4c 56 4d 32  20 30 30 31 78 7a 41 62    ...LVM2 001xzAb
00000220  43 64 45 66 47 68 49 6a  4b 6c 4d 6e 00 10 00 00   CdEfGhIjKlMn....
00000230  00 e0 0f 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
# illustrative LABELONE / "LVM2 001" PV label at the start of the physical volume

The LABELONE magic and the LVM2 001 type string mark an LVM2 physical volume. On an mdadm member the analogous landmark is the superblock magic 0xa92b4efc; on an ext4 filesystem inside the array the superblock magic 0x53EF sits 1080 bytes into the partition. We use landmarks like these to confirm a candidate geometry: if the math is right, known signatures land where they should.

How Do You De-Stripe a Nested RAID 50 or RAID 60 Array?

A nested array stacks two RAID levels. The outer tier is a RAID 0 stripe that distributes rows across multiple inner sets, and each inner set carries its own redundancy. RAID 50 nests inner RAID 5 sets under the outer stripe; RAID 60 nests inner RAID 6 sets. Both fall under our RAID data recovery service, and the inner spans are reconstructed with the same parity methodology as the corresponding single-array levels.

Outer tier (RAID 0 span set)

The outer RAID 0 layer defines span width, span count, and the member ordering across spans. Those boundaries come from the on-disk DDF on the trailing sectors of PERC and MegaRAID members, or the HP RIS in GPT partition 9 at the start of each member, exactly as on a single-level array. When that metadata is destroyed, span boundaries are reverse-engineered from block-level entropy and boundary analysis, because parity-block entropy and the synchronization point reset at each span transition.

Inner tier (independent parity spans)

Each inner span is its own redundancy group and is reconstructed independently. An inner RAID 5 span uses single XOR parity across its data chunks; an inner RAID 6 span uses the P and Q syndromes of Galois-field GF(256) Reed-Solomon coding, so a span can survive two member losses where a RAID 5 span survives one.

The reconstruction sequence runs from the outside in, then validates both tiers before any data is read:

1. Resolve the outer RAID 0 geometry first: span width, total span count, and member ordering across the spans.
2. Reconstruct each inner span on its own math, XOR for RAID 5 spans and P plus Q GF(256) for RAID 6 spans, treating the spans as separate redundancy groups.
3. Validate both tiers by XOR parity consistency within each inner span and by confirming filesystem anchor offsets land where the combined two-tier geometry predicts.
4. Only after both tiers validate does file extraction begin against the reconstructed virtual volume.

The destructive failure mode is reconstructing the independent inner spans as one continuous stripe. That collapses the span boundaries, lands chunks at the wrong offsets, and corrupts data that was otherwise intact. Every step runs on read-only clones, with each member imaged before assembly, because the URE physics that govern a single parity array govern a nested one as well.

How Do You Identify and Recover a RAID Write Hole From Cache Dropout?

The RAID write hole is a parity-divergence condition, not a media defect. A hardware controller buffers writes in DRAM cache and updates the data and parity members of a stripe as a unit.

If power is lost partway through that update, the dirty cache is never flushed, so the data members carry the new write while the parity member still holds the old value. The stripe is left XOR-inconsistent: the XOR of the data-member sectors does not equal the parity-member sector.

We identify the affected stripes by verifying every stripe set by XOR across the cloned images. Any stripe whose data-member XOR does not match its recorded parity sector is flagged as dropout-corrupted. This is a diagnostic pass over the image files, run in software against the clones, never against the live members.

1. Run a per-stripe XOR verification across the cloned member images to find stripes where the data-member XOR and the recorded parity sector diverge.
2. Flag those divergent stripes as cache-dropout write-hole stripes.
3. On a non-degraded array the data members hold the committed, newer write, so read the data directly from the data-member sectors of the flagged stripes.
4. Mark each such stripe recovered-without-parity-validation, because the stale parity cannot be used to validate those stripes or to reconstruct a missing member within them.

The integrity limit is specific: on the flagged stripes, data is read straight from the data members and parity is unusable only for validation and for reconstructing a missing member within those stripes. The rest of the array validates normally. This is the same offline methodology we use across RAID 5 recovery, where parity inconsistency, not drive death, is the reason the array went offline.

Whether a stripe survives the power event at all depends on how the controller protected its cache. The two mechanisms behave differently:

Lithium-ion BBU (battery backup unit)

A lithium-ion battery only holds the DRAM cache contents under battery power. It keeps the dirty cache alive on the order of one to a few days, and once the battery is exhausted the unflushed contents are lost. Older controller generations, such as the Dell PERC H710 class, use this approach.

Supercapacitor cache-vault (FBWC)

A supercapacitor cache-vault, the style used by LSI and MegaRAID CacheVault, does not try to hold DRAM under power. On power loss the supercapacitor supplies a burst that flushes the DRAM cache to onboard NAND flash, where it survives far longer than a battery can hold it. Later generations, such as the Dell PERC H730, H740P, and H755 class, use this approach.

Cache-protection state changes the odds of a clean stripe, not the recovery method. The URE risk on the surrounding members stays probabilistic: the chance of an unrecoverable read error rises with the volume of bits read, which is why the clone-first workflow applies to a write-hole array as much as to a degraded one.

RAID De-Striping Terms, Defined

XOR Parity

A bitwise exclusive-OR computed across the data chunks in a stripe row. A missing data chunk is recovered by XORing the surviving chunks with the parity chunk. The XOR of all blocks in a consistent stripe equals zero, which is how we validate a candidate geometry.

Parity Rotation

The pattern by which the parity chunk moves between members from one stripe row to the next, classified as left-symmetric, left-asymmetric, right-symmetric, or right-asymmetric. Symmetric layouts continue data after the parity position; asymmetric layouts place data in fixed disk order.

Stripe and Chunk Size

The chunk (or stripe element) size is the amount of contiguous data written to one member before the array moves to the next. Common values are 64 KB, 128 KB, and 256 KB; HP Smart Array defaults to 256 KB. The full stripe is one chunk per data member.

Unrecoverable Read Error (URE)

A sector that a drive cannot read back, rated at roughly one per 10^14 bits on consumer drives. During a degraded rebuild a URE means a stripe cannot be reconstructed, which is why de-striping is done on read-only clones rather than live members.

DDF (Disk Data Format)

A SNIA on-disk metadata format written to the trailing sectors of each member by Dell PERC and LSI/Broadcom MegaRAID controllers. It records member order, stripe size, and parity rotation, allowing controller-independent reassembly.

RIS (RAID Information Sector)

The HP Smart Array proprietary metadata region, written at the start of each member inside GPT partition 9 rather than at the trailing sectors. It carries the array geometry HP controllers use, with a 256 KB default stripe size.