RAID 5 Degraded or Rebuild Failed? What to Do First

A RAID 5 degraded warning means one drive has dropped out and the array is running with no safety margin left. The data is still there, and the array still works, but the next mistake or the next drive problem can take it offline. The RAID rebuild that’s supposed to fix things is also the most stressful moment in the array’s life. This guide covers the safe order of operations for a degraded array, what never to do, and what to do if the rebuild has already failed or a second drive has dropped.

What “degraded” actually means

RAID 5 stripes data and parity across all its drives so that any one drive can go missing and its contents can be recalculated from the rest. When that happens, the array is degraded: still online, still serving files, but every read of the missing drive’s data is now being calculated on the fly from the others.

You’ll usually find out from one of these:

• A NAS notification saying a volume or storage pool is degraded
• An amber or red drive LED, or a beeping RAID controller
• A controller or server management utility showing a drive as failed, missing, or offline
• A sudden slowdown, since the array is doing extra work for every read

The key point: a degraded RAID 5 has zero redundancy. One more failed drive, or even a few unreadable sectors on a surviving drive at the wrong moment, and the array can go offline. If you’re not sure how RAID 5 compares with other levels, what is RAID covers the basics.

Safe steps for a degraded RAID 5

Work through these in order. Don’t skip ahead to the rebuild.

1. Back up critical data first, if the array is still accessible. This is the single most important step. Copy your most important files to a separate drive or location before you insert a replacement. The rebuild reads every block on every surviving drive under heavy load; copying just the data you need first is a far smaller, more targeted read. Start with what you can’t replace.
2. Reduce load on the array. Pause scheduled jobs, heavy syncing, and anything non-essential until the data is safe and the array is healthy again.
3. Confirm exactly which drive failed. Use the NAS interface or controller utility to find the failed member’s slot number and serial number. Many systems have a “locate” or “identify” option that blinks the drive’s LED.
4. Label every slot. Before you touch anything, mark each drive with its bay or port number. If something goes wrong later, the drive order is essential for recovery.
5. Check the other drives’ health. Look at SMART status for the surviving members (see how to check hard drive health). If another drive is already showing reallocated or pending sectors, the rebuild is riskier, and getting your data off first matters even more.
6. Pull the correct drive. Match the serial number on the drive’s label to the one your system reported before you remove it. Pulling a healthy drive from a degraded RAID 5 leaves the array with two members missing, and it will go offline.
7. Use a suitable replacement. It should be the same capacity or larger, the same interface (SATA or SAS), and compatible with your controller or NAS. Use a new or wiped drive, never one taken from another array, which may carry old RAID metadata.
8. Let the rebuild run without interruption. Don’t power off, restart, or pull drives during the rebuild. Keep usage light and monitor progress. On large drives it can take a long time.

If you pulled the wrong drive by mistake, stop. Don’t start a rebuild, and don’t force anything. Putting the drive back in its original slot may restore the array, but if the system now marks it as failed or foreign, power down and get advice rather than experimenting.

What not to do

These are the actions that turn a recoverable RAID 5 failure into a much harder one.

• Don’t force a failed drive back online. Controllers often have a “force online” or “mark as good” option. A drive that dropped out earlier holds stale data. Forcing it back in mixes old and new data, and the array may start writing parity based on the wrong information.
• Don’t reinitialize, re-create, or “repair” the array by creating a new one. Initializing or creating a new array over the same drives can overwrite the configuration and, on some systems, the data itself.
• Don’t run chkdsk, fsck, or other file system repairs on a degraded or partially rebuilt array. If the array is presenting inconsistent data, a repair tool will “fix” the file system by deleting, truncating, or relinking files based on garbage. Those changes are written straight to the array.
• Don’t swap drive order or move drives between bays. Some systems tolerate it; many don’t. Keep every drive in its labeled slot.
• Don’t move the drives to a different controller or NAS model hoping it will import them more cleanly. Different systems can interpret, or rewrite, the metadata differently.

If the RAID rebuild failed

A RAID rebuild failed message usually means the array hit a problem reading a surviving drive partway through. Typical outcomes:

• The rebuild stops and the array returns to degraded.
• A second drive gets marked as failed, and the array goes offline.
• The rebuild “completes,” but some files or folders are corrupted, because certain stripes couldn’t be reconstructed.

At this point, stop retrying. Each new rebuild attempt reads the weakest drive in full again, and every attempt can add more writes to the new drive and the array metadata. See RAID rebuild failure for more on why rebuilds fail.

RAID 5 two drive failure

With two drives out, a RAID 5 array can’t reconstruct its data, so the volume goes offline or the NAS reports the pool as crashed (see NAS volume crashed for NAS-specific steps).

The good news is that a RAID 5 two drive failure is often less final than it sounds. Commonly, one drive failed long ago and holds stale data, and the second dropped out because of bad sectors or a timeout rather than a total failure. That second drive is often largely readable. A lab can image it, work out which member is stale, and reconstruct the array from the most current set of images.

What to do now: power the array down cleanly, keep every drive in its labeled slot, and write down what happened and in what order (which drive failed first, when the rebuild started, what errors appeared). Don’t force either failed drive online or re-create the array. Our RAID failure guide covers the same principles for any RAID level.

Foreign configuration on hardware RAID controllers

On hardware controllers such as Dell PERC, Broadcom/LSI MegaRAID, and similar cards, you may see a foreign configuration message after a drive is replaced, reinserted, or moved. It means the controller found RAID metadata on one or more drives that doesn’t match its own record of the array.

The controller will typically offer two choices:

• Import: adopt the configuration found on the drives. If that configuration is stale or partial (for example, from a drive that dropped out earlier), importing can bring the wrong data back into the array or trigger a rebuild from the wrong source.
• Clear: erase the foreign metadata from the drives. If the foreign configuration is actually your real array, clearing it removes the information needed to reassemble it.

Don’t import or clear blindly. If you’re not certain which drives belong to which configuration and which are current, stop and power down. A controller failure can produce the same symptoms; see RAID controller failure.

The bottom line

A degraded RAID 5 still has all your data, but no margin for error. Copy off what matters first, identify and replace the correct drive, label every slot, and let the rebuild run undisturbed. If the rebuild fails or a second drive drops out, stop: don’t force drives online, re-create the array, run chkdsk, or clear a foreign configuration. And once the array is healthy, make sure the 3-2-1 backup rule covers it, because RAID isn’t a backup.

If your array is already offline, our RAID 5 data recovery service reconstructs failed and partially rebuilt arrays by mail-in. Each case gets a custom quote after a free evaluation, and you pay nothing unless we recover your data.