Few things a server or NAS can do are more stressful than a RAID array refusing to rebuild, or a rebuild failing partway through and dropping the array offline. When this happens, the immediate urge is to try again, swap in another disk or simply hit “rebuild” once more. Please don’t. A stalled rebuild is a warning sign, and forcing it is exactly how recoverable arrays become permanently lost. Below is why rebuilds fail, and the safe way through.
Rebuilds fail because one of the remaining disks is weak, the controller is confused, or the disks are in the wrong order. Forcing or repeatedly attempting a rebuild puts additional stress on the surviving disks and can overwrite the data needed to recover the array. Stop first.
A rebuild that doesn’t finish usually has a specific cause. The commonest is a second weak disk: RAID disks are typically purchased at the same time and wear together, so if one fails, another is often close behind, and the intense reading a rebuild demands is exactly what tips it into failure. Other causes include a controller or configuration problem (the array has lost its configuration, or disks are detected in the wrong order), a disk that has been replaced with an incompatible one, or simply unreadable sectors on an otherwise working disk that halt the parity calculation. None of these will be resolved by trying again, and trying again is what does the damage.
Here’s the mechanism that catches people out. A healthy rebuild reconstructs a failed disk’s data and writes it to the replacement disk, using the other disks as the source. If the other disks are also faltering, the rebuild can write wrong data (reconstructed from bad reads) onto the array, which in turn overwrites correct information. Even worse, some controllers will start writing over the very parity and data a recovery would need once you have forced a rebuild past errors or re-added a disk in the wrong order. Because these are writes to the array, they often cannot be reversed. That is why the single best thing you can do after a failed rebuild is nothing further.
If a rebuild has failed or stalled, turn off the array and leave it. Do not initialise it, do not attempt to “repair” it, do not swap in more disks in the hope that one takes, and do not allow the controller to start another rebuild on boot. If possible, note the original order of the disks (which bay each came from), because the array can only be reassembled correctly with every member disk in its right place. Then treat this as a recovery rather than a repair. The data almost always still exists across the disks; the problem is that the array can no longer safely assemble it itself, so it needs to be done offline instead.
The scenario behind most failed rebuilds is the RAID 5 one: a disk fails, you replace it, and the rebuild begins by reading all of the other disks. Then a second disk, worn and the same age as the first, throws an error partway through and the rebuild collapses. At that point, the array is degraded beyond what it can fix by itself, but the data is still recoverable if it is handled properly. In a lab, every disk is imaged read-only first, so nothing further is written to the originals. The array is then rebuilt virtually from those images, working around the weak disk’s bad sectors, and your files are extracted from the reconstructed volume. It is the same careful approach behind recovering any failed RAID or an inaccessible NAS. Send all the disks labelled in bay order; RAID recovery is from £500 +VAT.
Typically, because a second drive in the array is weak and fails under the load of the rebuild, the controller has lost or misread the RAID configuration, an incompatible replacement drive was used, or unreadable sectors are halting the parity calculation. RAID disks tend to age together, so a second drive failing during a rebuild is common. Rebuilding again doesn’t fix any of these and can make the issue worse.
No. Forcing a rebuild past errors, or attempting to repeat a failed one, writes to the array while applying additional stress to disks that are already struggling. It can write data reconstructed from bad reads over good data, and some controllers may begin rewriting the parity and data that a recovery would need. Because these are writes to the array, the damage is often irreversible.
Power the array down immediately and stop: don’t initialise it, don’t repair it, don’t swap in any more disks, and don’t let the controller start another rebuild on boot. If possible, note which bay each disk was placed in. After that, treat it as recovering your data, not repairing your array: the data almost always still exists across the disks, but the array needs to be reassembled offline rather than by itself.
Usually, yes. The data typically remains across the member disks; the array simply can’t safely assemble it after a failed rebuild. In a lab, every disk is imaged read-only, then the array is rebuilt virtually from those images, skipping over any bad sectors, and your files are extracted. The key is to stop before you force another rebuild. Recovery is from £500 plus VAT.
We need all of your member disks, labelled with the bay or order they came from, because the array can only be reassembled correctly with every disk in its right place. It also helps to know the RAID level (RAID 5, 6, 10 and so on) and the controller or NAS make and model, if you have them. A free diagnostic and a fixed price quote come before any chargeable work.
Do not start another rebuild. Power the array down and send us the disks labelled in order; we’ll image each one read-only and rebuild the array offline, with a free diagnostic and fixed quote first.