Degraded for months, then the second drive failed about 20 minutes into the rebuild, or the controller went down and took the RAID configuration with it. RAID data recovery is everyday work on our bench: levels 0, 1, 5, 6 and 10 from servers, workstations and NAS boxes across York and the Science Park, imaged first and then reconstructed virtually, with business-down cases moved to the front of the queue.
Each RAID array job is examined for faults at no cost. The fixed estimate will be written down before any tools (even a screwdriver) are lifted.
In most cases you only pay if we recover your data. Chip level, electronic and mechanical repair is charged at 50% at start-up, and the other 50% only upon successful recovery of your data; all BitLocker, ransomware, forensic and CCTV/DVR recoveries are charged at start-up when you accept our fixed quote. More information can be found on the data recovery cost page.
The very first step with any RAID array is matching the symptoms to the fault, and after two decades of experience with this type of work, these 25 account for just about everything that comes through our door.
The first lost drive was budgeted for by the redundancy; the rebuild then finishes off a tired second. This is array recovery's defining disaster, and also our steadiest stream of arrivals.
Rebuilds that are half done poison the parity they depended on. We map the extent of the damage from images before touching the structure.
Controllers carry their configuration information with them when they die. Geometry is derived again from the members themselves, as opposed to using a replacement card or vendor utility programs.
Data that has been sitting for months when written into a set which is used currently will tear the file system apart. The "damage" can be identified and repaired at an image level.
New configuration built on top of a current configuration. The great majority of the data below survives if you interrupt the initialisation process early enough.
A single power failure can remove multiple members of an array at once. We repair each drive individually and take an image of it separately before starting any group arithmetic.
Chassis wiring is often the real culprit when whole banks "die" all at once. We diagnose before raising the alarm, and it's usually less expensive too.
RAID maths looks good but the NTFS or ext4 layer on top is shredded. Parser level rebuild will fix this.
This was removed by accident and can be recovered quickly, as long as the blocks it described remain unwritten. The only real problem is time.
The cache batteries are flat and there has been a power outage, leaving the write hole open and the two out of step. Rebuilt from disk images, where disagreements don't cost anything.
H710s and P420s will expire while still holding the array definition. We take the layout off the member drives and skip the replacement-card theatre.
A drive with dead heads is taken to the head-swap bench before it can be added back into the imaging line with its fellow drives. None of them will advance until this is done.
Small business 7E8s match each other perfectly in wear out rate. Imaging them in parallel outruns the second failure, and that is the whole game.
Superblocks for mdadm and metadata for Storage Spaces disappear easily. They both rebuild from the raw members, piece by piece.
If a RAID member has to remap sectors every day, you know that failure is just around the corner. If an image of that failing member is created in time, the whole set lives.
When you have RAID 10 with both sides of one mirror down, it defeats the design on paper. However, with lab imaging we can often lift one side far enough to close the stripe.
An automatic rebuild landed on an idle (hot) spare disk that had been in this state for many years while it slowly deteriorated. Nothing that hasn't been imaged gets trusted here.
A single optimistic click against old metadata will scramble the set. Afterwards, we read the actual layout from the disks themselves, which kept an honest record.
Members with zero error recovery limits are ejected from their array under load. They are then imaged on patient hardware and rebuilt into sets again.
When the power cuts out on hypervisor builds, pool metadata can be lost. We walk backwards through the transaction history, working from complete images of every member.
The scheduled consistency check puts precisely the sustained load on a drive that a marginal drive can't carry. It always fails right in the middle of a scan, so make sure to image the set before the next one is due.
Permanent scars are stamped into parity when medium errors occur during degraded running. Images are used to chart the damage and we route around these damaged areas.
The wrong sector format means refused membership, and forcing the issue multiplies the damage. Sector sizes become negotiable at the image level.
Firmware for either an HBA or an expander, if only partially applied, causes drives to fall out of their groups in bunches. First we identify the hardware fault; the data was never the problem.
RAID 0 across two modules for benchmark speed, with no parity, and one module has died. We recover each one as an NVMe job, then stitch the stripe back together from the images.
So, before anybody starts guessing, every member drive is captured end to end, and the originals never spin inside an array again. RAID drive recovery always starts with those images. From the images, we deduce the member order, stripe size, which way it rotates and where the parity offset is located. Then we stand up a virtual version of the original volume on top, and walk the file system from the assembly. Stale members in a RAID 5, double losses in a RAID 6, nested 10s, or a controller that completely forgot who it was: that's just another typical week. And if the actual card that runs your RAID dies, you don't need a matching controller for RAID drive data recovery, because we rebuild the layout from the images of the individual member drives rather than from the hardware that lost it.
Database crashes are by far the worst call types. A write to an SQL Server failed because its array went dead in the middle of writing, the transactions were logged across both sides of the failure point, and the business was unable to trade while waiting for it. The process of recovering a RAID database crash is treated as a separate discipline. In other words, the array is reconstructed virtually first, followed by repairing the database files into a consistent state (with priority tables done first) allowing the business to begin trading before the remainder of the data copy is finished. Just remember there are three actions which can cause many more failures than any hardware issue: force an offline member back online, rebuild your array onto a failing drive, and allow someone to attempt one final test. If the array is offline: Power off all devices. Label each hard disk with its respective bay number. Pick up the phone and dial.
There is just one rule governing how we handle RAIDs at this workshop: image everything prior to attempting to do anything else. Thus far it has never been waived:
Before anyone even mentions or theorises about what might have happened, each member of the RAID group is duplicated at the same time on a separate piece of hardware. So if anything goes wrong during the rebuild process, it happens to the duplicate and the original data is safe.
After imaging each member, the software uses the resulting images to determine which drive was the first member, second, third and so on in the RAID set. Once the order has been determined, the software works out how the data was striped and rotated across the members and where each member's data starts relative to the others. At that point the virtual RAID array is assembled based on these parameters. These parameters are shown and demonstrated (not assumed).
When one of the members fails it is treated as a complete single-drive case in its own right, and therefore everything related to it, such as the heads, firmware, controller board etc., will be examined until it can be properly imaged next to the other remaining members.
Both parity and entropy tests are used to check that the correct layout has been determined before a single file is copied. None of the guesses make it through to the next stage.
All native read operations of file systems such as NTFS, ReFS, ext4, XFS, BTRFS and VMFS, even the virtual disks layered upon these file systems.
Member imaging operations are completely read only. What you post is exactly what comes back in terms of bits and bytes.
Regardless of whether the failure occurred within card, chip set or at a higher software layer level: the geometry will remain intact on the physical member drives, and that is where we obtain our geometry from when we perform a restore operation. PERC and Smart Array cards will typically hold onto their definitions until they fail. NAS boxes built around matching batches of components will usually fail in perfect synchronization. Members built using standard grade desktop hardware will often give out after being subjected to prolonged loads. There are three steps to a single end goal: Every member device is imaged simultaneously on day one, reconstruction occurs from the images created on that same day, original member devices are retired from the array.
Shut the server down before the first drive leaves the rack, then mark each member with its slot number as it comes out, as this will be important for rebuilding. Once you have your quote, post the labelled drives alone. Leave the controller and chassis in place, and take a picture of the bays as you found them, as it will help later.
Get a quote first, by calling us on 0800 689 0668 or using our free online diagnostic tool. After receiving your quote, tracked and insured post is how nearly every job reaches us: it is the fastest and safest way to get your drive to our lab in Leeds. There's no collection service, so the parcel is yours to send, or you can hand it in at the Leeds lab's reception.
Is the hard drive or SSD still inside a machine, such as a laptop, MacBook, iMac, CCTV/DVR system or server? Please remove the hard drive or SSD from the machine first and then post just the bare drive by itself; we do not provide a service for removing drives from devices. For a server or RAID, send every disk, each clearly marked with its bay. For a NAS, send its disks labelled by bay if you can remove them, otherwise send the NAS itself. We cannot work on storage soldered to the motherboard (e.g. Apple Silicon Macs, T2 Macs and certain slim laptops): if it doesn't come out, it can't come in. If you are unsure whether your storage is removable, call us before sending.
↓ Print the booking-in & shipping form (PDF)
Once you have your quote, send your package addressed to Leeds Data Recovery (about a 40 minute drive from York on the A64 & A1(M) or next working day if you want to send it using trackable post). We will contact you as soon as we have taken delivery of your package and put it in line to be worked upon.
Can't figure out what to pack? Ring 0800 689 0668 first, or try our free online diagnostic tool.
Free diagnosis, fixed written quote, and on most work you only pay if we recover your data. Start online or call our freephone.