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.
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.