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.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.
- 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.) Callingckraid /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:Instead of the last two steps, you can instead run
fsck /dev/hda3
fsck /dev/hdc3
- 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
.dd if=/dev/hdc3 of=/dev/hda3
mkraid raid1.conf -f --only-superblock
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.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.
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.
/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:By using
mkraid raid1.conf -f --only-superblockdd
, 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.
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:After doing this, a
umount /web (where /dev/md0 was mounted on) raidstop /dev/md0 mkraid /dev/md0 --force-resync --really-force raidstart /dev/md0cat /proc/mdstat
should reportresync in progress
, and one should be able tomount /dev/md0
at this point.
/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:This should leave you with a working disk mirror.
- make a backup of the file system on
/dev/hda3
dd if=/dev/hda3 of=/dev/hdc3
mkraid raid1.conf -f --only-superblock
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.
fsck /dev/md0
?
A: Yes, it is safe to runfsck
on themd
devices. In fact, this is the only safe place to runfsck
.
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.
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:
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
- 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
SUPPORT_RECONSTRUCTION
ininclude/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 usualmdstop
, 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:
At this point, the array will be running with all the drives, and again protects against a failure of a single drive.
- stop the array (
mdstop /dev/md0
)- replace the failed drive
- run
ckraid raid.conf
to reconstruct its contents- run the array again (
mdadd
,mdrun
).Currently, it is not possible to assign single hot-spare disk to several arrays. Each array requires it's own hot-spare.
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.
A: Gadi Oxman < gadio@netvision.net.il> writes: Normally, to run a RAID-5 set of n drives you have to:Even if one of the disks has failed, you still have to
mdadd /dev/md0 /dev/disk1 ... /dev/disk(n) mdrun -p5 /dev/md0mdadd
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: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.
mkraid -f --only-superblock raid5.conf
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
andmdstop /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
andmdrun
.
A:
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?
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 ofckraid
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 & numerousfsck
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.
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 commandmdstop /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, bye2fsck
).