Controller or NAS make and model
Different configurations in layout among different vendors and different generation devices determine the method prior to delivery of the disks. Photo of the label is acceptable.
Unlike a failing disk (clicking), there is no clock running on the hardware. The clock is running on the well-meaning actions (rebuilds, re-creations, restores), and each of them writes to an array where the array's description of itself is already untrustworthy. If your array is a parity set, RAID 5 data recovery is your playbook for how to recover your lost data.
The arithmetic differs by level, but you are always going to follow the same process: stop the array, preserve the original bay order of the disks, image each disk in the array as read-only, and reconstruct the entire array from those images. Only the last step is dependent upon which level you have.
An array failure creates an immediate need to take action. And nearly all of the damage we see was done in the first hour.
A RAID that has stopped serving data is not deteriorating like a clicking drive. There is no clock running on hardware. The clock that is running is the one on well-intentioned interventions, and each of them writes.
The practical advice has to be painful: shut it off and don't touch anything. Don't "rebuild", don't "reinitialise" and certainly do not "restore over". And please don't even try to reseat the disks to see if that will help. All of these are writes to an array whose description of itself is already unreliable.
And that's what makes each option so very simple to perform, and yet so expensive.
A rebuild reads all sectors on all members that remain alive for many hours while writing as it proceeds. A rebuild puts the heaviest load the array ever experiences on disks the same age as the one that just failed. It is the most frequent reason an otherwise recoverable array becomes irrecoverable.
When controllers offer options labelled as recover, restore or repair, they usually mean create anew. They put fresh metadata that describes a new array in place of where your actual data configuration existed. There is no undo.
Prior to restoring a backup over an original item, verify that the backup was completed successfully and is up-to-date. Restoring over the source item will eliminate your fall-back option should it be found to not be suitable.
The disk might contain more information than the controller understands, and the fact that you just inserted the disk could tell the controller to sync the old disk’s data over what is currently good data.
Reordering the disks is detrimental to successful reconstruction. Therefore, if they were previously removed, identify their origin prior to performing any additional steps.
Free, and worth more than anything you can do.
Different configurations in layout among different vendors and different generation devices determine the method prior to delivery of the disks. Photo of the label is acceptable.
RAID 5, RAID 6, RAID 10, or a vendor-specific type such as SHR. If you do not know, then there is no need to be concerned; it will be determined by the disks themselves.
Exact words of the error. Was "degraded", "offline", "interim recovery", or "foreign configuration" referenced? These are all specific terms with definitions.
Rebuild initiated, array rebuilt/recreated, restore attempt made, disks inserted into slot again. This is the single most important item on the list and the one users are most reluctant to provide information about.
This is because the controller is a single component we've proven can't be trusted.
Each member is initially imaged as read-only – including any disks previously identified as failed, which frequently still hold most of their data and are often what makes the difference between recovering a portion of your array versus all of it. A large array can easily represent days worth of work prior to starting any form of analysis.
The layout is then derived from the images. Stripe sizes appear as repeated structural periods when looking at each member's image. Disk orders are determined through trial and error testing until the array's file systems resolve themselves into something that looks like actual data instead of just random noise. Parity rotations are validated by verifying that the recreated stripes calculate correctly. Metadata provided by the manufacturer is considered nothing more than a suggestion and is not used as factual information.
These layers are located above those and include anything additional that was added by the manufacturer – LVM pools, Synology SHR, QNAP thin provisioning — and each layer needs to be deconstructed in sequence since errors at any given layer will show up as nonsensical data at higher layers. In essence, the virtual array is assembled using the images and without being tied directly to the failed hardware. RAID, NAS and server recovery in Manchester is from £500 +VAT after a free 48-hour diagnostic.
Power it down. Leave all disks inside their bays. Do not initiate a rebuild. Do not create an array again. Do not restore onto the original volume. Intervention is what will cause harm at this point, not deterioration of the hardware.
This is because a rebuild reads every sector on every remaining member for hours while writing them as it goes – the largest load ever placed on the array, placed on disks of the same age as the one which has now failed. This is typically the primary reason an otherwise recoverable array becomes unrecoverable.
Usually not. Most controllers re-create the array's configuration when you select these options rather than repairing the existing one, writing new metadata over the record of where your data existed. The controller reports success but you lose the map and are left without the ability to "undo."
Yes. Any level other than a basic mirror requires all members in order to recreate the volume. A disk that the controller ejected often still contains most of its data. Thus, it is often the difference between recovering partially and completely.
No, it's a standard initial stage. The stripe size, disk sequence and the parity rotation algorithm can be determined by analysing the disks themselves. If you know these parameters, you'll save yourself some time; if you don't know them, this won't preclude the recovery process.
Generally, the free diagnostic is back within 48 hours. After that, the timeline depends on the number of disk members because each disk needs to be imaged prior to beginning the analysis process. A small array could take a few days while a larger array will take longer.