Every Linux system administrator eventually faces the same two questions: “What happens if a disk dies tonight?” and “What happens if this laptop gets stolen tomorrow?” The first question is answered by RAID (Redundant Array of Independent Disks), which protects your data against hardware failure. The second is answered by disk encryption, which protects your data against unauthorized access.

Table of Contents

1. What RAID Actually Does (and Doesn’t Do)
2. RAID Levels Compared
3. Setting Up RAID 1 with mdadm
4. Persisting and Monitoring Your Array
5. Handling a Failed Disk
6. Encrypting a Drive with LUKS and cryptsetup
7. Combining RAID and Encryption the Right Way
8. Common Mistakes to Avoid
9. FAQ
10. Conclusion

1. What RAID Actually Does (and Doesn’t Do)

RAID combines multiple physical drives into a single logical volume. Depending on the level you choose, it can improve read/write performance, protect against a drive failure, or both. It does not protect you against accidental deletion, ransomware, or file corruption caused by software bugs — that’s what backups are for. A common mistake among newer admins is treating RAID as a backup strategy; it isn’t. RAID keeps a service running when a disk dies. A backup lets you recover when a human (or a piece of malware) makes a mistake.

2. RAID Levels Compared

Here’s a breakdown of the RAID levels you’re most likely to encounter on a Linux system, along with the minimum number of drives each one requires:

Level	Function	Minimum Drives
RAID 0	Striping across disks for speed; no redundancy	2
RAID 1	Mirroring; each drive is an exact copy of the other	2
RAID 4	Striping with a single dedicated parity disk	3
RAID 5	Striping with distributed parity	3
RAID 6	Striping with two independent parity blocks (survives two simultaneous failures)	4
RAID 10	Combines mirroring and striping for speed and redundancy	4

For most home labs and small servers, RAID 1 is the sweet spot: simple to configure, easy to reason about, and it survives the loss of one disk out of two. RAID 5 and RAID 6 make more sense once you have three or more drives and want more usable capacity than mirroring provides, at the cost of a rebuild that’s more CPU- and I/O-intensive.

3. Setting Up RAID 1 with mdadm

mdadm (Multiple Device Admin) is the standard Linux kernel tool for managing software RAID via the md driver. It ships in the default Ubuntu and Debian repositories and is considered production-grade — it’s used inside major cloud providers and storage appliances, not just home labs.

Install it first:

sudo apt-get update
sudo apt-get install mdadm

Identify your target disks with lsblk, then create the array. Important: use whole, unpartitioned disks or dedicated partitions that don’t contain data you need — this process is destructive to anything currently on those devices.

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

You’ll be prompted to confirm since existing metadata may be detected. Type y to proceed. The kernel will immediately start synchronizing the two disks in the background — you can keep working while this happens.

Check the sync status at any time:

cat /proc/mdstat

Once the array exists, create a filesystem and mount it like a normal disk:

sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/raid1
sudo mount /dev/md0 /mnt/raid1
df -h /mnt/raid1

4. Persisting and Monitoring Your Array

An array that isn’t saved to configuration will not reassemble correctly after a reboot, and this is one of the most common support requests we see. Save the array definition and rebuild the initramfs so the boot process recognizes it:

sudo mdadm --detail --scan --verbose | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

Then add a persistent mount entry using the array’s UUID rather than its device name, since device names like /dev/md0 can shift:

sudo blkid /dev/md0
sudo nano /etc/fstab

Add a line similar to:

UUID=xxxx-xxxx-xxxx-xxxx  /mnt/raid1  ext4  defaults  0  0

Test it without rebooting:

sudo mount -a

Monitoring matters more than most guides admit. A degraded RAID 1 array (one disk down) still functions normally from the user’s perspective — nothing looks broken until the second disk fails and takes your data with it. Set up email alerts through the mdmonitor service so you’re notified the moment a disk drops out:

sudo apt install mailutils -y
sudo nano /etc/mdadm/mdadm.conf
# Add: MAILADDR your-email@example.com
sudo systemctl enable --now mdmonitor
sudo mdadm --monitor --test --oneshot /dev/md0

That last command sends a test alert so you can confirm delivery actually works before you need it in an emergency.

5. Handling a Failed Disk

When a disk fails (or you want to simulate a failure for testing), the recovery sequence is: mark it failed, remove it, insert the replacement, then add it back to the array.

sudo mdadm /dev/md0 -f /dev/sdb      # mark the disk as failed
sudo mdadm /dev/md0 -r /dev/sdb      # remove it from the array
sudo mdadm /dev/md0 -a /dev/sde      # add the new replacement disk

