Losing a disk shouldn’t mean losing your data, and a stolen server shouldn’t mean a stolen database. Those are two separate problems, and Linux solves them with two separate tools: RAID for redundancy, and LUKS for encryption. This guide walks through both, and shows how to combine them safely on the same machine — something a lot of tutorials get backwards.

Table of Contents

1. Why Combine RAID and Encryption
2. RAID Levels Compared
3. Before You Start: Requirements
4. Step 1: Prepare the Disks
5. Step 2: Build the RAID Array with mdadm
6. Step 3: Encrypt the RAID Device with LUKS
7. Step 4: Format and Mount the Encrypted Volume
8. Step 5: Automate Unlocking on Boot
9. Monitoring RAID Health
10. Common Mistakes to Avoid
11. FAQ
12. Conclusion

Why Combine RAID and Encryption

RAID and encryption solve different problems, and people often confuse them. RAID protects you against a failed disk. It does nothing if someone steals the server or copies the drive. Encryption protects the data at rest, but on its own, it does nothing when a disk dies mid-write.

A production server — whether it’s a home NAS or a client’s file server — needs both. The trick is doing it in the right order.

RAID Levels Compared

Pick a RAID level based on how many disks you have and how much data loss you can tolerate.

RAID Level	Min. Disks	Usable Space	Fault Tolerance	Best For
RAID 0	2	100%	None — one failure loses everything	Speed only, no important data
RAID 1	2	50%	Survives 1 disk failure	Boot drives, small servers
RAID 5	3	(n-1)/n	Survives 1 disk failure	General file storage
RAID 6	4	(n-2)/n	Survives 2 disk failures	Larger arrays, longer rebuild times
RAID 10	4	50%	Survives multiple failures (depends on layout)	Databases, high I/O workloads

If you’re only protecting two disks, RAID 1 is the simplest and safest choice. For four or more disks holding files that matter, RAID 6 gives you breathing room during a rebuild, when a second disk failure is most likely.

Before You Start: Requirements

You’ll need:

• A Linux distribution with mdadm and cryptsetup available (Debian, Ubuntu, RHEL/Rocky, and Arch all package both).
• At least two unused disks or partitions of similar size.
• Root or sudo access.
• A backup of anything currently on those disks — this process wipes them.

Install the tools first:

# Debian / Ubuntu
sudo apt update && sudo apt install mdadm cryptsetup

# RHEL / Rocky / AlmaLinux
sudo dnf install mdadm cryptsetup

# Arch Linux
sudo pacman -S mdadm cryptsetup

Step 1: Prepare the Disks

Identify your target disks with lsblk, and make sure you’re targeting the right ones before you do anything destructive.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

For this guide, assume two blank disks: /dev/sdb and /dev/sdc. Wipe any old filesystem signatures so mdadm doesn’t get confused by leftover metadata:

sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sdc

Step 2: Build the RAID Array with mdadm

Create a RAID 1 array from the two disks. Swap --level=1 for --level=5 or --level=6 if you have more disks.

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

Check that the sync started correctly:

cat /proc/mdstat

Save the array layout so it survives a reboot:

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

Let the initial sync finish before moving on — with large disks this can take hours. You can keep working; the array is usable during the sync, just slower.

Step 3: Encrypt the RAID Device with LUKS

This is the part where people commonly go wrong. Don’t encrypt each disk individually — encrypt the RAID device (/dev/md0) after it’s assembled. This way, mdadm sees plain block devices and handles the redundancy, while LUKS sees one clean volume and handles the encryption. If you encrypt the disks first, mdadm has to sync encrypted data, which wastes CPU and complicates recovery.

Initialize LUKS on the RAID array:

sudo cryptsetup luksFormat /dev/md0

Cryptsetup asks you to confirm and then set a passphrase. Choose something long — a passphrase, not a short password. Then open the encrypted volume, which creates a mapped device you can use like a normal disk:

sudo cryptsetup luksOpen /dev/md0 secure_data

You’ll now have a new device at /dev/mapper/secure_data.

Step 4: Format and Mount the Encrypted Volume

