Degradation can continue for months without anybody being aware of it, and then the second drive fails twenty minutes into a rebuild. Or the control unit fails with the only copy of the configuration stored within it. RAID data recovery services are something we do weekly rather than occasionally. We receive sets at 0, 1, 5, 6 and 10 from servers, workstations and NAS systems. All drives received will be imaged prior to us attempting anything, and the volumes are then rebuilt in software. Companies that cannot trade go first.
Every job for RAID arrays is assessed without cost. First, a fixed figure in writing, prior to taking anything out of the toolbox.
In most cases you only pay if we recover your data. The exceptions are electronic/mechanical failures, chip level work, DVR and forensic jobs. All pricing information can be found on the data recovery cost page.
The first job on any RAID array is always matching the problem (symptom) to the error (fault). After twenty plus years, these twenty-five cover nearly every fault that gets to this workbench.
The redundancy addressed the first failure. A rebuild will then finish off a second, exhausted disk. As such, array recovery has one defining catastrophic event and this is it; it is also the steadiest stream of arrivals to this bench.
If a rebuild is abandoned mid-stream it will poison the same parity it needs to complete the rebuild. How far that corruption reaches is tracked through images before anyone touches a structure.
The configuration information is retained by the controller and goes to the grave with it. Geometry will be re-derived from the member disks. This process does not include replacing the controller card nor using vendor utility software to do so.
Pushing months-old data back into an operational working set creates conflicts between two versions of files. The file system tears along the seams created by these conflicting versions. These discrepancies are picked apart at the image level, allowing them to be studied rather than creating additional conflict.
Someone builds some new configuration over the old, live one. If you catch this initialisation in time, a surprising amount of what was under it will come through it.
An electrical failure knocks down several disks at once. Each gets repaired individually and has a copy made of itself before group arithmetic can even start.
It looks like entire banks have failed at the same time, but really it's bad wiring in the enclosure. In this case, diagnosis precedes panic, and that order of work usually turns out less expensive too.
Everything works fine at the array arithmetic layer, and the file system (NTFS or ext4) sitting on top of that is broken. That problem is solved with a rebuild at the parser layer.
This was removed accidentally, and will still be recoverable fairly quickly as long as no-one writes anything to the blocks it was describing. The only true enemy here is time, and it isn't very patient either.
A flat cache battery combined with an outage leaves the "write hole" exposed and the data and its parity no longer synchronised. This is reconciled from images, where a bad guess is free to make without cost or consequence.
H710s and P420s die holding definitions that were never written down anywhere on earth. Those disk layouts come off the member disks and you do not have to put a new card through staging.
Whichever member disk has dead heads is sent to the repair lab first, then back into the image queue. Nothing proceeds until that disk is back in the image queue because a set is no more complete than its worst member.
Matched disks that were purchased to build a set for one small business tend to wear at roughly the same rate. Imaging them in parallel gets ahead of the second failure before it happens. And getting ahead of it is all there is to this game.
mdadm superblocks and Storage Spaces metadata vanish with relatively little provocation. Both are rebuilt from the original members (slowly, piece by piece) using their images.
Any member disk that is constantly mapping out bad sectors is failing by degrees instead of all at once. Regardless of how it fails it eventually will fail completely. Get it imaged before it is too late and the whole set will live. Leave the imaging too late and parts of the set will die.
Lose both halves of a single mirror pair within a RAID 10 and, by design, you lose. Lab imaging can often recover enough of one half of the lost mirror pair to complete a stripe. This is the point where theory meets reality.
Just one hopeful click made against stale metadata is enough to mess up the whole set. The genuine layout can be read back directly from the member disks, which have kept honest track of their own record throughout this time.
Members with no error-recovery limit will be ejected under load if they take too long to recover from a single bad sector. Members are imaged using equipment that doesn't mind waiting and then put back together again based upon their respective images.
Pool metadata lost from hypervisor builds due to a power outage is tackled by walking the transaction history backwards using complete member images. This carries on until something consistent turns up among the members.
Two modules were previously striped together for benchmark figures. No parity was used in the design and one of these modules is now dead. Each module is recovered individually as a full NVMe case. These individual images are then assembled back into the stripe.
The emails from alerts went to an email address that no one looked at after a staff member departed. This array has been running in a state of "borrowed" redundancy for six months, and the day the second disk fails is the day it will be discovered. All disks are then copied (imaged), including the disk the controller continues to call healthy.
Capacities may appear to be identical but can vary in number of sectors (by thousands) across different models or generations. The controller rejects the replacement disk, somebody clears the configuration so that it will accept one, and thus two problems are created rather than just one. When working at an image level, this capacity difference becomes irrelevant.
Disks that were pulled from old servers and reused contain the array signature information of those servers. When you show both sets of signatures to a controller, it will make choices that none of your users want. Ultimately, the genuine configuration is determined from the actual data and not from which set of metadata "yelled" the loudest.
JBODs as well as spanned sets have absolutely no redundancy. When you make a JBOD or a spanned set, the data is written across the disks in a sequential order and nothing more. If one disk fails then there will be a hole right down the centre of your file system. All of the files that were completely located on the remaining disks will come back intact, and more often than not it will be more files than owners anticipate.
Half of a RAID 1 fell off silently and the other just kept going without a mirror. When the live disk eventually failed, the old half was put back into service, carrying a full copy of everything from a year earlier. We image both, and the newer data is then copied off the failed disk instead of being written off.
No one thinks about how things should be laid out until each disk has been fully duplicated end to end. Once that is complete, nothing from your original set ever goes back into an array. All of this information is deduced on the copies of the data (where each disk was placed, size of striping, rotation of parity, starting position of offset). Those answers are in the data, and the data is now safely duplicated. Then the volume will be built by software and the file system pulled off the assembly. A stale disk that fell out of a RAID 5 half a year ago and was never noticed. Two failures in a RAID 6. Nested 10s. A controller that lost all memory of its configuration. All routine. If the card itself fails, there is no point chasing an identical replacement, as the layout is stored on the disks and not in the hardware that lost track of it.
The difficult calls come from failed databases. Disks stop working in the middle of a write. Transaction logs straddle the exact second when it all stopped. A company is left idle behind all of it. All this is managed as a separate discipline. The array comes back together using software; database files will then be restored to a consistent state, the critical business tables being restored first, so that trading can resume long before the remaining terabytes are complete. There are three habits that destroy more arrays than faulty parts ever could. Placing an offline disk back online. Rebuilding onto a unit that is clearly failing. Giving another person the opportunity to attempt it one more time. When an array fails: turn off the power, label each disk with its bay, and ring us for a quote first, before doing anything else. In cases like this, Scotland data recovery services are judged on a single question: is the business trading again by Monday?
There is one fundamental principle about RAID recovery in this facility. Everything is imaged before anything is touched. This policy has never been waived for anyone:
Each member will be cloned at the same time on specialised hardware prior to anyone making recommendations on configuration. All other risks are then placed on clones. Original members remain static.
Stripe size, stripe order, stripe rotation, and stripe offset determined based on the clone, and then the array is built virtually. Layout geometry verified through testing on the workbench, never assumed from documentation.
A "dead" member (or drive) must be a complete mechanical repair task unto itself. It gets everything it needs (heads, circuit board, firmware etc.) until it can be imaged alongside every other drive in the set.
When doing parity arithmetic and/or running entropy tests, there must be agreement between those results and the solved layout before any file is lifted off it; hunches don't survive this process. That is exactly why we do it.
NTFS and ReFS, ext4 and XFS, BTRFS and VMFS file systems all read natively, as well as whatever virtual disks might be currently attached/parked atop.
Members can't be written to during an image operation. Whatever you posted will go back to you bit for bit, no matter how your reconstruction ends up.
Whether it is a card, a chipset or a software layer, the geometry is stored on the member disks, and that's where we read it back from. A PERC or a Smart Array will be "dead" with the geometry (definition) still held within it, and nobody wrote it down anywhere. All the drives from a matched batch will fail almost in unison. Desktop-class members can't sustain the load for long before giving up on the set. There are three ways in, but there is only one process at the door: image every member side by side on the first day, reconstruct on the copies, then retire the original disks honourably at the end. Engineering firms, survey outfits and design practices around Aberdeen run more of this kit than they realise, usually in a cupboard nobody opens from one year to the next.
Before the first disk moves, shut off the server. As each disk is removed, label it with its slot number, because the reconstruction depends heavily on knowing that order. Only the labelled disks travel; the case and the controller remain in place. Take photos of the disks in their original slots, for about a ten-second cost. Get a quote first, by phone or with our free online diagnostic, then post the disks to us tracked and insured, or book a courier of your own. There is no collection service. However, you may take your disks into the reception area of our Edinburgh lab, which is open Monday to Friday, 9am to 5:30pm, with no appointment needed, approximately two and a half hours south on the A90.
Get a quote first by telephone or use our free online diagnostic. Most of what you see on this bench will then be delivered via tracked, insured post. This is one of the safest ways to move a failing drive and packages handed in at a North-East post office are normally delivered here the next working day.
Still attached to a laptop, desktop, MacBook, iMac, server or CCTV/DVR unit? Remove the hard drive or SSD first. The bare drive travels on its own; when removing disks from a server remove all the disks and label each disk by its bay. This lab does not take machines apart. Any storage that has been soldered onto a motherboard (as in T2 and Apple Silicon Macs and a couple of thin laptops) will not be worked on: if it will not unbolt, we cannot work on it. If you're not sure what type of machine you have, ring us first. Phones and tablets are also not taken on.
↓ Print the shipping & booking-in form (PDF)
Your parcel should be addressed to Edinburgh Data Recovery, approximately two and a half hours (and 130 miles) from Aberdeen via the A90; alternatively it can reach us the next working day by tracked post if this journey time / distance is prohibitive to travel. As soon as your drive has been scheduled in we will contact you.
Still unsure about what should be placed inside of the packaging? Please call us first on 0800 689 0668, or use our free online diagnostic tool to assist you in deciding which items belong inside of the packaging before sealing.
Free diagnosis, one fixed price quoted in writing, and in most cases you only pay if we recover your data. Start online or phone it in.