Data Recovery Case File · NAS & RAID · The Spare That Never Fired

"A safe method to rebuild and access the data" — the safe method is not rebuilding: seven imaged members, one grinding bearing spared the ordeal, and the volume reassembled where it can't be hurt

His enquiry read like a good incident report. A seven-disk RAID 5EE volume has failed; a hot-spare sits on the spare port of the hardware RAID card, but "the controller failed to activate it and rebuild the volume." Six drives "appear to be functioning normally"; the seventh has "an intermittent grinding sound that a colleague has said is likely a bearing issue when it is under load, but sounds normal when idling." He asked two things — "a safe method to rebuild and access the data, or a possible costing" — and one courtesy: email, please, around working hours. All three honoured. The central answer first, because it is the case's spine: the safe method is the one that never asks the grinding drive to survive a rebuild. A rebuild is the most punishing sustained workload an array can impose — hours of full-surface reading from every member at once — and it would be aimed squarely at the disk least able to bear it. The controller's refusal, whatever its internal reasoning, landed on the right side of history.

The decode: what 5EE changes, what the grinding means, and why the rebuild is the trap

5EE, briefly and honestly: in this variant the spare capacity isn't a disk waiting on the sidelines — it's woven through the stripe set itself, distributed across the members alongside data and parity. "Activating the spare" is therefore not a simple swap-in but a live reorganisation of the whole array. That makes the layout subtler to reconstruct than a plain parity set — and makes an automatic rebuild an even heavier, longer, less interruptible ordeal for every member involved.

The colleague's diagnosis, graded: load-dependent grinding that idles quiet is exactly the presentation of a mechanical component in early distress — struggling precisely when the heads are asked to work. Full credit; it's a sound piece of listening. It is also the whole argument against rebuilding: a rebuild would demand from that drive many consecutive hours of the very activity that makes it grind. Parity arrays have a brutal arithmetic — already degraded, the loss of one more member during the ordeal ends the mathematics entirely. The gamble risks everything to win convenience.

The controller's refusal, reframed: whether it declined out of detected member instability or an inconsistent array state, treat the refusal as information rather than obstinacy. Overriding a controller's hesitation with force-online commands is one of this genre's classic self-inflicted wounds — and he did no such thing. He stopped and asked. That is why every option remained open.

The recovery: image first, rebuild nowhere, assemble where nothing can be hurt

Every member was imaged individually, write-blocked, on hardware imagers — the healthy six straightforwardly, the grinding seventh gently: easy regions first, error-tolerant handling, no punishing retries, the aim being to capture its surface once and never ask it to perform again. From that point the physical drives were out of the story. The array was reassembled virtually from the images: member order, stripe geometry and the 5EE layout derived analytically from the structures on the platters themselves, the volume brought up read-only from the reconstruction, and the filesystem walked and verified. Nothing was rebuilt onto physical disks; nothing needed to be.

The outcome

The volume's contents extracted and verified from the virtual assembly and delivered on new media — with a written account of which member was failing and how the array had been put back together. His costing question was answered the only honest way: free assessment first, then one fixed written figure including VAT for the recovery, under no-recovery-no-fee. And his working pattern was respected to the letter: the whole exchange ran by email, findings waiting in his inbox rather than interrupting his day.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.