Hex-Level RAID De-Striping and Controller-Independent Recovery
When a RAID controller dies, gets replaced with the wrong firmware, or wipes its own configuration, the array goes dark even though every drive still holds its data. We reconstruct the array offline, without the original card, by reading the geometry that hardware and software RAID write directly onto the member drives, then de-striping write-blocked clones at the byte level.
All work is performed at our single lab in Austin, TX. This is cross-level forensic methodology for parity arrays; for the level page see RAID 5 recovery, and for the broader service the RAID data recovery hub. Free evaluation. No diagnostic fees. No data recovered means no charge.
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.
Why Can a RAID Array Be Rebuilt Without the Original Controller?
- Dell PERC and LSI/Broadcom MegaRAID
- These controllers write a SNIA DDF (Disk Data Format) variant to the trailing sectors at the end of each member. The DDF structure records member count, stripe element size, parity rotation, and the virtual disk GUID that ties members to their parent array. We read those trailing sectors from each clone before any assembly decision. See our Dell PERC recovery and LSI MegaRAID recovery pages for controller-specific handling.
- HP Smart Array
- HP Smart Array controllers do not use DDF. They write a proprietary RAID Information Sector (RIS) at the start of each member, carried inside GPT partition 9, with a default stripe size of 256 KB. Because the RIS sits at the start rather than the end, the parsing offset differs from DDF and a tech who assumes DDF on an HP array reads filesystem data instead of metadata. Our HP Smart Array recovery workflow accounts for that.
- Linux mdadm
- Software RAID under mdadm writes a superblock to each component device. Version 0.90 places a 4 KB superblock at a 64 KB boundary near the end of the device; version 1.2 places it 4 KB from the start; version 1.1 sits at the very start and 1.0 at the end. The superblock dictates exact geometry, which we read with
mdadm --examine. - LVM2
- LVM2 writes a text-based metadata header at the start of each physical volume, defining the volume group, physical extents, and logical volumes. Because it is human-readable text, the volume layout can be reconstructed from the PV header even when the array underneath it has lost its own configuration.
This is why the original card is convenient but not mandatory. The structural truth of the array is on the platters, and it survives the controller. For the underlying parity theory, see how RAID parity works.
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 volumeThe 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 Determine Stripe Size, Member Order, and Parity Rotation?
The first move on any Linux software array is to examine the superblock on each member:
# read the mdadm superblock on each member (run against clones, read-only)
mdadm --examine /dev/sdb
mdadm --examine /dev/sdc
mdadm --examine /dev/sdd
# fields that matter: Raid Level, Chunk Size,
# Device Role (member order), Data Offset, Layout (parity rotation)When the metadata is gone, geometry is reverse-engineered from the data. Stripe and chunk boundaries show up as shifts in block-level entropy: a parity chunk is the XOR of the data chunks in its row, so it carries higher, flatter entropy than structured filesystem data, and the position where that signature jumps from one member to the next reveals both the chunk size and the rotation direction.
File signatures and filesystem structures that run sequentially across members let us confirm member order and the data start offset. The parity rotation belongs to one of four families:
- Left-symmetric
- Parity rotates right to left across rows, and data continues on the drive after the parity drive. The most common layout for Linux mdadm RAID 5.
- Left-asymmetric
- Parity rotates right to left, but data fills the non-parity drives in fixed disk order rather than continuing after the parity position.
- Right-symmetric
- Parity rotates left to right across rows, with data continuing after the parity drive.
- Right-asymmetric
- Parity rotates left to right, with data placed in fixed disk order. Common on several hardware controller defaults.
Why Must De-Striping Happen on Read-Only Clones?
A degraded RAID 5 has no parity to spare. If the controller hits an unrecoverable read error on a surviving member while rebuilding the missing one, it cannot reconstruct that stripe and many controllers abort the entire rebuild.
The probability of meeting a URE rises with the number of bits read, so on larger arrays the odds work against a clean live rebuild. This is a probabilistic risk, not a guarantee in either direction, but it is exactly why we never bet a live array on it.
Every member is imaged through hardware write-blockers before any reconstruction. We use PC-3000 Express, PC-3000 Portable III, DeepSpar Disk Imager, and ddrescue with adaptive retry so weak sectors are captured without further stressing the original drive.
A URE that lands during imaging costs us a sector on a clone, not the array. De-striping and parity validation then run against the image files, so the original members are read once and never touched again.
If your array is degraded or a rebuild aborted: Power down. Do not retry the rebuild, reinitialize, or import a foreign config. Label each drive with its slot number. Then contact us for a free evaluation.
How Do We Reconstruct Your Array?
- Evaluation. We record member count, controller family (Dell PERC, LSI/Broadcom MegaRAID, HP Smart Array, Linux mdadm, LVM2), the reported failure, and the filesystem. This step is free and there is no diagnostic fee.
- Write-blocked member imaging. Each member is cloned through hardware write-blockers on PC-3000 Express, PC-3000 Portable III, DeepSpar Disk Imager, or ddrescue. Mechanically failed members get head swaps on a 0.02 micron ULPA-filtered clean bench before imaging. The imaging hardware reads sectors from the members; it does not assemble or rebuild anything.
- Metadata extraction and geometry determination. From the image files we read DDF on the trailing sectors for PERC and MegaRAID, the RIS in GPT partition 9 for HP Smart Array, the mdadm superblock, or the LVM2 text header. When the metadata is destroyed, geometry is derived by block-level entropy and boundary analysis across the clones.
- Virtual array assembly. The array is assembled virtually in software against the image files using Data Extractor Express RAID Edition, or with
mdadm --assemble --readonlyfor Linux software arrays. The live member drives are never assembled or rebuilt. - Parity validation. The candidate geometry is checked by XOR parity consistency across stripes and by confirming that filesystem anchor points (ext4 superblock magic 0x53EF, XFS allocation group headers, NTFS MFT records) land at the predicted offsets. A wrong geometry produces noise at those offsets.
- Read-only filesystem extraction. The reconstructed virtual volume is mounted read-only and files are extracted. Priority data is verified first.
- Verification and delivery. Recovered data is copied to your customer-provided destination drive. Working copies are purged on request.
# assemble a Linux software array from clones, read-only, never writing to members
mdadm --assemble --readonly /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde
# if the superblocks are inconsistent, build read-only from explicit geometry instead
# (chunk size, layout, and device order taken from the --examine output above)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.
How Much Does Controller-Independent RAID Recovery Cost?
Pricing is the aggregate of per-member imaging plus an array reconstruction fee of $400-$800. Each member drive is imaged and priced individually at the HDD tier, then the array is reassembled virtually in-house. If we recover nothing, you owe $0.
Per-Member Imaging
- Logical or firmware-level issues: From $250 per drive for filesystem-level imaging, rising to $600–$900 per drive for firmware module damage that needs PC-3000 terminal access.
- Mechanical failures (head swap, motor seizure): $1,200–$1,500 per drive with a 50% deposit, plus donor parts. Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
Array Reconstruction
- $400-$800 depending on member count, filesystem (mdadm, LVM, XFS, EXT4, Btrfs, ZFS, NTFS), and whether geometry comes from surviving metadata or must be derived from raw entropy. Virtual assembly runs in Data Extractor Express RAID Edition against the cloned images.
- A +$100 rush fee to move to the front of the queue is available.
No Data = No Charge: If we recover nothing from your array, you owe $0. Free evaluation, no diagnostic fee.
In-house: Imaging, geometry determination, and virtual reconstruction are all done at our single Austin, TX lab. No outsourcing.
Controller-Independent RAID Recovery Questions
Do you need the original RAID controller to recover the array?
What happens if the controller metadata is wiped?
Is rebuilding a degraded RAID 5 array safe?
Can you recover after a failed or aborted rebuild?
What tools do you use for controller-independent RAID recovery?
How much does controller-independent RAID recovery cost and how long does it take?
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.
See our clean bench validation data and particle test videoDead controller? The geometry is still on your drives.
Free evaluation. Offline reconstruction from write-blocked clones. No data = no charge. Mail-in from anywhere in the U.S.