A six-disk RAID 5 went offline after a power cut, with one member failed and only two of the remaining five recognised. The client used the controller’s built-in recovery function. It reported success — and then Windows showed six unallocated disks and offered to format them.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
A server or workstation runs a motherboard firmware update, or a technician performs a BIOS recovery to resolve an unrelated fault. The machine comes back up and the RAID volume has gone. The disks are all present, all healthy, and the controller reports no configured array at all.
On motherboard RAID and on several entry-level controllers, the array definition — which disks are members, in what order, with what stripe size — is stored in controller NVRAM rather than only on the disks. A BIOS recovery or firmware reset returns that NVRAM to defaults, and the definition goes with it.
The data is entirely untouched. Every disk still holds exactly what it held before. What has been lost is the map, and without it the controller sees a set of unconfigured disks and offers to create a new array from them.
That offer is the danger. Accepting it writes fresh metadata and, on many controllers, initialises the volume.
Creating an array with the same disks in the same order sometimes works and sometimes writes new metadata at a different offset. It is a coin toss with your data.
Initialisation writes a fresh volume structure across the members. This is the one action that turns a fully recoverable situation into a genuine loss.
With no configuration the controller has no parity relationship to work from. A rebuild here writes calculated data over real data.
Not on an array holding data you need. 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 actually arranged. The controller reports success; you lose the map.
Almost certainly not. Re-creating an array replaces a small amount of descriptor metadata, not the terabytes of actual data beneath it. The files, the file system and the parity are usually untouched — what has gone is the description of how they fit together.
No. That is the single most damaging thing available at that point. Formatting writes across the volume rather than a corner of it, and it destroys the structures a recovery would use to rebuild the array.
Yes — stripe size, member order, parity rotation and offset are all derived by analysing the disks themselves. Candidate arrangements are tested until reassembly produces coherent file system structures rather than noise, and the wrong ones fail immediately.
It can be recovered and it is worth doing. RAID 5 tolerates one missing member, so the array can often be assembled without it — but repairing that drive and imaging it as well gives a complete set and removes any dependence on parity to fill gaps.
From £500 plus VAT, fixed in writing after a free 48-hour diagnostic. Where a member needs clean-air work there is a 50% deposit with the balance due only on success.
Every member is imaged first, so nothing that follows can reduce what is present. Reconstruction then means establishing four unknowns from the images: disk order, stripe unit size, parity rotation and start offset.
The method is to test candidate geometries against structures that only make sense when the parameters are right — a file system superblock at a predictable location, a large file running continuously across stripe boundaries. Wrong parameters produce output that looks almost plausible, which is why verification against known structures matters more than getting a result.
Once confirmed, the volume is assembled from the images. The original disks are never written to.