A company’s 12-disk Lenovo ThinkSystem RAID 5 lost a drive, and during the rebuild the IT team pulled the wrong one — taking a second disk out of an array that could only survive losing one. The server went offline and further rebuild attempts corrupted more. The data was still on the disks; the controller had simply lost the plot. We imaged all twelve, worked out the true original layout, and rebuilt the array from the copies.
A business ran its core systems — databases, financial and client records, and several virtual machines — on a 12-disk Lenovo ThinkSystem server in RAID 5. A SAS disk failed, which RAID 5 is built to withstand, and the IT team set about replacing it. In the process the wrong disk was removed, the controller lost track of the array’s structure, and the server dropped offline. Attempts to rebuild it onto a new disk only made things worse, corrupting more of the configuration. At that point — correctly — they stopped and called us, rather than letting the controller keep trying.
RAID 5 stripes your data across all the disks and, alongside it, stores parity — a mathematical checksum (an XOR of the data blocks in each stripe) spread across the array. Parity is what provides the safety net: if any one disk fails, the controller can recalculate that disk’s missing data from the surviving disks plus the parity. It’s an efficient design — you lose only one disk’s worth of capacity to protection. But it has a hard limit: RAID 5 can survive the loss of exactly one disk. With one disk already failed, the array is running degraded, with its entire safety margin used up and no redundancy left at all.
That degraded state is precisely where this went wrong. With one disk gone, every remaining disk is essential — each one is now holding the only copy of its share of the data. Removing a second disk, believing it to be the failed one, drops the array below the single-disk tolerance and it can no longer be assembled: there isn’t enough left to calculate the missing pieces. Worse, when the controller then tried to rebuild with the disks in the wrong roles, it began writing parity and data based on a false picture of the array, overwriting some of the correct information with calculations that no longer matched reality. This is why the golden rule in a degraded RAID is to change nothing without being certain: in that state, one wrong swap turns a routine single-disk failure into a full-array outage.
The crucial point is that removing a disk or botching a rebuild doesn’t erase the data — the original information was still present across the twelve disks. What had been lost was the controller’s understanding of how that data fitted together, plus a limited amount of damage from the failed rebuild writes. Rebuilding a RAID correctly doesn’t depend on the controller’s memory of the configuration at all; it depends on working out the array’s true parameters from the data itself. Do that, and the array can be reassembled as it was before anyone touched it — which is exactly what a live controller, once confused, cannot do for itself.
Every one of the twelve SAS disks was cloned in full to healthy storage through hardware imagers, write-blocked, so all further work happened on copies and the originals were preserved as evidence of the pre-rebuild state. Working from the images, the array was reconstructed manually: by analysing the data and parity patterns across the disks we determined the true stripe size, disk order, parity rotation and start offset — the parameters that define a RAID 5 — rather than trusting the corrupted controller metadata. The genuinely-failed disk’s data was rebuilt from the others using parity, and the botched rebuild’s incorrect writes were identified and worked around, restoring the array to its correct pre-failure layout as a read-only reconstruction.
With the array correctly reassembled, the file system was mounted and the company’s data extracted — the databases, financial and client records, and the virtual machines — then checked for integrity, with database files and VMs validated before sign-off. The small amount of data sitting on stripes damaged by the failed rebuild couldn’t be perfectly reconstructed, leaving a 99% recovery with all critical systems restored, delivered on fresh storage. The lesson we passed on: a degraded RAID has no safety net left, so the moment a disk fails the priority is a verified backup and extreme care with any disk swap — label the failed drive precisely, and if there’s any doubt about which disk to pull, stop and get advice before touching the array.
Per-disk hardware imaging, write-blocked (12× SAS) · manual RAID 5 parameter analysis (stripe size, disk order, parity rotation, offset) · parity-based reconstruction of the failed disk · identification and exclusion of bad rebuild writes · read-only array reassembly, file-system repair and VM/database validation. All work in-house at our Belfast lab.
Wrong disk pulled, or a rebuild that’s made things worse — stop there and power the array down. Every further rebuild attempt risks overwriting recoverable data. Send us the disks for a free, no-obligation diagnostic; we’ll tell you what can be recovered and put a fixed price in writing before any work starts. We handle priority RAID recoveries for businesses across the UK.
Usually not. Pulling the wrong disk from a degraded RAID drops it below its fault tolerance so it won’t assemble, but the data itself is still on the disks. By imaging every disk and working out the array’s true original layout, it can be reconstructed as it was before the mistake. The key is to stop rebuilding, because that’s what overwrites recoverable data.
Exactly one. RAID 5 uses parity to rebuild a single failed disk from the others, but once one disk is down the array is degraded with no redundancy left. Losing a second disk — or removing a healthy one by mistake — takes it beyond what parity can recover on its own, which is why a degraded RAID 5 must be handled very carefully.
No. If the array is already confused or a wrong disk has been involved, further rebuild attempts write data and parity based on a false picture and overwrite good information. Power the server down, keep the disks in their original order and clearly marked, and get a diagnostic — a correct reconstruction from images gives a far better outcome.