Controller or NAS make and model
Layouts differ enough between vendors and generations that this determines the approach before the disks arrive. A photograph of the label is fine.
Essential
Unlike a clicking drive, there is no clock running on the hardware. The clock that is running is the one on well-intentioned interventions — rebuilds, re-creations, restores — and each of them writes to an array whose description of itself is already unreliable.
The arithmetic differs by level but the sequence never does: stop the array, preserve the bay order, image every member read-only, and reconstruct from the copies. Only the last step depends on which level you have.
Array failures create pressure to act, and almost all the damage we see was done in the first hour.
A RAID that has stopped serving data is not deteriorating in the way a clicking drive is. There is no clock running on the hardware. The clock that is running is the one on well-intentioned interventions, and each of them writes.
So the useful instruction is uncomfortable: power it down and do nothing. Not a rebuild, not a re-initialisation, not a restore over the top, not reseating the disks to see if that helps. Every one of those is a write to an array whose description of itself is already unreliable.
Which is what makes them so easy to do, and so costly.
A rebuild reads every sector of every surviving member for hours and writes as it goes. It is the heaviest load the array ever experiences, applied to disks the same age as the one that just failed. It is the commonest way a recoverable array stops being one.
Controller options labelled recover, restore or repair usually mean re-create. They write fresh metadata describing a new array over the record of how your data was actually arranged, and there is no undo.
Until you know the backup is complete and current. Restoring over the source removes your fallback if it turns out not to be.
It may hold more than the controller thinks, and reinserting it can trigger a resync in the wrong direction — overwriting good data with stale data.
Bay order is central to reconstruction. If you have already removed them, note which came from where before anything else.
All free, and all worth more than anything you could attempt.
Layouts differ enough between vendors and generations that this determines the approach before the disks arrive. A photograph of the label is fine.
RAID 5, 6, 10, or a vendor arrangement like SHR. If you do not know, that is a normal starting point — it is derived from the disks themselves.
The exact wording of the error, and whether it mentioned degraded, offline, interim recovery or foreign configuration. Those terms mean specific things.
A rebuild started, an array re-created, a restore attempted, disks reinserted. This is the single most important item on the list and the one people are most reluctant to volunteer.
Because the controller is the one component that has already demonstrated it cannot be relied on.
Every member is imaged read-only first — including any disk already marked failed, which frequently still holds most of its data and is often the difference between a partial and a full recovery. On a large array that alone is days of work before analysis begins.
The layout is then derived from the images. Stripe size shows up as a repeating structural period across members. Disk order is established by testing arrangements until file system structures resolve into something coherent rather than noise. Parity rotation is confirmed by checking that reconstructed stripes actually compute. Vendor metadata is treated as a hint, not a fact.
Above that sit whatever layers the vendor added — LVM pools, Synology SHR, QNAP thin provisioning — each unwound in order, because an error at one level surfaces as nonsense several levels up. The array is assembled virtually from the images, entirely outside the hardware that failed. RAID, NAS and server recovery in Manchester is from £500 +VAT after a free 48-hour diagnostic.
Power it down and leave the disks in their bays. Don’t start a rebuild, don’t re-create the array, and don’t restore over the original volume. The hardware is not deteriorating — what causes damage at this point is intervention.
Because a rebuild reads every sector of every surviving member for hours and writes as it goes — the heaviest load the array ever experiences, applied to disks the same age as the one that just failed. It is the commonest way a recoverable array becomes unrecoverable.
Usually not. On most controllers those options re-create the array definition rather than repairing it, writing new metadata over the record of how your data was arranged. The controller reports success; you lose the map, with no undo.
Yes. Every level except a simple mirror needs the full set to reconstruct the volume, and a disk the controller ejected frequently still holds most of its data — often the difference between partial and complete recovery.
No, it is a normal starting point. Stripe size, member order and parity rotation are all derived by analysing the disks themselves. Knowing them saves time; not knowing them does not prevent recovery.
The free diagnostic is normally back within 48 hours. Beyond that the timescale is set by the number of members, since every one is imaged before analysis begins — a few days for a small array, longer for a large one.