RAID Data Recovery Leicester

The first failure went unnoticed for weeks, the replacement went in, and twenty minutes into the rebuild a second disk dropped out. That sequence accounts for more array losses than every other cause combined. It is not the end of the job. Every member gets imaged, including the two that failed, and the set is reconstructed from the copies.

Rebuilding reads every sector of every remaining member, which is exactly the workload a tired disk cannot survive. A rebuild that has stopped partway has usually written some correct parity and some incorrect parity across the set. Stop, power everything down, and do not start another.

Hardware controllers keep the configuration in their own memory, and when one dies the arrangement goes with it. Fitting a replacement card and letting it initialise the disks is how a recoverable set becomes an unrecoverable one. The layout is derived from the members here instead, and no matching card is needed.

The disks agree with each other and the file system on top has come apart. That is a different fault from an array failure and needs a different repair. Recreating the volume does nothing useful. It is imaged and the file system is rebuilt from whatever structures survive.

Losing mains mid-write leaves different members holding different generations of the same stripe. The controller then refuses the set because the sequence numbers disagree. Working out which member is stale, and by how much, is done from the images rather than by trusting what the controller says.

Management tools make destroying an array a small number of clicks, and the confirmation is easy to click through. What that writes is metadata rather than user data, so a set switched off promptly is usually recoverable in full. Every hour it runs afterwards costs something.

Somebody pulled the drives to check serial numbers and put them back in a different order. Some controllers cope and some write fresh metadata and make it permanent. Photograph the front of the chassis before removing anything, and label every disk with its bay.

Spares activate automatically and occasionally activate against a disk that had not actually failed, overwriting a good member with reconstructed data. The set then has two versions of the truth. Both get imaged and the reconstruction chooses between them stripe by stripe rather than at the level of whole disks.

Striping with no redundancy at all, and losing any member loses the volume. This is more common than it should be, because striping is what a two-bay enclosure defaults to on several makes. Both disks have to arrive. Where the failed one can be imaged even partially, a substantial share of the files comes back.

Mirrors fail silently. One member drops out, nobody notices, and writing carries on to the survivor for months. When the second one fails there are two versions with a long gap between them. Both are imaged and the newest good copy of every file is assembled from the pair.

Double parity tolerates two failures and no more. A third takes the volume out, and the usual reason a third goes is the rebuild after the second. Partial images of the failed members frequently supply enough to reconstruct most stripes, so a set in that state is worth assessing rather than writing off.

Nested layouts survive several failures as long as they land in different mirrors, and fail completely when two land in the same one. Which pairs were mirrored together has to be worked out from the members, and that is routine here even without the controller.

Adding capacity rewrites the layout across every member while the data is being moved, which is the least forgiving moment in an array's life. An expansion interrupted by a power cut or a failing disk leaves the set half in one geometry and half in another, and both have to be reconciled.

Very common on arrays that have never been scrubbed. Each disk has unreadable regions in different places, and no single member is complete. Imaging every one and combining the good ground is the only route, and it is a large part of the ordinary work on this bench.

Intermittent disks are worse than dead ones, because the controller keeps trying to bring them into the set and writes metadata every time it does. A disk behaving that way should be left out rather than reseated, and the whole array should be powered down.

Dynamic disks and Storage Spaces both keep their configuration in metadata on the members, and both can end up with a set that Windows sees and refuses to bring online. The arrangement is read directly from images here rather than through the operating system that is refusing it.

Software RAID on Linux is well documented and among the more straightforward layouts to reconstruct, which does not stop a set from refusing to assemble after a power cut or a failed grow. The superblocks are read from images, and the correct order and offsets follow from them.

ZFS keeps a transaction history, and where the current state is inconsistent an earlier consistent one is frequently reachable. Pools built on top of a hardware controller add a second layer to unpick. Say what the pool was built with on the booking form, because it saves a day at this end.

The array comes back first and the virtual disks are dealt with afterwards, as a separate problem. VMDK, VHDX and QCOW2 files each have their own structure, and a virtual disk that spans a damaged region needs its own repair once the underlying volume is readable. VMware work has a page of its own on this site.

A machine that will not power on, a set of disks in it, and no documentation anywhere. That is an ordinary Tuesday. The layout comes out of the disks, the controller is not needed, and the original machine can stay where it is. Server work has a dedicated page on this site.

The array is physically healthy and the files on it are encrypted where they lie. What can be done depends on the variant, on whether snapshots or shadow copies survived, and on what has been written since. It is priced as ordinary media, from 500 pounds + VAT for an array, and it is never charged as forensic work.

Matched sets fail in clusters because they were made together, run together and worked identically. That is arithmetic rather than misfortune. An array that has just lost one member of a matched batch is considerably more likely to lose another within months.

Copy-on-write file systems need free space to make any change at all, deletions included, and one that reaches capacity can end up unable to mount itself. It is recoverable. The lesson afterwards is to leave headroom, and it is one of the cheaper failures on this list to prevent.

Controllers that were never allowed to finish their initial synchronisation, or that hit an error during it, carry parity that does not match the data. Everything works until a member fails and the reconstruction produces rubbish. This gets identified during the assessment rather than discovered halfway through.

Write caching in front of an array holds data that has not reached the disks. When the cache device fails, the volume is inconsistent regardless of how healthy the members are. Cache devices have to travel with the array and be labelled as such.

Disks that have run continuously for years often carry wear that only shows when they are stopped and restarted. Moving a server, or a long power cut, is regularly the last event before a failure. That is the restart exposing a marginal disk rather than the move causing it.

BitLocker, LUKS and vendor encryption all sit above the array and have to be dealt with after the volume is reassembled, not before. A key or a passphrase is needed. Encrypted work is 400 pounds + VAT where it applies, and where the key is genuinely lost that is said plainly.

Second opinions arrive here regularly and a fair share of them come good. Be candid about what has already been attempted, because it determines the safest order to work in. The assessment costs nothing whether it is the first attempt or the third.

Not a fault, a priority. When an array failure has put a firm off the air, say so on the call and the job moves to the front of the list. The honest timings still apply: the free assessment takes two working days from arrival, and reconstruction runs from there.

Arrays get used as the destination for everything else in a building, which makes them the single point of failure for the whole site rather than the safety net. Redundancy protects against a disk failing and nothing else. It does not protect against deletion, ransomware, fire or theft.