Nobody had looked at the alert panel in months, so the first failure went unremarked and the second turned up twenty minutes into the rebuild. Or a controller died holding the only description of the layout. Array work is a weekly fixture here rather than an event, across levels 0, 1, 5, 6 and 10, out of servers, workstations and network boxes. It all travels by tracked post, so a set out of a Coventry office sits alongside work from anywhere else in the country, and nothing is tried on anything until every disk has been copied.
Looking at a RAID set costs nothing. What comes out of that examination is one written figure, agreed between us before anybody picks up a screwdriver: from £500 + VAT on an array, the figure following the number of members.
Logical work is no fix, no fee. Four things sit outside that: electronic and mechanical failures, chip-level work, DVR jobs and forensic work, and anything physical is half up front. All five bands are laid out on the data recovery cost page, while data recovery services follows a postal job from the parcel to the answer.
Tracing a symptom back to whatever caused it is where the job genuinely starts, and these thirty cover very nearly every box opened on the Oxford bench. A fault that is not on the list is not an unfamiliar one: describe it over the telephone and you will get a straight reading of the odds before you have spent a penny on postage.
A degraded set keeps working, which is the whole point of parity and also the reason so many arrays run for months one disk short. The alert went to an address nobody reads. The end, when it comes, is a perfectly ordinary second failure landing on a set that had already spent its margin.
Replacing the failed disk starts a full-rate read of every survivor, which is the heaviest thing an ageing set is ever asked to do. Twenty minutes in, another member drops. Nothing is finished at that point. Both failed disks are imaged along with the healthy ones and the volume is built from the copies.
Half-finished reconstruction leaves some stripes carrying freshly calculated parity and some carrying the old kind, with no marker to say where the boundary fell. That boundary can be found again from the copies. Laying a fresh rebuild over the top of the abandoned one is what destroys the evidence needed to find it.
Hardware cards keep member order, stripe size and rotation in their own memory, so the arrangement dies with the card. Buying an identical replacement and letting it adopt the disks is the standard next move and it is the wrong one. Here the layout is worked out from the members, and no card is needed at any stage.
Somebody pulled the drives to read serial numbers off the labels, or to blow the dust out, and slid them home in whatever order came to hand. A few controllers cope. Others write new metadata to match what they now see and make the mistake permanent. Photograph the front of the chassis before anything moves.
Striping keeps no second copy and calculates nothing, so a single dead member takes the volume with it. Two-bay boxes are shipped striped by several makers because it advertises the larger number. Both disks travel here, and where the failed one images even partly, a large share of the files returns. Striped sets have a page of their own on this site.
Mirrors fail quietly. One member drops out, the machine carries on against the survivor, and nobody hears about it until the second one goes. What then arrives is two disks holding versions of the same volume months apart. Both are imaged and the newest sound copy of each file is picked out. Mirrored pairs have their own page here.
One parity block per stripe tolerates exactly one absent disk. The second takes the volume out, and the second usually arrives during the rebuild that followed the first. Partial images of both failures routinely supply enough to compute most stripes, so this is worth assessing rather than abandoning. Parity sets have a dedicated page here.
Two parity blocks per stripe absorb two failures, and the third ends it. Sets built this way are usually large and old, which is precisely why they were built this way. Recovery works from whatever can be read off all the members together, and the wider the set the more often that turns out to be enough.
Striping across mirrored pairs survives several failures as long as they land in different pairs, and dies the moment two land in the same one. Which disks were paired with which is not obvious from the outside. It comes out of the member metadata and the content, and it does so without the controller.
The members agree with one another, the geometry is right, and Windows or Linux refuses the volume anyway. That is a file system fault standing on top of a sound array, and it is a separate piece of work with separate tools. Creating a new volume to get past it is the one action that turns it into a real loss.
Adding a disk moves every block on the set into a new geometry while the array stays in service, which makes it the least forgiving hour in an array's life. Interrupt it and part of the volume sits in the old arrangement and part in the new. Both have to be identified and reconciled before anything is readable.
A power cut leaves different members holding different generations of the same stripe, and the controller then refuses the whole set because the sequence counters disagree. Which member is stale, and by how many writes, is settled from the images rather than from whatever the card believes about itself.
Spares activate on their own and occasionally activate against a disk that had done nothing worse than answer slowly. Reconstructed data then lands on top of good data and the set holds two accounts of itself. Both are imaged, and the reconstruction chooses between them stripe by stripe instead of trusting one disk wholesale.
Removing an array takes two clicks and a confirmation worded to sound routine. What those clicks write is configuration rather than content, so a set powered down promptly is very often recoverable in full. What costs is the hours it stays in service afterwards while somebody works out what happened.
Cards offer to import a configuration they do not recognise, and the offer appears at the worst possible moment with somebody in a hurry standing in front of it. Accepting it can rewrite the metadata on every member. Where that has already happened, say so, because it changes the order the work is done in.
Common on any set that never had a consistency check scheduled. The bad ground lands in a different place on each drive, so not one of them reads the whole way through, and the volume is built out of the good parts of all of them at once. It is a normal week's work rather than an exotic case.
An intermittent disk causes more damage than a dead one, because every time it reappears the controller tries to bring it into the set and writes metadata doing so. Reseating it invites that to happen again. A drive behaving this way should be left alone and the whole array powered down.
Microsoft's software pooling keeps its layout in metadata on the members, and a pool that has lost a disk or been interrupted mid-write can end up visible and unusable at the same time. Repair from inside Windows writes to the pool. Here the arrangement is read straight out of the images, with the operating system left out of it.
Linux software RAID is well documented and among the more tractable layouts to put back, which does not stop a set refusing after a power cut or a failed grow. Superblock version decides where the data area starts, so it is read rather than guessed. Recreating the array is the action that ends the job, and it is the one most often tried.
Copy-on-write pools keep a history of consistent states, and where the newest is broken an earlier one is frequently still reachable. A pool built on top of a hardware card adds a second layer to unpick. Write down what it was created with and on what, because that note saves a working day at this end.
The array is put back first and the virtual disks are treated as a second problem afterwards. VMDK, VHDX and QCOW2 files each have their own internal structure, and one that spans a damaged region needs repairing in its own right. Virtual machine work has a page of its own on this site.
A machine that will not power on, a handful of drives inside it, no paperwork and nobody left who set it up. That is an ordinary week here. The layout comes from the disks, so the make of the machine is not the obstacle it appears to be. Server work has its own page as well.
The disks are sound and the files on them have been through somebody else's cipher. What can be done turns on the strain, on whether snapshots survived, and on what has been written since. It is priced as ordinary array work, from £500 + VAT, it is not an investigation and it is never charged as one.
BitLocker, LUKS and vendor encryption all live above the array, so the volume is reassembled first and the encryption dealt with afterwards. A key or a passphrase is needed for that second half. Where neither exists, that is said at the assessment rather than discovered later, and encrypted work is the £400 + VAT band.
Members bought together were made together, spun the same hours and served the same requests, so they arrive at the end of their lives within weeks of one another. That is arithmetic rather than bad luck. An array that has just lost one of a matched batch is a poor candidate for a leisurely rebuild.
File systems that write new blocks rather than overwriting old ones need free space to do anything at all, deletions included, and one that reaches capacity can lock itself out. It comes back. The lesson afterwards is headroom, and it is among the cheapest failures on this page to avoid entirely.
Arrays end up as the destination for every other machine on site, which makes them the single point of failure rather than the safety net. Redundancy protects against one disk stopping. It does nothing about a deletion, an attack, a fire or a theft, and that distinction only ever gets made after the event.
Second opinions arrive regularly and a fair proportion of them come good. Say what was run, how long it ran and whether anything was written back. Nobody is keeping score. The answer decides where it is safe to start, and looking costs nothing on a third attempt exactly as it does on a first.
Not a fault, a priority, and it is treated as one when it is said on the telephone. Saying it changes the queue and not the arithmetic. Two working days from booking in for the free examination, and the reconstruction starts from there. Anyone offering a rebuilt array by the morning is guessing with your money.
The order of work is short to describe and it is the whole difference between a recovery and a gamble. Each member is imaged read-only before anything else happens, and that includes disks the controller has already declared dead, because a drive with a few thousand unreadable sectors is still holding the overwhelming bulk of what was written to it, and that bulk is often what finishes the reconstruction. Once the images exist, the geometry is worked out from them: stripe size, member order, parity rotation, delay, start offset. All of it comes out of the data. None of it is read off a card, tested against your disks or written back to them at any point. Two consequences follow. A dead controller is an inconvenience and nothing more, since the arrangement lives in the members; conversely, fitting a replacement card and allowing it to initialise the set is the single most reliable way to turn a recoverable array into an unrecoverable one. And the metalwork stays with you: Oxford's form asks for member disks only, each marked with its bay position, and a photograph of the front panel before anything is drawn costs nothing and occasionally saves a day.
RAID 0 spreads data across every member and keeps nothing spare, so one missing disk takes the volume with it. It is also much the commonest array arriving from this part of the country, usually a two-disk workstation set or a dual-bay box that was striped out of the carton without anybody choosing it, and it has a page of its own here because the route back differs from a parity set. RAID 1 mirrors, which looks safe until both members age together in the same warm cupboard, and that has its own page too. RAID 5 holds one calculated block per stripe and survives a single missing member, which is exactly why so many of them arrive having lost two; the page devoted to it walks through that sequence. RAID 6 tolerates two failures and RAID 10 is mirrors striped together. Servers and virtual machines have pages of their own as well, because a failed server tends to bring a controller, a boot volume, a stack of data disks and often a hypervisor along with it. The pricing is identical whichever door you came in through.
Most of the difficult array jobs here became difficult after the failure rather than during it. Running a second rebuild is the first, because a rebuild puts every remaining member under a full-rate read for hours and that is what a tired disk gives out under. Letting a replacement controller initialise the set is the second, since it stamps fresh metadata over whatever arrangement was in place. Agreeing when a management console proposes building a new volume is the third, and it hides behind a confirmation box that is easy to click past at two in the morning. All three are survivable and all three cost days. The one thing that helps is dull: cut the power and leave it cut. On money, an array is from £500 + VAT and climbs with the member count, the free examination takes two working days from the day the disks are logged, and a firm that has stopped trading should say so on the call so the job is marked on arrival — though the timings themselves do not bend for anybody.
No theory is ever tested against the disks that arrived. Every member is copied first, every idea about the geometry is tried against the copies, and the original set goes home in the state it came in. That single rule is why an array another firm has already given up on is still worth putting in a box.
A disk the controller ejected still holds nearly everything ever written to it, and that remainder is frequently what completes the volume. So the ejected members are imaged alongside the survivors, with retries capped in hardware so a difficult region is deferred rather than hammered until the drive gives up.
Where the chunks of a large file land across the members tells you the order they were written in, the length of each chunk and how parity moves down the set. All of that comes out of the data. It is the reason a dead card is an inconvenience rather than a verdict.
Levels 0, 1, 5, 6, 10, 50 and 60, plus the nested and proprietary arrangements that appear in no manual. A missing member is not guessed at; the stripes it held are calculated from the parity on the ones that remain, and the result is checked against real file content before it is trusted.
NTFS, ext4, XFS, Btrfs, ZFS, VMFS and ReFS. An array that goes back together perfectly and still refuses to mount has a damaged file system on it, which is a separate repair with its own tools and its own failure modes, done against the image rather than the disks.
IronWolf, WD Red, Ultrastar, Exos and the SAS families, held by model and firmware revision. Matched batches fail in clusters, so having two or three of the same drive already on the shelf is what decides whether the imaging starts this week or waits on a delivery.
Array disks fail exactly as any other disk does, and one that has been clicking needs its heads replaced under filtered air before it can be read at all. That part is an electronic or mechanical failure, which is one of the four published exclusions, so it takes 50% up front.
An array opens at £500 + VAT and climbs with the member count, because each disk is copied separately before any reassembly begins. Looking is free, the answer lands on the second working day after the drives are logged in, and the figure is put in writing at that moment rather than guessed at over the telephone. Ransomware on an array is priced identically and is never charged as an investigation. Logical work carries no fix, no fee; a member that failed electronically or mechanically does not, and that part takes 50% up front. Where something has already been tried — a rebuild restarted, a replacement card allowed to adopt the disks, an offer of a fresh volume accepted — write it on the booking form. None of those ends a job. All of them change where it has to start, and guessing at that end of the bench costs a day. This page is the general one. Striped sets, mirrored pairs and single-parity sets each carry their own page here, going into the arithmetic of one level at a time, and servers and virtual machines do the same.
Send the member disks and nothing else. The chassis stays with you, so do the controller card, the caddies where they fight you and the rails, because none of them are needed to work out the layout and a rack unit in a parcel is a costly way of protecting a set of drives. Before a single disk moves, photograph the front of the machine, then write the bay number on each drive in marker — one, two, three, in the order the unit presents them. A NAS box is the exception and travels whole with its disks left in place, which records the order for you. Wrap each bare disk so it cannot knock against its neighbours and use a carton that keeps its shape under weight. Send it tracked and insured to Oxford Data Recovery, John Eccles House, Oxford Science Park, Robert Robinson Avenue, Littlemore, Oxford, OX4 4GP, or bring it in yourself: Coventry to the door is about fifty-five miles of M40 and takes roughly an hour, and drop-offs are taken Monday to Friday, 9:00am to 5:30pm. There is no counter in Coventry and nobody collects. Do not start another rebuild before the parcel leaves. If the failure has stopped a business trading, ring 0800 689 0668 and say so, and the job moves up the list.
Almost everything worked on here arrived in the post. A drive that is already in trouble has an easier time boxed, padded and insured than it does being carried round in a bag for an afternoon, and a parcel handed over in Coventry today is normally booked in at Oxford tomorrow morning.
As a rule the storage comes out and the machine stays where it is. That applies to a laptop, a tower, an iMac and to the recorder sitting under a counter. Taking equipment apart is not something this bench does, and a repair shop will free a drive in a few minutes. Two things go the other way: an external drive stays sealed inside its own case, and a NAS travels as a complete unit with its disks still in their bays. A Fusion Mac is a third case — both of its drives come out and travel together, each one labelled. The single situation nobody can work around is memory soldered flat onto a mainboard, which is how Apple Silicon Macs and a good many slim laptops are built: if the storage will not unbolt, there is no parcel to send.
↓ Print the shipping & booking-in form (PDF)
Put Oxford Data Recovery on the label. From Coventry it is roughly fifty-five miles straight down the M40, about an hour if you would rather drive it in than post it. Either way you are told the moment it is logged, and the free diagnostic finishes two working days later.
Unsure what ought to go in the box? Ring 0800 689 0668 before you seal it, or work through the free online diagnostic and let it do the asking.
The commonest array here, and nothing in it is duplicated anywhere
Parity spread across every stripe, and the rebuild that spends it
Two halves, imaged apart, then compared on what they actually hold
Three makers, three ways of writing down the same array layout
VMFS above the members, and guests that refuse to come back up
It failed an hour ago: what to do, and what to leave well alone
Looking at it costs nothing, one written figure follows, and the band governing this page is from £500 + VAT on an array, the figure following the number of members.