Format the mapped device with your filesystem of choice — ext4 is a safe default for general storage:

sudo mkfs.ext4 /dev/mapper/secure_data

Create a mount point and mount it:

sudo mkdir -p /mnt/secure_data
sudo mount /dev/mapper/secure_data /mnt/secure_data

Confirm it mounted correctly:

df -h /mnt/secure_data

Step 5: Automate Unlocking on Boot

By default, you’d have to run cryptsetup luksOpen manually after every reboot. For a server, that’s usually unwanted — you either want it to unlock automatically with a keyfile, or you want it to prompt you at boot.

Option A — keyfile (fully automatic, less secure if the server itself is stolen):

sudo dd if=/dev/urandom of=/root/secure_data.key bs=512 count=4
sudo chmod 400 /root/secure_data.key
sudo cryptsetup luksAddKey /dev/md0 /root/secure_data.key

Add entries to /etc/crypttab and /etc/fstab:

echo "secure_data /dev/md0 /root/secure_data.key luks" | sudo tee -a /etc/crypttab
echo "/dev/mapper/secure_data /mnt/secure_data ext4 defaults 0 2" | sudo tee -a /etc/fstab

Option B — passphrase prompt at boot (more secure, requires physical or console access):

echo "secure_data /dev/md0 none luks" | sudo tee -a /etc/crypttab
echo "/dev/mapper/secure_data /mnt/secure_data ext4 defaults 0 2" | sudo tee -a /etc/fstab

A keyfile is convenient for a headless server that reboots unattended. A boot-time passphrase is the better choice if the physical security of the machine is a real concern — for example, a server that could be physically removed from the premises.

Monitoring RAID Health

RAID only protects you if you actually notice when a disk fails. Set up regular checks and email alerts.

Check array status any time:

sudo mdadm --detail /dev/md0

Enable mdadm‘s built-in monitoring daemon so it emails you on failure:

sudo systemctl enable --now mdmonitor

Edit /etc/mdadm/mdadm.conf and set the MAILADDR line to your admin email address, then restart the service:

sudo systemctl restart mdmonitor

Run a monthly scrub to catch silent data corruption before it becomes a real failure:

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

Common Mistakes to Avoid

• Encrypting disks before assembling RAID. Encrypt the RAID device, not the individual members.
• Skipping backups of the LUKS header. If the header gets corrupted, the whole volume becomes unreadable, even with the correct passphrase. Back it up with cryptsetup luksHeaderBackup.
• Forgetting to update mdadm.conf after creating the array. Without it, the array may not reassemble automatically after a reboot.
• Using RAID 0 for anything you can’t afford to lose. RAID 0 has zero fault tolerance — it’s not backup, and it’s not safety.
• Never testing a disk-failure scenario. Simulate a failure with mdadm --fail in a test environment so you know your recovery process actually works before you need it for real.

FAQ

Does RAID replace backups? No. RAID protects against a hardware failure, not against accidental deletion, ransomware, or a fire. Keep a separate backup regardless of your RAID setup.

Can I add encryption to an existing RAID array without wiping it? Not in place. LUKS encryption changes how data is stored on disk, so you need to back up the data, encrypt the array, then restore.

Which is faster: encrypting before or after RAID? Encrypting the RAID device (after assembly) is both faster and simpler to manage, since the CPU only performs one encryption pass instead of one per disk.

What happens if I lose the LUKS passphrase? The data is unrecoverable by design. Store the passphrase in a password manager or your organization’s secrets vault, and keep a backup of the LUKS header in a separate secure location.

Is software RAID (mdadm) safe for production use? Yes. mdadm is stable and widely used in production Linux environments, including by major hosting providers. Hardware RAID controllers add cost and their own points of failure — mdadm avoids both.

Conclusion

Building resilient, secure Linux storage comes down to layering the right tools in the right order: mdadm for redundancy against disk failure, and LUKS for encryption against unauthorized access — encryption applied to the assembled RAID device, not to the individual disks. Combined with real monitoring and a tested backup plan, this setup gives you a storage layer that survives both a dead disk and a stolen server.