The array won’t mount, the volume reads as RAW, or the controller flags the set as failed — yet the disks themselves spin up fine. That gap is the whole story of RAID corruption: the data is usually still there, scattered intact across healthy disks, and the thing that has broken is the logic that tied them together. Which is exactly why the instinctive fix — rebuild, re-initialise, let the controller sort it out — is the move that turns a recoverable array into a lost one.
A corrupt array is a logic problem sitting on top of healthy disks. Write to those disks and you overwrite the thing you’re trying to save.
A RAID presents several physical disks as one volume, and it does that with metadata: which disk holds which stripe, in what order, with what block size, and — on parity levels like RAID 5 and 6 — a running checksum that lets a missing disk be recalculated. ‘Corruption’ is when that layer stops making sense while the disks underneath are physically fine: parity that no longer matches the data, array metadata that’s been lost or overwritten, or a filesystem on the assembled volume that’s been damaged. It is a fundamentally different problem from a dead RAID disk, and it’s treated differently — the members are the good news here, not the bad.
A handful of causes account for most of it. A rebuild gone wrong after a disk swap writes bad parity across the whole set. A controller or RAID card fails, or its firmware garbles the configuration. Power is lost mid-write and the parity and data fall out of step — the classic ‘write hole’. A disk is dropped and marked failed, then a second falls offline before anyone notices. Or a controller is replaced and the new one can’t read the old array’s metadata. In a NAS or a server, the same faults wear different badges but break the array the same way.
This is where recoverable becomes lost. Do not re-initialise or re-create the array to ‘fix’ it — that writes fresh metadata over the map you need. Do not let the controller auto-rebuild onto the original disks; a rebuild computes and writes new parity, and if it starts from the wrong assumptions it overwrites real data on the way. Do not run chkdsk or fsck against a corrupt volume — a repair tool asked to ‘fix’ a misassembled filesystem can shred it. And don’t reorder, relabel or swap the disks around to see what mounts. Every one of those actions writes to the members, and the members are the only copy you have.
The bench does the opposite of the controller. Every member disk is first imaged read-only — a full sector-by-sector clone — so nothing that follows can touch the originals, and any disk that is genuinely weak gets handled gently while it’s copied. The array is then reconstructed virtually from those images: the correct disk order, block size, parity rotation and start offset are worked out until the stripes line up and a coherent filesystem appears. Only then is your data extracted — from the copies, with the originals sitting untouched in case a second pass is needed. A member that has partly failed is no longer a blocker; it’s just an image to work from.
Array reading as RAW, a rebuild that stalled, or a controller telling you it’s all gone? Before you re-initialise anything, stop — the diagnostic is free, the quote is fixed in writing, and a straight answer on 0131 202 0491 costs nothing at all.