Case file · NAS & RAID · BDR-2025-1103
A RAID Five Against the Clock.
The call was all verbs: a RAID 5 recovery job
, disks ready — get the disks to you today
— and a business deadline of close-of-play at the weekend. What they wanted before committing was the honest version of confidence on price and timing
, not bravado.
Same symptoms on your desk?
01273 964902
The decode.
Deadlines change scheduling, not method. The corner that never gets cut is imaging: reconstructing directly from original members risks the client's array to save hours, and if a member fails mid-rebuild there is no second attempt. Speed on a time-critical array comes from parallelism — imaging every member simultaneously rather than sequentially — and from deriving geometry while the copies are still running, so no time is spent waiting.
Equipment on this case.
How a case runs →| Platform | What it did here | Why this tool |
|---|---|---|
| Atola TaskForce 2 | Imaged all members simultaneously — the single biggest time saving available | Images many drives at once — the difference between days and a week on an array |
| PC-3000 Portable PRO | Firmware-level access brought to the drives rather than the drives to it | The same firmware-level access, in a form that travels to the drive |
| UFS Explorer RAID Recovery | Derived stripe size, member order and parity rotation from the images | Reads NAS volume managers as they actually are, not as a flat array |
On the bench.
Everything onto imagers at once
All members went onto imaging hardware in parallel the moment they arrived. Sequential imaging of a multi-drive array is what turns a three-day job into a week, and parallel capacity is the difference between meeting a Friday deadline and explaining why you didn't.
Derive the geometry while the copies run
Array parameters were established from the metadata on the first completed images rather than waiting for the full set — stripe size, member order, parity rotation and delay, all verified against actual data patterns rather than assumed from the controller's defaults.
Reconstruct, then verify against what the business needs first
The volume was assembled virtually across the images and the filesystem parsed. Verification was ordered by business priority — the shares they'd told us they needed for Monday were checked first, so a green light could be given before the whole set had finished validating.
The outcome.
The reconstructed volume verified and handed over inside the weekend window. The business opened Monday on its own data — recovered at pace, with nothing skipped to achieve it, and progress reported at every stage boundary rather than promised.
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.