RAID Basics - yourlinuxguide.com

LVM Basics can span a volume group across multiple disks, but that alone provides no protection against a disk failing - lose one disk in a spanned volume group and you lose data across all of it. RAID specifically exists to survive a disk failure (or improve performance), and the two are often used together: RAID for redundancy underneath, LVM for flexible volume management on top.

The RAID levels that matter

Level	Layout	Tolerates	Usable capacity (n disks)
RAID 0	Striping, no redundancy	Nothing - any disk failing loses everything	100% (n × disk size)
RAID 1	Mirroring	1 disk failure (with 2 disks)	50% (1 × disk size)
RAID 5	Striping + 1 distributed parity	1 disk failure	(n-1) × disk size
RAID 6	Striping + 2 distributed parity	2 disk failures	(n-2) × disk size
RAID 10	Mirrored pairs, then striped	1 failure per mirrored pair	50%

RAID 0 is really "not RAID" in the redundancy sense - it improves performance by spreading I/O across disks, but a single disk failure loses the entire array. Everything else on this list exists specifically to survive a failure, at the cost of usable capacity or write performance.

Creating a software RAID array with mdadm

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

Creates a RAID 1 (mirror) array named /dev/md0 from two partitions. From here, treat /dev/md0 like any block device - partition or filesystem it directly (see Disk Partitioning):

sudo mkfs.ext4 /dev/md0
sudo mount /dev/md0 /mnt/data

Checking array status

cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sdc1[1] sdb1[0]
      976630464 blocks super 1.2 [2/2] [UU]

[2/2] [UU] means both of 2 expected disks are present and Up - a degraded array shows something like [2/1] [U_], an immediate signal to replace the failed disk before a second failure causes actual data loss.

sudo mdadm --detail /dev/md0

Gives full detail: array state, each member disk's role, and rebuild progress if one is currently in progress.

Replacing a failed disk

sudo mdadm --manage /dev/md0 --fail /dev/sdc1     # mark a disk as failed (if not automatic)
sudo mdadm --manage /dev/md0 --remove /dev/sdc1
# physically replace the disk, partition the new one identically, then:
sudo mdadm --manage /dev/md0 --add /dev/sdc1

The array automatically starts rebuilding onto the new disk, readable in /proc/mdstat as a resync percentage - the array remains usable (though at reduced performance and, for a moment, without full redundancy) throughout the rebuild.

Persisting the array across reboots

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

Without this, the kernel can usually still reassemble arrays it recognizes from disk metadata alone, but writing the config explicitly is the reliable, distro-recommended way to make sure /dev/md0 comes back with the same name and members after every boot.

RAID is not a backup

RAID protects against a disk failing, not against a file being deleted, a filesystem getting corrupted, or ransomware encrypting everything in place - any of those get faithfully replicated across every mirror or parity block in the array, just as reliably as good data would be. See Backups for what actually protects against those failure modes; RAID and backups solve different problems and neither substitutes for the other.

Hardware RAID and LVM as alternatives

Dedicated hardware RAID controllers do the same job in a separate card, transparent to the OS (which just sees one disk) - less common now that mdadm is mature and doesn't tie the array to a specific controller that might itself fail. LVM also supports basic mirroring (lvcreate --type raid1), useful when you're already committed to LVM and want redundancy on a specific logical volume without managing a separate mdadm layer underneath it.