You swapped the dead drive and the RAID still shows degraded. That's because the controller doesn't automatically detect the new disk in some setups. Here's the fix.
Step 1: Check the New Drive's Status
Open your RAID controller's utility. For most Dell PERC, HP Smart Array, and LSI MegaRAID cards, that's the BIOS at boot (Ctrl+R, Ctrl+C, or F5 for HP). If you're on a desktop with Intel RST, boot into the RST interface (Ctrl+I during startup).
Look for the new drive. It'll often show as "Unconfigured Good" or "Foreign". If it shows as failed, skip to Step 3. If it's "Ready", move to Step 2.
Step 2: Assign the Drive to the Array Manually
In the controller utility, select the degraded virtual disk and choose "Rebuild" or "Replace Disk". Pick the new drive from the list. This forces the controller to start rebuilding. For Intel RST, right-click the array in the Windows software and select "Rebuild to another drive."
You'll see progress. Rebuild time depends on the drive size and RAID level. For a 4TB RAID 5, expect 6-12 hours. Don't reboot during this.
Step 3: If the Drive Won't Import
If the controller shows the new drive as "Foreign", you need to import it. In the utility, go to "Foreign View" or "Import Foreign Config". Select the drive and import. This tells the controller to treat it as part of the array. Some HP Smart Array cards call this "Configure" > "Add Drive."
Still no go? The drive might have a different firmware or sector size. Match the old drive's specs exactly. A 4K-native drive won't work with a 512e array unless the controller supports emulation.
Why This Fix Works
The real issue is that many RAID controllers wait for explicit confirmation before rebuilding. They see the new disk as foreign or unconfigured for safety—they don't want to accidentally write to a drive with data. By manually assigning or importing, you bypass that safety check and tell the controller: yes, use this drive.
For Intel RST, the Windows software can't automatically rebuild if the array was created in BIOS mode. You have to trigger it manually. Same for LSI cards—the automatic rebuild only happens if the drive matches the array's metadata exactly (same slot, same type). Swap a hot-plug drive into a different slot and it won't rebuild on its own.
Less Common Variations
RAID 0 with two drives
If one drive fails in RAID 0, you can't rebuild—it's a stripe set. The fix is to replace both drives and restore from backup. But if you're lucky and the controller still sees the other drive, you can sometimes force a copy of the metadata to the new drive using the controller's "Replace Member" option. Only works if the array hasn't been fully destroyed.
Dell PERC H730 with T10 PI (Protection Information)
These controllers sometimes refuse to rebuild if the new drive has different PI settings (formatted with 520-byte sectors vs 512). You'll see the drive as "Blocked". Go into the controller's config and disable PI on the virtual disk, then rebuild. Or format the new drive with the same block size using sg_format on Linux.
Software RAID on Linux (mdadm)
If using mdadm, the array might degrade after a drive failure but not rebuild automatically. The fix is: run sudo mdadm --add /dev/md0 /dev/sdb. If the drive still shows as spare, the metadata might be stale. Wipe it first: sudo mdadm --zero-superblock /dev/sdb, then add it.
Prevention
Don't rely on automatic rebuilds. Know your controller's behavior. Before a drive fails, test on a spare: pull a drive, replace it, see if it rebuilds automatically. If not, you've got the manual steps memorized.
Match drive specs exactly—same model, same firmware, same sector size. A mismatch will waste your time. Keep one cold spare with identical firmware.
Set up email alerts from your controller (most support SMTP). You'll know the second a drive fails, not a week later when you reboot and find the array degraded.
One last thing: if your array is still degraded after all this, the controller might be failing, not the drive. Try reseating it or swapping slots.