Nearly every array that reaches this bench lost its first disk weeks before anyone noticed, because redundancy keeps everything working while quietly spending the margin that protects you. By the time the volume vanishes, the failure people remember is the second one. That history matters: it determines whether a rebuild is safe to attempt, and attempting one on an array that has already been degraded for a month is the single most common way the data goes from difficult to unrecoverable.
$ cdr diagnose /dev/raid → Array: RAID 5 · 6 × 4 TB · 20 TB volume → Status: OFFLINE — 2 disks failed, rebuild failed → Client: confidential · Cambridge CB2 $ cdr engineer-working → Member disks: all 6 imaged read-only → Parameters: order + stripe + parity solved → Array: rebuilt virtually from images $ cdr verify → ✓ databases — 412 GB → ✓ shares + VMs — 17.8 TB → ✓ array recovered — data back
Understanding this changes what you do next, and it is the single most useful thing on this page.
Redundancy works by absorbing a failure silently. When the first disk goes, the array keeps serving data exactly as before — no interruption, no error anyone sees, often nothing but an email nobody read or a light on a chassis in a cupboard. The system carries on, protected by nothing.
Weeks or months later a second disk fails and the volume disappears. That is the failure people remember and report, and it is why so many arrays arrive here having been degraded far longer than anyone realised.
The practical consequence: by the time you know there is a problem, the margin is already spent. A rebuild at that point is the highest-risk operation available, because it loads every surviving disk at full surface for hours — and those disks are the same age, from the same batch, with the same hours on them as the ones that already died.
Where the controller is gone and nobody documented the configuration, all four of these have to be worked out from the member disks themselves. That derivation is most of the job.
Bay order is not always array order, particularly after a chassis move or a disk swap. Deriving it means finding parity relationships that only hold in the correct sequence.
Ranges from 4 KB to 1 MB depending on controller and configuration. The wrong value produces data that looks almost right, which is worse than data that looks obviously wrong.
Several conventions exist and controllers do not agree. Establishing which was used is essential before any missing member can be reconstructed from parity.
Controllers reserve space at the start of each disk for their own metadata, and how much varies by vendor. HP Smart Array in particular uses an offset that catches out generic tools.
The distribution corridor from Huntingdon through to Milton Keynes sends the largest and most time-critical array work we handle — warehouse management and stock systems on RAID 5 and 6, where an operation that cannot see its inventory loses money by the hour. These arrive as genuine emergencies and are the reason the lab keeps enterprise SAS spares rather than ordering them in.
The science parks send a different problem: arrays assembled by capable people who are not storage specialists, often with no record of the original stripe order or controller settings. And from the fens come arrays out of process and monitoring systems, usually older and usually with at least one disk that failed months before anybody noticed.
Send everything, in order. Every disk including the one that failed first, labelled by bay, plus the controller if you still have it. A RAID 5 missing two members cannot be reconstructed — there is no parity left to work from.
RAID and array recovery starts at £500 +VAT regardless of level, member count or controller. The figure is fixed in writing after the free 48-hour diagnostic and does not change afterwards.
Where individual members need clean-air work before the array can be assembled, that is identified at the same diagnostic and quoted then rather than appearing later as an extra.
Usually not. The second disk has often only been ejected for a timeout rather than failing outright, and its data may be almost entirely intact. Both are imaged individually and the array assembled from the images.
No. A rebuild is the highest-risk operation you can run on a degraded array — hours of full-surface load on disks the same age and batch as the ones that already failed. If the data matters more than the uptime, image first.
Expected, and it is most of what we do. Disk order, stripe size, parity rotation and start offset are all derived from the member disks themselves by finding the arrangement where the parity mathematics holds.
Send it if you have it. It is not essential — the configuration is derivable from the disks — but knowing the make and generation shortens the work and reduces what has to be established by trial.
Send the disks rather than the server if you can, labelled by bay. The chassis, backplane and motherboard are rarely relevant; what matters is the disks and the order they were in.
Five to ten working days typically. Each member is imaged individually first, which on large modern disks accounts for most of the elapsed time, and reconstruction only begins once every image is complete.
From £500 +VAT, quoted once we have seen the members. Every disk imaged read-only and the array rebuilt away from the controller that lost it — and if the unit is still powered and offering to rebuild, switch it off before anything else.