Degraded quietly for months, and then the second disk went twenty minutes after the rebuild began. Or the controller failed and the configuration was inside it. A RAID data recovery service is not an occasional adventure here but ordinary weekly work: sets running 0, 1, 5, 6 and 10 come out of servers, workstations and NAS boxes, get copied before anything is attempted, and are reassembled in software, with firms that cannot trade seen first.
Every raid array job is diagnosed free. The quote follows in writing, fixed, before a screwdriver is picked up.
No fix, no fee all jobs except electronic and mechanical failures, chip level work, DVR and Forensic jobs. Full pricing is on the data recovery cost page.
The first job on any raid array is matching the symptom to the fault — and after twenty-odd years, these thirty account for very nearly everything that comes through the door.
The first failure was planned for. The rebuild then finishes off a tired second one, and that is the defining catastrophe of array recovery as well as our steadiest arrival.
Half-completed rebuilds poison the parity they were relying on. The reach of that damage is charted from images before any structure is touched.
Controllers take their configuration to the grave with them. Geometry is re-derived from the member drives directly, with no replacement card and no vendor utilities involved.
Months-old data forced back into a working set tears the file system apart along the seam where the two disagree. Unpicked at image level, where the disagreement can be examined rather than compounded.
A fresh configuration created over the top of a live one. Interrupt that initialisation early enough and a surprising proportion of what lay underneath survives.
A power event drops multiple members at once. Each drive receives its own repair and its own image before any group arithmetic starts.
Whole banks appear to die together when the chassis wiring is the real culprit. Diagnosis comes before alarm here, and it is usually the cheaper order as well.
The array mathematics checks out perfectly while the NTFS or ext4 sitting on top of it is in pieces. Parser-level rebuilding is what brings that home.
Removed in error and recoverable quickly, while the blocks it described remain unwritten. Time is the only genuine enemy in that scenario.
A flat cache battery and an outage leave the write hole open and the two of them out of step. Reconciled from images, where being wrong about something costs nothing at all.
H710s and P420s expire still holding the definition nobody wrote down. The layout is lifted off the member drives and the replacement-card theatre is skipped entirely.
The member with dead heads goes to the clean bench first and then rejoins the imaging queue with the others. Nothing moves forward without it, because a set is only as complete as its worst member.
Matched drives bought together for a small-business set wear at much the same rate. Imaging them in parallel outruns the second failure, and outrunning it is the entire game.
mdadm superblocks and Storage Spaces metadata go missing with remarkably little provocation. Both are rebuilt from the raw members, piece by piece and slowly.
A member that remaps sectors daily is failing gradually rather than suddenly, and gradual failure has an ending like any other. Imaged in time, the whole set lives; imaged late, some of it does not.
RAID 10 with both halves of a single mirror down defeats the design as written. Lab imaging will often lift one of those halves far enough to close the stripe, which is where the paper and the practice part company.
An automatic rebuild lands on a hot spare which has idled for years and quietly decayed throughout. Nothing unimaged is trusted here, and a spare is no exception.
One optimistic click against stale metadata will scramble the whole set. The real layout is read back off the member drives, which kept honest records the whole way through.
Members without error-recovery limits get ejected under load for taking too long over a bad sector. Imaged on hardware that is prepared to wait, then the set is reassembled.
Hypervisor builds lose their pool metadata to power cuts. The transaction history is walked backwards from complete member images until a consistent point turns up.
A scheduled consistency check is exactly the sustained load a marginal drive cannot carry, so it fails punctually, part way through the scan. Image before the next one is due rather than after.
Medium errors picked up during degraded running get written into parity as permanent scars. The punctures are charted from images and routed around.
The wrong sector format is refused membership, and forcing the point multiplies the wreckage considerably. At image level, sector sizes become negotiable in a way they never are on live hardware.
HBA or expander firmware that only half applied sheds drives in tired clumps over the days that follow. The hardware fault gets identified first, because the data was never the problem.
Two modules striped for the benchmark figures, no parity anywhere, and one module dead. Each one is recovered as an NVMe case in its own right and the stripe is sewn together from the images.
The alert emails went to an address that stopped being read when somebody left. The array has been running on borrowed redundancy for half a year, and the day the second drive goes is the day anyone finds out. Everything is imaged, including the drive the controller says is fine.
Nominally identical capacities differ by a few thousand sectors between models and generations. The controller refuses the replacement, somebody clears the configuration to make it accept one, and now there are two problems. At image level the size difference stops mattering.
Disks pulled from an older server and reused still carry array signatures from that server. A controller reading both sets makes decisions nobody intended. The true layout is established from the data itself rather than from whichever metadata shouted loudest.
JBOD and spanned sets have no redundancy at all — they simply write across the disks in sequence. Lose one and the file system is left with a hole in the middle. Files that lived entirely on the surviving members come back whole, and that is usually more of them than people expect.
One half of a RAID 1 quietly dropped out and the pair carried on unmirrored. When the live disk finally failed, the old half was pressed back into service, complete with a year-old copy of everything. Both are imaged, and the newer data is recovered from the failed disk rather than accepted as lost.
Before anybody works out what the layout used to be, each disk is duplicated from beginning to end and your originals never spin in an array again. Everything from there happens on the duplicates: disk order, stripe size, parity rotation and offset are deduced from the data itself, the volume is assembled in software on top, and the file system is read out of that assembly. A stale disk that dropped out of a RAID 5 months before anyone noticed; two losses in a RAID 6; nested 10s; a controller with no recollection of its own settings — none of that is out of the ordinary. And where the card itself is what died, no matching replacement need be hunted down, because the layout is recoverable from the disks rather than from the hardware that lost track of it.
Database failures make for the awkward calls. A SQL server whose disks quit in the middle of a write, transaction logs straddling the moment everything stopped, and a firm standing still behind all of it. That gets treated as its own discipline: the array is reassembled in software first, then the database files are repaired to a consistent state with the priority tables taken in order, so the business is working again well before the long tail has finished copying. Worth naming, too, are the three habits that destroy more arrays than any component failure manages. Forcing an offline disk back online. Rebuilding onto a unit that is already on its way out. And letting one more person try one more thing. If an array is down: switch it off, mark each disk with the bay it came from, and ring before anything else happens to it.
One rule governs RAID work here, which is to image everything before anything gets touched, and it has never yet been set aside for anybody:
Every member is cloned at the same time on dedicated hardware before anybody offers a theory. All the rebuild risk lands on copies while the originals sit and watch.
Order, stripe size, rotation and offset are worked out from the images, then the array is stood up virtually. The geometry gets demonstrated rather than assumed.
A failed member becomes a full mechanical case in its own right, heads and firmware and boards, until it images alongside the others.
Parity checks and entropy testing prove the solved layout out before any file at all is lifted. Nothing proceeds on a hunch.
Native reading of ReFS and NTFS, ext4, XFS, BTRFS and VMFS, plus whatever virtual disks are parked on top of them.
Nothing can be written back to a member while it is being imaged. Whatever you posted is what returns, bit for bit, however the reconstruction goes.
Card, chipset or software layer, the geometry lives on the member drives themselves, and off those drives is where we read it back. PERCs and Smart Arrays expire still clutching their definitions; matched-batch drives fail in something close to choreography; desktop-grade members desert the set under sustained load. Three roads, and one ritual on arrival: every member imaged side by side on the first day, reconstruction carried out on the copies, and the originals honourably retired at the end.
Shut the server down before any drive moves, then mark each member with its slot number as it comes out, because reconstruction leans heavily on that order being known. Send the labelled drives by themselves — controller and chassis stay where they are — and a quick photograph of the bays as you found them earns its keep later on. Post them tracked and insured or send them by your own courier; there is no collection service, and drives can also be handed in at reception at our Cambridge location.
Most of what reaches this bench arrived by tracked, insured post. It is the steadiest way to move a poorly drive, and a parcel posted in Norfolk is usually on the bench the next working day.
Is the drive still bolted inside a laptop, desktop, MacBook, iMac, server or CCTV / DVR recorder? The hard drive or SSD needs to come out first, and only the bare drive travels — taking drives out of machines is not something we do here. Storage soldered to a motherboard (Apple Silicon Macs, one or two very thin laptops) is the single thing beyond us: if it will not come out, it cannot come in.
↓ Print the shipping & booking-in form (PDF)
Mark the parcel for the attention of Cambridge Data Recovery. From Norwich it is about an hour and twenty down the A11, then two minutes off the A14 at Junction 32 — or next working day by tracked post. You hear from us as soon as it is booked onto the bench.
Unsure what to put in the box? Ring 0800 689 0668 before you seal it, or run the free online diagnostic.
Diagnosis free, one figure written down, most work under no fix no fee. Start online, or ring us.