Case file · NAS & RAID · BDR-2025-0642
Two Failed Drives in a RAID 5 Array.
An enterprise storage shelf with a familiar wound: two failed drives in a RAID 5
. The owner had spare disks
ready and a reasonable-sounding question — could the array be rebuilt from one disk to another
? The spares were the temptation; the question was the trap.
Same symptoms on your desk?
01273 964902
The decode.
RAID 5's arithmetic tolerates exactly one absence. At two, the controller cannot compute what's missing, and any attempt to rebuild onto spares writes fresh parity across stripes that reconstruction needs to read precisely as the failure left them. There's a second trap in enterprise shelves specifically: the drives frequently use non-standard sector sizes and vendor-formatted layouts that generic tools misread entirely. The spares' correct role was to receive the ending, not to participate in it.
Equipment on this case.
How a case runs →| Platform | What it did here | Why this tool |
|---|---|---|
| PC-3000 SAS/SCSI | Addressed the enterprise SAS members that desktop hardware cannot talk to | Enterprise SAS and SCSI members that desktop hardware can't address |
| Atola TaskForce 2 | Parallel imaging of all members, compressing a week of sequential work | Images many drives at once — the difference between days and a week on an array |
| UFS Explorer RAID Recovery | Derived the array geometry and assembled the volume from the images | Reads NAS volume managers as they actually are, not as a flat array |
On the bench.
Image every member — including the survivors
All members went onto imagers, the failed pair alongside the healthy ones. Enterprise SAS drives need hardware that speaks their interface properly, and the shelf's vendor sector formatting had to be handled correctly at the imaging stage or every subsequent step would have been built on nonsense.
Recover the failed members enough to read them
The two failed drives were assessed and brought back to a readable state — the usual finding held, with neither uniformly dead and most of each surface intact. Imaging both meant reconstruction could later choose the best copy of any given block rather than depending on parity alone.
Derive the geometry, assemble in software
Stripe size, member order, parity rotation and delay were established from the on-disk metadata rather than assumed from defaults. The volume was then assembled virtually across the images and the filesystem parsed from the reconstruction.
The outcome.
The array's data reconstructed and verified, then delivered onto the owner's spare disks as fresh storage — their first and only job in the affair, and a much better use for them than the rebuild that nearly happened.
Related on the index.
More from NAS & RAID.
Recognise your own drive in this story?
Same rule as every case above: power it down, and let the diagnosis be free before any decision has to be.