RAID Data Recovery Bracknell

More arrays are destroyed by this than by any component in them. A rebuild asks every surviving member to read from end to end for hours while it writes to the replacement, which is the heaviest possible work to demand of disks that have shared a warm cupboard for six years. One of them gives out around the halfway mark, and the set now holds two failures and a half-written newcomer. Copy everything first and none of that can happen.

Somebody lifts all the disks out to read the serial numbers off them and cannot say afterwards which slot each one came from. Member order, stripe width and the offset where data actually begins all have to agree before a volume appears, and the wrong order produces something that mounts and reads as nonsense. The order is recoverable from the contents themselves. It is also an afternoon of arithmetic that a strip of masking tape would have saved.

The cache is holding writes, the backup battery has been flat since last year, and the power goes. What comes back has parity blocks describing stripes that were never committed. That gap is the write hole, and it does exactly what the name suggests. Both versions can be set side by side on copies and the right one chosen. Live, the controller settles the argument by overwriting one of them without asking.

Hardware controllers keep their array definition in memory on the card, so when the card fails the definition stops being readable. Nobody here goes hunting for the identical model on an auction site. Stripe boundaries, parity rotation and the start of the file system are all legible in what the member disks contain, and reading them back off the platters is quicker and more reliable than sourcing a replacement.

Adding a disk to a live RAID 5 rewrites every stripe on the set at a new width, in place, over a period of days. Interrupt that and the array is carrying two geometries at once: the old one behind the point it reached, the new one in front of it. The boundary shows up plainly on the images, and each region is then read with whichever geometry belongs to it.

A disk that dropped out in April, pushed back into the set in June, is offering the controller a version of the file system that is two months stale. The two accounts tear against each other along the line where they stop agreeing. Pulling that seam apart is done on copies, where a wrong assumption costs an hour instead of a directory tree.

chkdsk, fsck and the vendor repair utilities all assume the volume beneath them is fundamentally sound. Run one over an array that has come back together in the wrong order and it will dutifully rewrite metadata to match a layout that never existed. That is a second job created on top of the first, and it is the reason nothing gets repaired here until the geometry has been proved.

Somebody opens the controller utility to look at the state of things, works through the wizard, and creates a fresh array on hardware that already had one. Initialisation writes from the front, so if it was stopped in the first minutes most of the previous volume is still lying there behind it, untouched and perfectly readable once the old geometry is worked out.

A dying PSU or a spike on the rail can take out several members in the same instant, and no level of redundancy is designed for that. Each casualty is treated as a drive recovery in its own right on the mechanical bench before any of them is asked to contribute to a reconstruction. Arithmetic across the group comes last, not first.

When an entire column of bays drops out together, six disks failing simultaneously is the least likely explanation on the table. Chassis wiring, a tired expander or a cracked solder joint on the backplane accounts for most of these. Establishing which it is costs nothing but an hour, and it is a great deal cheaper than treating six healthy disks as casualties.

The spare sits powered and idle for four years, the array loses a member at two in the morning, and the automatic rebuild begins onto a disk that has not been asked to do anything since it was installed. Idle is not the same as healthy. Nothing here joins a reconstruction before it has been imaged and read clean, and a spare gets no exemption from that.

The controller offers to import metadata it has found, somebody clicks yes because the alternative box looked worse, and the member order changes underneath a working file system. The genuine layout is still written across the drives, which keep a more honest account of themselves than a card that has just been handed stale information.

Occasionally the geometry falls out cleanly, every parity check agrees, and the NTFS or ext4 riding on top is still wrecked. That is two jobs stacked: an array recovery underneath a file-system recovery. The second half is finished by reading the structures directly rather than by pointing a downloaded scanner at the result.

A disk with failed heads goes to the clean bench for a head transplant, has its firmware brought back into line, and only then joins the imaging queue with the rest of the set. The other members wait, because an array is only as recoverable as the worst disk in it and there is nothing to be gained by reconstructing early.

