Software RAID

Software RAID combines two or more block devices into a single logical array that survives disk failure, increases throughput, or both, using the kernel's md (multiple device) driver instead of a dedicated hardware controller. On Debian and Ubuntu you create and manage arrays with the mdadm tool; the array appears as /dev/md0 and you partition, format, or hand it to LVM exactly like a physical disk.

Because the parity and mirroring work happens in the kernel on your CPU, software RAID has no proprietary on-disk format and no controller to fail or to source a matching replacement for. The operational consequence is concrete: a failed disk in a RAID 1 or RAID 5 array keeps serving reads and writes in degraded mode, but you remain responsible for noticing the failure, swapping the disk, and triggering the rebuild — none of that is automatic, and a second failure during a rebuild can lose the whole array.

RAID Levels and Their Trade-offs

The md driver implements the standard levels plus a Linux-specific RAID 10. RAID 0 stripes data across all members for capacity and speed with zero redundancy — one disk lost means the array is gone. RAID 1 mirrors every block to all members, so an N-disk mirror tolerates N−1 failures but gives you only one disk of usable capacity. RAID 5 stripes data with one parity block per stripe and tolerates a single failure; RAID 6 carries two parity blocks and tolerates two.

Level	Min disks	Usable capacity	Failures tolerated	Typical use
RAID 0	2	100%	0	Scratch, caches, rebuildable data
RAID 1	2	1 disk	N−1	Boot and root volumes
RAID 5	3	N−1 disks	1	Capacity with some redundancy
RAID 6	4	N−2 disks	2	Large arrays, long rebuilds
RAID 10	4	50%	1 per mirror set	Databases, mixed read/write

RAID 5 carries a hidden cost called the write penalty: every small write must read the old data and old parity, recompute, and write both back, turning one logical write into four I/O operations. On large arrays of multi-terabyte disks, RAID 6 is preferred over RAID 5 because rebuild times now run for many hours, and the probability of a second disk or an unrecoverable read error appearing during that window is no longer negligible.

Creating and Inspecting an Array

You assemble an array from whole disks or partitions with mdadm --create. Using GPT partitions of type Linux RAID rather than raw disks makes the members self-describing and avoids confusion when a disk is moved between machines. After creation the kernel begins an initial sync, and the array is usable — though slower — while that sync runs.

# create a 3-disk RAID 5 array from partitions
mdadm --create /dev/md0 --level=5 --raid-devices=3 \
      /dev/sdb1 /dev/sdc1 /dev/sdd1

# watch the initial sync and overall state
cat /proc/mdstat
mdadm --detail /dev/md0

The file /proc/mdstat is the fastest health check: it lists each array, its level, its members, and a status line such as [UU_] where each U is an up member and an underscore is a missing one. mdadm --detail adds the array UUID, the sync percentage, and the per-device roles you need before replacing hardware.

Persistent Assembly and the Boot Path

An array that works after --create will not reassemble after a reboot unless its definition is recorded. Write the array's UUID into /etc/mdadm/mdadm.conf (the path is /etc/mdadm.conf on Red Hat and Fedora), then refresh the initramfs so the array can be assembled early enough to mount the root filesystem.

# append the running array's definition to the config
mdadm --detail --scan | tee -a /etc/mdadm/mdadm.conf

# Debian/Ubuntu: rebuild the initramfs so md0 assembles at boot
update-initramfs -u
# Red Hat/Fedora equivalent: dracut -f

Reference the array in /etc/fstab by its filesystem UUID from blkid, never as /dev/md0, because the kernel may enumerate an unconfigured array as /dev/md127 after a reboot. If you forget to update the initramfs on a root-on-RAID system, the machine drops to an initramfs shell because the root device cannot be assembled.

Failure Handling and Rebuilds

When a disk fails, the array continues in degraded mode and the md driver marks the member faulty. You replace it by failing and removing the bad device, partitioning the new disk identically, and adding it back; the rebuild starts automatically. Configure mdadm --monitor with a MAILADDR line in the config so a failure pages you instead of waiting to be discovered.

# fail, remove, then add the replacement disk
mdadm /dev/md0 --fail /dev/sdc1 --remove /dev/sdc1
mdadm /dev/md0 --add /dev/sde1

# cap rebuild speed so it does not starve production I/O
echo 50000 > /proc/sys/dev/raid/speed_limit_max

Add a hot spare with --add-spare so a rebuild begins the instant a disk is marked faulty, before anyone reads the alert. Schedule a periodic check scrub — Debian and Ubuntu ship a monthly cron job for this — to read every block and detect silent unrecoverable read errors while the array is still redundant, rather than discovering them mid-rebuild when there is no longer any parity to reconstruct from.

RAID Is Availability, Not Backup

RAID protects against disk hardware failure, and nothing else. It happily mirrors or stripes an rm -rf, a corrupting application bug, a ransomware encryption pass, or a bad write to all members at once. A controller-free mirror also does nothing for fire, theft, or a filesystem that corrupts its own metadata.

Keep independent, versioned, off-host backups regardless of RAID level, and test restores. Treat RAID as an availability mechanism that buys time to replace a disk without downtime, not as a recovery mechanism for data you deleted or corrupted. Parity levels also carry a write-hole risk: if power is lost mid-stripe, data and parity can disagree, which is why a battery-backed cache or a journaled array matters for RAID 5 and 6.