The kernel automatically starts rebuilding the mirror onto the new disk in the background — you can watch progress with cat /proc/mdstat just as you did during the initial sync.

If you ever need to expand an existing array to include an additional disk (useful when migrating RAID 1 toward a RAID 10-style layout), --grow adjusts the device count:

sudo mdadm --grow /dev/md0 --raid-devices=3

Note that growing an array changes its risk profile and rebuild time, so plan this during a maintenance window rather than on a live production system.

6. Encrypting a Drive with LUKS and cryptsetup

RAID solves availability. It does nothing for confidentiality — if someone removes a drive from your array, its contents are just as readable as an unprotected disk. That’s where LUKS (Linux Unified Key Setup) comes in, implemented through the cryptsetup utility.

Format the volume for encryption:

sudo cryptsetup -y -v luksFormat /dev/sda1

You’ll be asked to type YES in uppercase to confirm, then set a passphrase. Choose something long and unique — this passphrase is the only thing standing between an attacker and your data, so weak or reused passwords defeat the entire purpose of encrypting the drive in the first place. A password manager-generated passphrase of 20+ characters is a reasonable baseline for anything sensitive.

Open (decrypt) the volume:

sudo cryptsetup -v luksOpen /dev/sda1 decryptvolume

This creates a mapped, decrypted device you can interact with normally. Confirm it exists:

ls /dev/mapper

You should see an entry named decryptvolume. From here, treat it like any other block device — format it and mount it:

sudo mkfs -t ext4 /dev/mapper/decryptvolume
sudo mkdir -p /mnt/secure
sudo mount /dev/mapper/decryptvolume /mnt/secure

Close the volume when you’re done:

sudo cryptsetup -v luksClose decryptvolume

Closing the mapping re-locks the data. Anyone who later powers on the disk without the passphrase sees only encrypted noise.

7. Combining RAID and Encryption the Right Way

A question we get often: should you encrypt the individual disks first, or encrypt the assembled RAID array? In almost every case, encrypt each underlying disk, then build the RAID array on top of the decrypted mappings — not the other way around. This has two advantages:

• Each disk is independently protected, so a stolen drive on its own is useless without the passphrase.
• The RAID layer only ever sees consistent, already-decrypted block devices, which avoids alignment and performance quirks that can appear when encrypting an assembled array as a single unit.

In practice this means running luksFormat and luksOpen on each physical disk (e.g. /dev/sdb and /dev/sdc) to produce /dev/mapper/cryptvol1 and /dev/mapper/cryptvol2, and then pointing mdadm --create at those mapped devices instead of the raw disks. It’s more setup work, but it’s the pattern used in most production and enterprise deployments for good reason.

8. Common Mistakes to Avoid

• Forgetting to persist configuration. Skipping mdadm.conf and update-initramfs means your array may not auto-assemble on reboot.
• Treating RAID as a backup. It isn’t. Keep offsite or offline backups regardless of your RAID setup.
• Using weak LUKS passphrases. Encryption is only as strong as the passphrase protecting it.
• Ignoring monitoring. A silently degraded array gives you zero warning before a second failure causes real data loss.
• Encrypting after striping instead of before. As covered above, encrypt disks before assembling them into the array where possible.

9. FAQ

Does RAID 1 double my read speed? It can improve read performance since data can be read from either mirror, but write speed is generally limited to that of a single disk because both copies must be written.

Can I recover data from a RAID array if I lose the encryption passphrase? No. LUKS is designed so that without the passphrase (or a backed-up header/key file), the data is cryptographically unrecoverable. Always store a LUKS header backup and passphrase in a secure, separate location.

Is hardware RAID better than software RAID with mdadm? Hardware RAID offloads processing to a dedicated controller, but it ties your array to that specific controller model. Software RAID via mdadm is portable across hardware, actively maintained, and used in production at scale — a solid choice for most self-managed servers.

10. Conclusion

RAID and encryption solve two different problems, and a resilient Linux storage setup needs both. mdadm gives you a reliable, well-documented path to disk redundancy — create the array, format it, persist the configuration, and set up monitoring so you actually find out when something breaks. cryptsetup and LUKS then add a layer of confidentiality so that redundancy doesn’t come at the cost of security. Encrypt your disks before you mirror or stripe them, keep your passphrases and LUKS header backups safe, and pair all of it with a real backup strategy that lives outside the array entirely.