Small-business arrays are almost always built from a single order of identical drives, which then run the same hours at the same temperature in the same box. They reach the end of their working lives within weeks of each other, and the failure that gets noticed is rarely the first one. Every member is imaged in parallel here for exactly that reason.

mdadm superblocks vanish after a distribution upgrade. Storage Spaces stops recognising a pool it created itself. Neither takes much provoking, and neither is as well documented as the wiki page suggests. Both are reassembled by hand from the raw members, which is slower than any automatic route and considerably more likely to work.

A disk remapping sectors on a schedule is not failing suddenly; it is failing predictably. Imaged while there is still slack in that schedule, the whole set comes home intact. Left in service until the count runs out, part of it will not, and the part that goes is chosen at random rather than by importance.

On the design document the set is finished, because losing a complete mirror pair puts a hole straight through the stripe. In practice one of those two disks will usually image far enough on lab hardware to fill the gap, and the recovered volume is complete or very nearly so. This is where the theory and the bench tend to part company.

Consumer drives will spend a minute or more trying to read a marginal sector, because on a desktop that is the right behaviour. A RAID controller waits seven seconds and then throws the disk out of the set for insubordination. On imaging hardware that is happy to wait all night, those same drives read perfectly well and the set reassembles.

Buy the cheap high-capacity drive, put it in a degraded array, and the rebuild slows to a crawl as the drive shuffles overlapping tracks about behind the controller. It eventually stops answering, the controller drops it, and the array is worse off than before it was touched. Which drives were shingled is worth knowing before anything is ordered.

Virtualisation hosts running ZFS arrive after a power cut with pool metadata halfway through an update. Full images of every member come first, without exception, and the transaction history is then walked backwards on those copies until a consistent point turns up. That point is usually only seconds behind the failure.

A patrol read or a monthly scrub means hours of uninterrupted reading across every member, which is precisely the work a marginal disk cannot survive. The failure lands part way through the scan, at a weekend, when nobody sees the email. If a set is going to be imaged, image it between the checks rather than after one.

An array short of a member has no way to correct a medium error, so it records the failure into parity as a permanent hole. Those punctures are charted from the images and routed around at file level, which usually means a handful of files are affected rather than the volume. Nobody finds out until the rebuild reaches them.

Sector formats do not mix, the controller rejects the newcomer, and forcing the point creates two more problems on the way to solving nothing. On images the sector size is something that can be adjusted at will, which it never is on hardware that is trying to be helpful.

HBA and expander updates that fail to complete shed disks in ones and twos across the following fortnight. It reads on the console as a run of drive failures and it is nothing of the sort. Identifying that the fault is on the controller side, not the media side, comes before anybody starts replacing perfectly good disks.

A stripe with no parity anywhere in it, chosen because the numbers looked good in a review. One module stops answering and the volume goes with it in the same second. Each module is handled as an NVMe job on its own terms, and the stripe is reassembled from the images afterwards.

Warnings have been arriving in the mailbox of a member of staff who left before Easter, so nobody has known for months that the set was running without protection. By the time the phone rings the second disk has gone too. Everything in the chassis gets copied here, including the members the controller still calls healthy, on the reasoning that a controller which missed the first failure is no judge of the rest.

Nominally identical capacities differ between production runs, sometimes by thousands of sectors, so the controller refuses the new disk and somebody clears the configuration to make it accept one. The original fault now has a second fault standing next to it. Copies can be made whatever size the work requires, so on images the capacity argument simply does not arise.

Drives pulled out of a decommissioned server and put into a new one arrive with the previous array metadata still written on them. A controller that can see both sets of signatures starts making decisions nobody asked it to make. The layout that matters is settled from the data on the platters, not from whichever signature was loudest.

JBOD spans hold no redundancy of any kind. Files are laid down across the members one after another, so a missing disk removes a slice from the middle of the file system rather than truncating the end of it. Everything that happened to sit wholly on the surviving members comes back intact, and on a large span that is a far bigger proportion than most owners expect to hear.