A six-disk RAID 5 went offline after a power outage had left one disk as failed and only two of the other five disks recognised by the controller. After the user ran the controller's “recovery” option, the controller reported that the process worked, and then Windows showed six unallocated hard drives and asked if the user would like to format them.
This is a scenario, not a case study. It illustrates a common failure type that we address on a regular basis, and how it is approached, written from the technical side (versus as part of a single customer project). Please visit our documented case files here.
A technician updated the firmware of the motherboard (or BIOS) for a server or workstation, or performed a “BIOS recovery”, so they could fix another, unrelated issue. Either way, when the computer came back online, the RAID volume was missing. However, all of the disks were visible, were healthy, and the controller reported no RAID configuration at all.
In addition to the disks themselves (i.e., each individual disk), motherboard RAID and several low-end controllers store the RAID configuration (which disks make up the RAID, in what order, how large to stripe them) within the NVRAM located within the controller. When you run a BIOS recovery, or do a firmware reset, you will have reset your NVRAM to default values; therefore, your RAID configuration is now also at its default values.
All of this does not mean that the data has been compromised in any way. Each and every single disk is still holding exactly what it did prior to losing access to it. What has been lost is the mapping information. Without this mapping information, the controller recognises nothing but unconfigured disks. Therefore, the controller asks if you'd like to configure a new RAID from those disks.
That is the problem with the offer. When you accept this option, it will create fresh metadata and, on many controllers, will also initialise the volume.
Sometimes creating an array using the same disks in the same sequence may allow you to access your data, but there is always a chance that this will write new metadata at a different offset, so it is like flipping a coin for your data.
Initialising a volume creates a brand new volume structure across all of the members. It is the one thing you can do to take a completely recoverable failure and turn it into a real loss.
If you have no configuration information then the controller does not know which set of parity relationships to use when you want to rebuild. Therefore, if you attempt to rebuild you will end up calculating and placing data over real data.
Do not try them on an array that contains data you cannot afford to lose. On most controllers, those options will recreate the array's definition by rewriting its metadata, as opposed to fixing the existing array, thus writing new metadata over the original metadata about where your data resides. Although the controller will report success, you will lose the mapping.
Almost certainly not. Creating an array again simply replaces a small amount of the descriptive metadata used by the array and usually leaves intact your terabyte(s) of actual data along with their file systems and parity. What has gone is the description of how it all fits together.
No. That is the worst thing you could do at that point. The formatting process writes across the volume, not just into a small part of it. It also destroys the structures needed to build the array back together in a recovery.
Yes. These parameters (stripe size, member order, parity rotation and offset) are determined by analysing each of the individual disks. The candidate configurations are tested, and when a configuration produces file system structures instead of random bits of information, that's the correct configuration. When a configuration is wrong, it fails straight away.
It is recoverable, and it is worth recovering. RAID 5 can tolerate one drive being removed (and thus unavailable) and still function, so the array can often be assembled without the bad or failing disk. However, repairing that disk and completing a full image of it as well gives you a good copy of every disk, so you do not depend on parity information to restore lost data.
From £500 plus VAT; all necessary diagnostics prior to quoting are free (diagnostics take up to 48 hours), and the price is then fixed in writing. If any of your hard drives need mechanical work, a 50% payment is made prior to that work being done. The balance is due only upon successful completion of the recovery.
Each member in the RAID group will be imaged before anything else is done. Thus, after all members have been imaged, nothing that follows can reduce the data present on them. To rebuild the RAID group, we need to solve four different variables based on the disk image data collected: disk order, stripe unit size, parity rotation and start offset.
The way this works is by testing candidate geometry configurations against structures that can only be produced if all of the parameters were set up correctly. For example, a file system superblock should appear in a specific location, and there should be one or more large files whose contents run continuously across stripe boundaries. If the configuration parameters are wrong, the output will look very close to correct, so verifying the results against what we know about those structures matters much more than just getting an answer.
After that is verified, we assemble the volume using the images. We don't write anything back onto the original disks.