Software-RAID HOWTO: Error Recovery

Next Previous Contents

4. Error Recovery

Q: I have a RAID-1 (mirroring) setup, and lost power while there was disk activity. Now what do I do?
A: The redundancy of RAID levels is designed to protect against a disk failure, not against a power failure. There are several ways to recover from this situation.
- Method (1): Use the raid tools. These can be used to sync the raid arrays. They do not fix file-system damage; after the raid arrays are sync'ed, then the file-system still has to be fixed with fsck. Raid arrays can be checked with ckraid /etc/raid1.conf (for RAID-1, else, /etc/raid5.conf, etc.) Calling ckraid /etc/raid1.conf --fix will pick one of the disks in the array (usually the first), and use that as the master copy, and copy its blocks to the others in the mirror. To designate which of the disks should be used as the master, you can use the --force-source flag: for example, ckraid /etc/raid1.conf --fix --force-source /dev/hdc3 The ckraid command can be safely run without the --fix option to verify the inactive RAID array without making any changes. When you are comfortable with the proposed changes, supply the --fix option.
- Method (2): Paranoid, time-consuming, not much better than the first way. Lets assume a two-disk RAID-1 array, consisting of partitions /dev/hda3 and /dev/hdc3. You can try the following:
  1. fsck /dev/hda3
  2. fsck /dev/hdc3
  3. decide which of the two partitions had fewer errors, or were more easily recovered, or recovered the data that you wanted. Pick one, either one, to be your new ``master'' copy. Say you picked /dev/hdc3.
  4. dd if=/dev/hdc3 of=/dev/hda3
  5. mkraid raid1.conf -f --only-superblock
  Instead of the last two steps, you can instead run ckraid /etc/raid1.conf --fix --force-source /dev/hdc3 which should be a bit faster.
- Method (3): Lazy man's version of above. If you don't want to wait for long fsck's to complete, it is perfectly fine to skip the first three steps above, and move directly to the last two steps. Just be sure to run fsck /dev/md0 after you are done. Method (3) is actually just method (1) in disguise.
In any case, the above steps will only sync up the raid arrays. The file system probably needs fixing as well: for this, fsck needs to be run on the active, unmounted md device.
With a three-disk RAID-1 array, there are more possibilities, such as using two disks to ''vote'' a majority answer. Tools to automate this do not currently (September 97) exist.
Q: I have a RAID-4 or a RAID-5 (parity) setup, and lost power while there was disk activity. Now what do I do?
A: The redundancy of RAID levels is designed to protect against a disk failure, not against a power failure. Since the disks in a RAID-4 or RAID-5 array do not contain a file system that fsck can read, there are fewer repair options. You cannot use fsck to do preliminary checking and/or repair; you must use ckraid first.
The ckraid command can be safely run without the --fix option to verify the inactive RAID array without making any changes. When you are comfortable with the proposed changes, supply the --fix option.

If you wish, you can try designating one of the disks as a ''failed disk''. Do this with the --suggest-failed-disk-mask flag.
Only one bit should be set in the flag: RAID-5 cannot recover two failed disks. The mask is a binary bit mask: thus:
```
    0x1 == first disk
    0x2 == second disk
    0x4 == third disk
    0x8 == fourth disk, etc.
            
```
Alternately, you can choose to modify the parity sectors, by using the --suggest-fix-parity flag. This will recompute the parity from the other sectors.

