RAID levels
| Level | What it does | Example from 4 disks of 1 TB | Protection |
|---|---|---|---|
| 0 (stripe) | Parallelize I/O | 4 TB | NONE; one disk dies = everything lost |
| 1 (mirror) | Full copies | 1 TB (mirror) | Survives N-1 disk failures |
| 5 | Striping + parity | 3 TB | Survives 1 disk failure |
| 6 | Striping + 2 parity | 2 TB | Survives 2 disk failures |
| 10 | Stripe of mirrors | 2 TB | One failure per mirror |
RAID 0 is not RAID in the sense of reliability. It is just a stripe for speed.
Creating an array
# RAID 1 (mirror) from two disks
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
cat /proc/mdstat # build progress
sudo mdadm --detail /dev/md0 # full details
# Create the filesystem
sudo mkfs.ext4 /dev/md0
sudo mount /dev/md0 /mnt/raid
# Save the config so the array assembles after a reboot
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u # debian/ubuntu
Array state
cat /proc/mdstat
▸typically looks like:
# md0 : active raid1 sdb1[0] sdc1[1]
# 976630464 blocks super 1.2 [2/2] [UU]
▸[UU] = both disks "Up"; [U_] = one disk dropped out
▸"resync" / "recovery" with progress = a rebuild is running
sudo mdadm --detail /dev/md0
▸State: clean / degraded / resyncing
The /proc/mdstat file is the main source of truth. A healthcheck just
parses it for the presence of [U_].
Disk failure
# Simulate a failure
sudo mdadm /dev/md0 --fail /dev/sdc1
# Remove it from the array
sudo mdadm /dev/md0 --remove /dev/sdc1
# Replace with a new disk (same size!)
sudo mdadm /dev/md0 --add /dev/sdd1
# The array starts the rebuild automatically. Watch it:
watch -n 1 cat /proc/mdstat
While the rebuild runs the array is degraded, and one more failure means everything is gone. On large RAID 5/6 arrays the rebuild can take days. That is where RAID 5 gets its reputation as "dangerous" for disks over 2 TB.
Spare disk
sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 \
--spare-devices=1 /dev/sd{b,c,d}1 /dev/sde1A spare waits in the pool. When any active disk fails, mdadm starts the rebuild onto it automatically. This shrinks the window of vulnerability sharply.
The stack: RAID + LVM + filesystem
A standard server setup:
/dev/sd[bcd]1 ← RAID 5 → /dev/md0 ← LVM PV → vg-data → lv-web → ext4 → /mnt/web
Each layer adds its own thing:
- RAID gives you reliability
- LVM gives you flexible sizing and snapshots
- the filesystem holds the actual files
Hardware vs software
- Hardware RAID (a controller on PCI): the OS sees a ready-made "disk". Pros: a battery-backed write cache, the CPU is offloaded. Cons: vendor lock-in (if the controller dies you need an identical one); firmware bugs.
- Software RAID (mdadm): runs on any hardware, is portable, and the OS sees and controls it. Cons: it uses CPU and RAM; there is no native battery-backed cache.
For most cases software RAID + a UPS is the better choice: it is portable, debuggable, and has no vendor lock-in.
ZFS and btrfs as an alternative
zfs and btrfs have built-in RAID (RAID-Z, btrfs raid). They keep data
checksums and therefore detect bit rot on read better (md RAID trusts that
"the disk said OK"). The downside is they are more complex, and btrfs RAID 5/6
has historically been buggy.