Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
I am thinking of using hardware RAID (levels 5 and 10) on my computers. What I don't get is how is data recovered when something goes bad and the RAID array fails (RAID Card problem or anything else).
When using standalone disks the process is very straightforward, but what does one do when a RAID array fails, how do people repair the array and resume work; and how is data recovered from a RAID array. since we cant just take out the drive and plug it in other computer.
When a drive dies in a HW RAID, you pull it out and plug a new one. An automatic rebuild takes place. In some cases you may have to use the card's GUI or CLI to notify the card that a drive has been replaced. The RAID is, of course, operational during the whole excercise.
If your RAID card dies, then that's much tougher. You should have a spare. If you don't, you buy one from your supplier. If it's no longer in production, you go frantically looking on eBay for a used one.
If you can't find even a used one, then it boils down to reverse engineering the on-disk format and writing some code to recover it. You may be lucky and find that it is stored in a fairly standard format. You either do it yourself or pay a lot to a data recovery company.
In that light, a SW RAID is more future-proof, as the software itself will not break over time and commodity hardware can be easily replaced.
However, SW RAID5 cannot be made fully resilient to power outages. That's the big advantage of HW RAIDs - they can be equipped with battery backed memory and thus be fully safe with regards to pulling the plug.
Your question is about HW raid recovery, so you look at the features that the HW raid card / controller provides for you.
Your RAID card will come with drivers and software that is supported under your OS that allows you to do configuration and status management without having to reboot into that BIOS.
For server hardware, the drives themselves are on hot-swap sleds with additional LEDs. These provide the physical feedback to you if the controller detects a problem with the RAID.
For desktop computers, your drives are hardwired to the RAID card or motherboard.
The driver and the software in your OS may also detect this and alert you some other way (email, etc).
Once a drive has gone bad, the controller stops reading and writing to it, relying on the remaining drives to serve the data. This is called a degraded state, you are still working, but one more failure pushes you over the edge into data loss. (2 more failures if you're running RAID 6)
For a hot-swapable raid controller, you simply pull out the failed drive, and put in a blank one.
How does it know it is blank? That's the job of the (3) scheme. All drives have unused data at the beginning, the partition table has plenty of free space in it. Each manufacturer will use it differently, but this is where the raid controller will store data that tells it which drive belongs to which part of the raid.
Once it sees a new drive that has not been used by this raid card before, it can start the restore process.
This can be automatic or triggered by the user, and can of course completely obliterate the new drive's contents if it was already formatted for something else.
The recovery or rebuild is managed in the background by the raid controller, it reads each sector from the remaining drives and calculates what should be on each sector for the new drive. For RAID 1, it simply copies accross all sectors of the existing good drive to the new drive. For RAID 5 or 6, all the existing drives are read, and the data to write to the new drive can be calculated. Since this work accesses the remaining drives, you can usually set a priority for it, so it doesn't slow down the whole system.
But you'd need to consider whether speed to recover back to full RAID status is more important than ongoing work. Some controllers, e.g. ones built into a regular desktop motherboard, might require you to go into the BIOS and trigger the rebuild there, and not let you boot into the OS until it's ready again. That would be an inconvenience, and would not be a good HW Raid because you want uptime as well as reslilience to failure.
A standalone HW raid card will give you the convenience of a rebuild that doesn't affect your ability to continue working.
If the failure is in the RAID card itself: The computer/server will most likely have crashed hard and is not bootable. At this point you might assume that the drives themselves are still viable, but it is more likely that the drives are in an inconsitent state, i.e. writes to one drive were not fully propagated to other drives. You are at the mercy of the Operating System and its File System error recovery for this. Worst case here is that you need to recover data from a backup as well after repairing the computer/server. If the RAID card is replaceable, an identical model can be installed in its place. Because the individual drives still report the same Identification in a manner that the RAID card recognizes, the full set of drives will work as before without complete loss of data (though File System inconsistencies may be present). If the RAID controller was part of a motherboard, the whole motherboard must be replaced with one with the same model RAID controller. If you attempt to use a different brand of RAID controller, most likely it won't recognize the drives at all, and just ask you how you want them newly configured, which will erase all existing data.
In HP Servers, all the various models of built in and plug-in RAID controllers share the same scheme for disk identification, so replacement of a built in controller with a plug-in, or a plug-in with a more powerful plug-in model is possible without loss of data.
In either case, care must also be taken that the replacement RAID card has its firmware updated to the same or newer version than the one being replaced.
Again with HP servers, I have had a server die, then I pull the whole set of drives in a RAID, and plug them into empty slots in a new server (already powered on), and the data is visible straight away.
With RAID 5 you always have a "parity volume". This is something of a misnomer as parity data is actually distributed among the drives, but it's still the case that you have one more drive than the number you would expect to need for your intended capacity. Call it n for the number of drives that you would need without redundancy, so n+1 is the number your raid 5 array will take.
The RAID 5 concept is that any n drives out of the set will always contain enough data to reconstruct a failed drive's contents.
The way parity lets this happen is similar to the concept of a "batch total" in accounting data. If I have a bunch of transactions to enter into a system, I may well compute a total for the batch before passing it to data entry. The data entry program requires that the computed batch total be entered, and then all of the transactions. The program computes the sum of the transactions and compares this to the batch total that I computed separately. If they're different, something's wrong. So the data entry person checks over the details.
To extend this to RAID 5, imagine that we have a way to know if any of the transactions - or the batch total, for that matter - was entered wrongly (or is unreadable). If only one input is wrong, then we can reconstruct that input with simple arithemetic: Subtract all the numbers that we do have from the total, and there's the missing number.
Fortunately for us, it's very difficult for a bad sector on a hard drive to be "read" without any error indication.
To understand further how the parity volume works, let's think about just one pair of bits in your "end user" data. Say, the first two bits in a sector as presented by the RAID 5 volume. We store one of those bits on drive A, and the other on drive B. On drive C, which is the "parity volume" for these particular bits, we store a bit that is the "exclusive OR" of the other two bits. The "exclusive OR" function is simply the sum of the bits, with carry ignored.
Another way to put it is that the XOR of any number of bits will be 1 if the number of "1" bits in the input is odd, and will be 0 if the number of "1" bits in the input is even. The value of this "XOR" function is what's stored in the "parity volume". Here's what this gives us for two input bits:
A B XOR(A,B)
----------------
0 0 0
0 1 1
1 0 1
1 1 0
Now, if we lose one of the bits - any one of the three, even the XOR - we can reconstruct it from the data we do have, as long as we know which bit is wrong - or missing.
And I will state again: the error correction and checking within hard drives is very good about this. It's set up so that, although corrected errors happen routinely, errors that are both uncorrectable and undetected are very, very rare. In the middle we have uncorrectable but detected errors, and we also have the case where the drive just fails and won't read anything (or the drive is missing completely). These "middle" cases are far more common than uncorrectable+undectable errors, and these are the cases RAID 5 protects against. We can reconstruct the missing or bad data from the data we have, simply by computing the XOR - the parity - of the bits that the drive tells us are still readable and good.
