Can I add a spare disk to the array to speed up failure recovery?

Yes. Add the disk with mdadm --add /dev/sdX and mdadm will designate it as a hot spare. If a member fails, the kernel immediately starts rebuilding onto the spare without any manual intervention.

Is mdadm RAID 5 safe for large modern drives?

It works, but long rebuild times on drives larger than 2-4 TB expose you to a second failure or an unrecoverable read error during the rebuild. RAID 6 with a hot spare, or RAID 10, is safer for high-capacity arrays.

Can I grow an existing array by adding more disks?

Yes, with mdadm --grow. You can add devices and then reshape the array, though this is a slow background operation that should be done with a current backup. RAID 1 cannot be grown this way; you'd migrate to RAID 5 or RAID 10 instead.

What happens to the array if I forget to regenerate the initramfs?

On the next boot the initramfs will not have the assembly configuration and the root array will fail to mount, dropping you to an emergency shell. Boot from a live environment, mount your root partition, chroot in, and run update-initramfs, dracut --force, or mkinitcpio -P as appropriate.

Does mdadm work alongside LVM?

Yes, and it's a common stack: RAID at the md layer for redundancy, then LVM on top of /dev/md0 for flexible volume management. Create the md array first, then initialize it as a physical volume with pvcreate /dev/md0.

Software RAID on Linux with mdadm

Software RAID with mdadm is a mature, kernel-native approach to disk redundancy and performance on Linux. It costs nothing beyond the drives themselves, performs within a few percent of hardware RAID controllers on modern CPUs, and gives you full visibility into array state—no proprietary firmware black box. This guide walks through choosing a RAID level, building an array, keeping it healthy, and recovering from a failed drive without losing data.

RAID Level Quick Reference

Pick the right level before you touch a single command. Getting this wrong later means rebuilding from scratch.

RAID 0 – Striping only. Doubles throughput (roughly), zero redundancy. One disk dies, all data is gone. Use for scratch space or caches, never for anything you care about.
RAID 1 – Mirroring. Requires 2 disks minimum; usable capacity equals one disk. Survives one failure. Read performance can be spread across both disks; writes hit both. The sane choice for a boot drive or small critical dataset.
RAID 5 – Striping with distributed parity. Minimum 3 disks; loses one disk worth of capacity. Survives one drive failure. Rebuild times on large drives are long, and a second failure during rebuild is fatal. Avoid for disks >2 TB unless you have frequent backups and a hot spare.
RAID 6 – Like RAID 5 but with double parity. Minimum 4 disks; survives two simultaneous failures. Preferred over RAID 5 for arrays of large drives.
RAID 10 – Mirrored stripes. Minimum 4 disks; loses half capacity. Fast reads and writes, survives multiple failures as long as no mirror pair loses both members. The practical choice for a database or heavily written workload.

Installing mdadm

Debian / Ubuntu

sudo apt update && sudo apt install mdadm

Fedora / RHEL / Rocky

sudo dnf install mdadm

Arch Linux

sudo pacman -S mdadm

Identifying Your Disks

Confirm device names before you do anything destructive. Block device names can shift between reboots; use disk IDs or serial-based symlinks in /dev/disk/by-id/ for permanent references.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
ls -l /dev/disk/by-id/ | grep -v part

The examples below use /dev/sdb through /dev/sde. Substitute your actual device paths. Double-check every path—mdadm will overwrite data without further prompting.

Wiping Existing Superblocks

If any disk was previously part of an array, zero its superblock first or mdadm may auto-assemble the wrong array on next boot.

sudo mdadm --zero-superblock /dev/sdb /dev/sdc /dev/sdd /dev/sde

Creating the Array

RAID 1 (2-disk mirror)

sudo mdadm --create /dev/md0 \
  --level=1 \
  --raid-devices=2 \
  /dev/sdb /dev/sdc

RAID 5 (3-disk)

sudo mdadm --create /dev/md0 \
  --level=5 \
  --raid-devices=3 \
  /dev/sdb /dev/sdc /dev/sdd

RAID 10 (4-disk)

sudo mdadm --create /dev/md0 \
  --level=10 \
  --raid-devices=4 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

mdadm immediately starts the initial sync in the background. The array is usable right away—you don't have to wait—but redundancy is not guaranteed until the sync completes.

Saving the Configuration

Write the array configuration to /etc/mdadm/mdadm.conf (Debian/Ubuntu) or /etc/mdadm.conf (Fedora/RHEL/Arch) so the array auto-assembles on boot.

# Debian/Ubuntu
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

