Almost every RAID array we receive lost the first drive weeks prior to when someone realised something was wrong — the reason is redundancy continues to work while the margins are spent quietly. When the volume ceases to function, most people will then remember the second drive failing. This is what each RAID level does and doesn't survive and why a rebuild is the wrong response. The same failure that occurs mid-rebuild for losing the second drive has been covered by RAID 5 data recovery.
Rebuilding a RAID writes to every good disk for hours and whenever it can’t read parity clean it will write bad data. A rebuild is by far the most frequent occurrence that turns a RAID array that could have been recovered fully into fragments. Shut off power and leave your disks alone in their bays.
The RAID level tells you exactly how many things need to fail before your RAID array ceases to function — and how it acts during the process.
Nearly every array that comes through here has already lost a disk by the time someone finds out about it.
The awkward consequence of redundancy is that if a device fails, the remainder of devices continue operating as expected. There is no indication that anything is amiss. The notification will go into a mailbox unread by anyone or it may be that the warning light on a unit stored in some cupboard indicates something went wrong. It then takes weeks until another device fails; when it does, the volume is gone in an afternoon, and thus all anybody remembers is the second one.
It’s for that reason that the degraded state of the system is much more important than the actual failure. A non-redundant volume has zero slack, and therefore each hour that passes during which the volume continues to operate is one hour at maximum risk. Therefore, if a controller notifies you that there are disks down, the appropriate reaction is to image (copy) the data out before ordering replacement disks and continuing on.
The controller has already proven unreliable enough that it should not be used for making volumes.
This includes those members previously noted as failed — an ejected member typically contains most of its data and is often the difference between partial and total recovery.
The stripe size is determined by testing various values until the reassembled array displays a coherent file system structure as opposed to random data. Disk order, parity rotation and offset are also tested to find combinations that provide the most coherence during the re-assembly process.
The array is completely recreated from the images, without use of the hardware. At no point in the process will anything be written back to the original disks.
If one member can't read a sector then the other members can compute it. It's possible to have two members which both can't read their sectors in the same location; those stripes can't be resolved.
NTFS, ReFS, ext4, XFS or Btrfs file systems are reconstructed from the assembled data set and database checks verify the data structures are consistent as opposed to simply copying them.
The practical part, and the part that makes the difference in terms of elapsed time.
All of the disks including the failed disk — they should be sent to us — each with their corresponding bay number — 1, 2, 3 etc. Bay numbering is key to reconstructing your data. Although it may be possible to derive the bay numbers through an analytical process there is no cost to you in sending them to us and it will save you significant amounts of time. If the hardware controller comes out easily, send the controller as well.
What should you tell us? Three simple things — the model of controller/NAS, the RAID level if you know it, but most importantly — what you've tried already. It matters if a rebuild was started and abandoned; if someone re-created the array just to "check" it; if someone put the disks back in a different order before shipping them to us — these all change the approach completely — and we'd much rather learn about them ahead of time than after-the-fact. No one will judge you for it — we simply want the accurate story.
This means a two-disk mirror and a 12-disk array aren't the same job. The cost is based upon that fact.
We charge from £500 +VAT for RAID, NAS and server recoveries, after we have completed our free 48-hour diagnostic. For enterprise SANs we quote separately from £1,250 +VAT after a scoping call. Where members need physical drive-level work we take a 50% deposit, and will only take the remainder once your disks are successfully recovered.
Our business terms are straightforward: NDAs are signed without exception; we have only one named point of contact from the diagnostic phase through to delivery; we invoice instead of taking payment by credit/debit card; and your data remains within the UK during the entire recovery process.
Please send the array, along with details of the RAID level, number of disks, and controller. We do not charge for the diagnostic that follows; and you will receive written confirmation of one figure before we begin any work.
Nothing starts until the array is on our bench — all of its disks, each labelled in the correct order. Please pack them carefully and include your contact information. The diagnostic costs you nothing, and one quote will go in writing prior to any work being performed.
Posting it? Use a tracked and insured service. The value of what is on the drive far exceeds the cost of postage. Bringing it in? Weekdays from 9am to 5:30pm, and it still needs packing as described above for the journey.
Not sure it's worth sending? Please tell us what type of RAID configuration your array uses, the type of failure you experienced, and any attempts you've made to recover your data. Every single one of these questions is reviewed by one of our engineers, who comes back with an honest view of the odds and a price range, before you post anything.
We’ll be in touch shortly. If it’s urgent, call 0161 871 0788.
The “level” determines the type of maths used in your system, and the platform determines where the description of that maths gets stored — and it is that description that most often goes missing.
Hardware controllers — Dell PERC; HP Smart Array; LSI and Broadcom; Adaptec; IBM ServeRAID. They maintain the array's configuration on the card; at times there will also be a backup copy located on disk(s), and other times there won't. If a firmware update or the card itself fails you will have disks still operating, yet no way of knowing how they all fit together as an array. This would represent a recoverable situation, however it is something the controller cannot do by itself.
Software arrays — Linux mdadm; Windows dynamic disks and Storage Spaces; ZFS. The configuration is stored on each member of the array, which is helpful, although when superblocks are updated during a rebuild operation it may create a situation where the description of how things currently stand does not match reality.
Appliances — Synology; QNAP; Buffalo; Drobo etc. all layer additional levels over the top of the array: SHR; thin-provisioned pools; BeyondRAID. All can be rebuilt, but need to be stripped away from each other before being treated as individual volumes.
What we get asked the most about getting back your data after you lose access to a RAID array.
A lot of times yes. The important question is whether the second drive was completely dead or just dropped out of the RAID – the typical case of a removed member can usually be read most of the time. All drives are pulled, each drive is imaged, and the array is rebuilt from the images rather than the original hardware.
No. If your data has value. Any time a controller rebuilds a RAID it will scan every sector on every good drive for many hours writing to all drives as it scans. When parity can't be read cleanly in any of those sectors during that process it will write bad data. This is why many people lose their recoverable RAID to an unrecoverable RAID when they do this.
Yes. Degraded means the redundancy is already gone, therefore at this point any additional failure is total loss. Get your data copied off now and replace nothing until you have got your data off first. It's nice to feel like it still works – it's this very feeling that makes this stage cost money.
Yes. Including any disk(s) previously flagged as failed. To restore a volume you need the entire stack except for mirrored volumes. Even an ejection typically allows a disk to provide readable data. Mark them by bay before pulling them.
This is a typical entry point — not an issue. The stripe size, order of members, parity rotation and offset for your array can be deduced by simply examining the disks themselves — the controller's information about them will serve as a guide, but nothing more.
Fixed-price written quotation available after a 48-hour free diagnostic. A minimum price of £500+VAT is available; enterprise SAN pricing is separate, from £1,250+VAT. Payment terms include a 50% deposit when physical drive-level work is commissioned, and payment of the remaining amount is only due on success.
Each controller manufacturer writes its own unique metadata formats. During a recovery process, we do not trust any of them. Therefore, when recovering from a RAID setup we derive the geometry directly from the data stored on the disks and then compare that to the parity calculated from the data on those disks. We do this because the controller is usually implicated in the failure.
From £500 +VAT. An initial quotation for the work will need to be obtained based on viewing all members of the array. All drives will then be imaged read-only without modification to the original configuration, and the array will then be restored using those images, away from the controller that lost it — and if the unit is still powered and attempting to rebuild, switch it off before anything else.