The flags --suggest-failed-dsk-mask and --suggest-fix-parity can be safely used for verification. No changes are made if the --fix flag is not specified. Thus, you can experiment with different possible repair schemes.
Q: My RAID-1 device, /dev/md0 consists of two hard drive partitions: /dev/hda3 and /dev/hdc3. Recently, the disk with /dev/hdc3 failed, and was replaced with a new disk. My best friend, who doesn't understand RAID, said that the correct thing to do now is to ''dd if=/dev/hda3 of=/dev/hdc3''. I tried this, but things still don't work.
A: You should keep your best friend away from you computer. Fortunately, no serious damage has been done. You can recover from this by running:
mkraid raid1.conf -f --only-superblock
By using dd, two identical copies of the partition were created. This is almost correct, except that the RAID-1 kernel extension expects the RAID superblocks to be different. Thus, when you try to reactivate RAID, the software will notice the problem, and deactivate one of the two partitions. By re-creating the superblock, you should have a fully usable system.
Q: My version of mkraid doesn't have a --only-superblock flag. What do I do?
A: The newer tools drop support for this flag, replacing it with the --force-resync flag. It has been reported that the following sequence appears to work with the latest tools and software:
umount /web (where /dev/md0 was mounted on) raidstop /dev/md0 mkraid /dev/md0 --force-resync --really-force raidstart /dev/md0
After doing this, a cat /proc/mdstat should report resync in progress, and one should be able to mount /dev/md0 at this point.
Q: My RAID-1 device, /dev/md0 consists of two hard drive partitions: /dev/hda3 and /dev/hdc3. My best (girl?)friend, who doesn't understand RAID, ran fsck on /dev/hda3 while I wasn't looking, and now the RAID won't work. What should I do?
A: You should re-examine your concept of ``best friend''. In general, fsck should never be run on the individual partitions that compose a RAID array. Assuming that neither of the partitions are/were heavily damaged, no data loss has occurred, and the RAID-1 device can be recovered as follows:
1. make a backup of the file system on /dev/hda3
2. dd if=/dev/hda3 of=/dev/hdc3
3. mkraid raid1.conf -f --only-superblock
This should leave you with a working disk mirror.
Q: Why does the above work as a recovery procedure?
A: Because each of the component partitions in a RAID-1 mirror is a perfectly valid copy of the file system. In a pinch, mirroring can be disabled, and one of the partitions can be mounted and safely run as an ordinary, non-RAID file system. When you are ready to restart using RAID-1, then unmount the partition, and follow the above instructions to restore the mirror. Note that the above works ONLY for RAID-1, and not for any of the other levels.
It may make you feel more comfortable to reverse the direction of the copy above: copy from the disk that was untouched to the one that was. Just be sure to fsck the final md.
Q: I am confused by the above questions, but am not yet bailing out. Is it safe to run fsck /dev/md0 ?
A: Yes, it is safe to run fsck on the md devices. In fact, this is the only safe place to run fsck.
Q: If a disk is slowly failing, will it be obvious which one it is? I am concerned that it won't be, and this confusion could lead to some dangerous decisions by a sysadmin.
A: Once a disk fails, an error code will be returned from the low level driver to the RAID driver. The RAID driver will mark it as ``bad'' in the RAID superblocks of the ``good'' disks (so we will later know which mirrors are good and which aren't), and continue RAID operation on the remaining operational mirrors.
This, of course, assumes that the disk and the low level driver can detect a read/write error, and will not silently corrupt data, for example. This is true of current drives (error detection schemes are being used internally), and is the basis of RAID operation.
Q: What about hot-repair?
A: Work is underway to complete ``hot reconstruction''. With this feature, one can add several ``spare'' disks to the RAID set (be it level 1 or 4/5), and once a disk fails, it will be reconstructed on one of the spare disks in run time, without ever needing to shut down the array.
However, to use this feature, the spare disk must have been declared at boot time, or it must be hot-added, which requires the use of special cabinets and connectors that allow a disk to be added while the electrical power is on.

As of October 97, there is a beta version of MD that allows:
- RAID 1 and 5 reconstruction on spare drives
- RAID-5 parity reconstruction after an unclean shutdown
- spare disk to be hot-added to an already running RAID 1 or 4/5 array
By default, automatic reconstruction is (Dec 97) currently disabled by default, due to the preliminary nature of this work. It can be enabled by changing the value of SUPPORT_RECONSTRUCTION in include/linux/md.h.

If spare drives were configured into the array when it was created and kernel-based reconstruction is enabled, the spare drive will already contain a RAID superblock (written by mkraid), and the kernel will reconstruct its contents automatically (without needing the usual mdstop, replace drive, ckraid, mdrun steps).

If you are not running automatic reconstruction, and have not configured a hot-spare disk, the procedure described by Gadi Oxman < gadio@netvision.net.il> is recommended:
- Currently, once the first disk is removed, the RAID set will be running in degraded mode. To restore full operation mode, you need to:
  - stop the array (mdstop /dev/md0)
  - replace the failed drive
  - run ckraid raid.conf to reconstruct its contents
  - run the array again (mdadd, mdrun).
  At this point, the array will be running with all the drives, and again protects against a failure of a single drive.
Currently, it is not possible to assign single hot-spare disk to several arrays. Each array requires it's own hot-spare.
Q: I would like to have an audible alarm for ``you schmuck, one disk in the mirror is down'', so that the novice sysadmin knows that there is a problem.
A: The kernel is logging the event with a ``KERN_ALERT'' priority in syslog. There are several software packages that will monitor the syslog files, and beep the PC speaker, call a pager, send e-mail, etc. automatically.
Q: How do I run RAID-5 in degraded mode (with one disk failed, and not yet replaced)?
A: Gadi Oxman < gadio@netvision.net.il> writes: Normally, to run a RAID-5 set of n drives you have to:
mdadd /dev/md0 /dev/disk1 ... /dev/disk(n) mdrun -p5 /dev/md0
Even if one of the disks has failed, you still have to mdadd it as you would in a normal setup. (?? try using /dev/null in place of the failed disk ??? watch out) Then, The array will be active in degraded mode with (n - 1) drives. If ``mdrun'' fails, the kernel has noticed an error (for example, several faulty drives, or an unclean shutdown). Use ``dmesg'' to display the kernel error messages from ``mdrun''. If the raid-5 set is corrupted due to a power loss, rather than a disk crash, one can try to recover by creating a new RAID superblock:
mkraid -f --only-superblock raid5.conf
A RAID array doesn't provide protection against a power failure or a kernel crash, and can't guarantee correct recovery. Rebuilding the superblock will simply cause the system to ignore the condition by marking all the drives as ``OK'', as if nothing happened.
Q: How does RAID-5 work when a disk fails?
A: The typical operating scenario is as follows:
- A RAID-5 array is active.
- One drive fails while the array is active.
- The drive firmware and the low-level Linux disk/controller drivers detect the failure and report an error code to the MD driver.
- The MD driver continues to provide an error-free /dev/md0 device to the higher levels of the kernel (with a performance degradation) by using the remaining operational drives.
- The sysadmin can umount /dev/md0 and mdstop /dev/md0 as usual.
- If the failed drive is not replaced, the sysadmin can still start the array in degraded mode as usual, by running mdadd and mdrun.
Q:
A:
Q: Why is there no question 13?
A: If you are concerned about RAID, High Availability, and UPS, then its probably a good idea to be superstitious as well. It can't hurt, can it?
Q: I just replaced a failed disk in a RAID-5 array. After rebuilding the array, fsck is reporting many, many errors. Is this normal?
A: No. And, unless you ran fsck in "verify only; do not update" mode, its quite possible that you have corrupted your data. Unfortunately, a not-uncommon scenario is one of accidentally changing the disk order in a RAID-5 array, after replacing a hard drive. Although the RAID superblock stores the proper order, not all tools use this information. In particular, the current version of ckraid will use the information specified with the -f flag (typically, the file /etc/raid5.conf) instead of the data in the superblock. If the specified order is incorrect, then the replaced disk will be reconstructed incorrectly. The symptom of this kind of mistake seems to be heavy & numerous fsck errors.
And, in case you are wondering, yes, someone lost all of their data by making this mistake. Making a tape backup of all data before reconfiguring a RAID array is strongly recommended.
Q: The QuickStart says that mdstop is just to make sure that the disks are sync'ed. Is this REALLY necessary? Isn't unmounting the file systems enough?
A: The command mdstop /dev/md0 will:
- mark it ''clean''. This allows us to detect unclean shutdowns, for example due to a power failure or a kernel crash.
- sync the array. This is less important after unmounting a filesystem, but is important if the /dev/md0 is accessed directly rather than through a filesystem (for example, by e2fsck).

Next Previous Contents

Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:05