# Fedora / RHEL / Rocky
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
sudo dracut --force

# Arch
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
sudo mkinitcpio -P

On Debian/Ubuntu the mdadm package hooks into update-initramfs automatically during install; run it again any time you change the config.

Formatting and Mounting

sudo mkfs.ext4 /dev/md0

sudo mkdir /mnt/raid
sudo mount /dev/md0 /mnt/raid

For a permanent mount, add the array to /etc/fstab. Use the UUID to be safe:

sudo blkid /dev/md0

# Add to /etc/fstab (substitute your UUID)
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/raid  ext4  defaults,nofail  0  2

The nofail option prevents the system from dropping to emergency mode if the array is degraded at boot time.

Monitoring the Array

Check array status

cat /proc/mdstat

Output shows sync progress, array state (active, degraded, recovering), and per-disk slot status. A U means a disk is up; _ means it is missing.

sudo mdadm --detail /dev/md0

This gives a full breakdown: array UUID, level, state, number of active/failed/spare devices, and each device's role.

Enable email alerts via systemd

mdadm can notify you of failures. Edit /etc/mdadm/mdadm.conf (or /etc/mdadm.conf) and add a MAILADDR line, then enable the monitoring service:

echo 'MAILADDR root@localhost' | sudo tee -a /etc/mdadm/mdadm.conf
sudo systemctl enable --now mdmonitor

On Fedora/RHEL the service is also called mdmonitor. Make sure your system has a local MTA or a mail relay configured, otherwise alerts go nowhere.

Scheduled scrubs

Most distributions ship a weekly cron job or systemd timer that runs a check. Verify it is active:

# systemd timer variant (Fedora/RHEL)
systemctl list-timers | grep raid

# Traditional cron (Debian/Ubuntu)
cat /etc/cron.d/mdadm

To trigger a scrub manually:

echo check | sudo tee /sys/block/md0/md/sync_action

Replacing a Failed Disk

This is the sequence you will follow in production. Do not skip the verify step.

1. Identify the failed device

sudo mdadm --detail /dev/md0
cat /proc/mdstat

Look for a device flagged (F) for faulty. Note its slot number.

2. Mark it faulty and remove it (if not already auto-removed)

sudo mdadm /dev/md0 --fail /dev/sdc
sudo mdadm /dev/md0 --remove /dev/sdc

3. Physically replace the drive, then add the new one

If your chassis supports hot-swap you don't need to power down. Otherwise shut down cleanly, swap the drive, and boot back up.

sudo mdadm /dev/md0 --add /dev/sdc

mdadm immediately begins rebuilding. Watch progress with:

watch -n 2 cat /proc/mdstat

4. Verify rebuild completion

sudo mdadm --detail /dev/md0 | grep -E 'State|Active Devices|Rebuild'

You want State : active and Active Devices back to the original count. Do not remove the array from monitoring until this is confirmed clean.

Boot Considerations

Using /dev/md0 as your root filesystem or hosting /boot on RAID adds complexity.

GRUB and RAID 1 on the boot partition: GRUB2 can read md RAID 1 arrays directly. After creating the array install GRUB to both member disks' MBR/ESP so the system boots if either drive fails: sudo grub-install /dev/sdb && sudo grub-install /dev/sdc.
UEFI systems: The EFI System Partition cannot be a RAID array (UEFI firmware reads raw FAT). Use a separate small ESP on each drive and keep them in sync with a bind-mount or efibootmgr entries pointing to each disk independently.
initramfs must include mdadm: The rebuild steps above (update-initramfs, dracut --force, mkinitcpio -P) regenerate the initramfs with mdadm assembly hooks. Skipping this step means the root array will not be assembled at boot and you will land in an emergency shell.
Kernel module autoload: The raid1, raid5, etc. modules are autoloaded on modern kernels when mdadm assembles the array. No manual configuration is normally needed.

Troubleshooting

Array stuck in degraded state after reboot: Run sudo mdadm --assemble --scan manually. If it fails, check that /etc/mdadm.conf was updated and the initramfs was regenerated.
mdadm --create fails with "device busy": A previous array superblock is still being auto-assembled. Run sudo mdadm --stop /dev/mdX for any auto-assembled device, then zero superblocks and retry.
Rebuild speed is very slow: The kernel throttles rebuild I/O by default to protect foreground workloads. Temporarily raise the minimum speed: echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_min. Restore to default (1000) once done.
Wrong array assembled from stale superblock: Use sudo mdadm --examine /dev/sdX to inspect a disk's superblock metadata without assembling it, then zero and re-create as needed.