Learn RAID - Security & Encryption

#Introduction

Redundancy keeps the array running, backup keeps the data existing — but what protects data from the wrong hands? Episode 14 answers with encryption and integrity. A stolen disk, a seized server, or silently corrupted bits — each needs its own layer of protection.

In episode 11 we briefly touched on luks-on-raid versus raid-on-luks. Episode 14 covers it in depth, including native ZFS encryption, key management, and the checksums that set ZFS and btrfs apart from other filesystems. Let's start with the dm-crypt foundation.

#LUKS and dm-crypt on top of RAID

#The Hidden Layer

LUKS (Linux Unified Key Setup) is the standard format for disk encryption on Linux, built on top of dm-crypt from the kernel. When you use LUKS above the array, the entire /dev/md0 is encrypted as one unit:

sudo cryptsetup luksFormat /dev/md0
sudo cryptsetup open /dev/md0 raid_crypt

The cryptsetup luksFormat /dev/md0 command creates a LUKS container (confirm YES and create a strong passphrase), then cryptsetup open opens it as a mapper named raid_crypt. Once opened, the filesystem is created at /dev/mapper/raid_crypt.

#Luks-on-raid Advantages

This approach offers simplicity:

• One passphrase for the whole array.
• Rebuild without intervention: when a disk fails and is replaced, the raw data stays encrypted — no need to enter a passphrase repeatedly.
• Broadly compatible with mdadm and the kernel.

#Luks-on-raid Drawbacks

The other side: if you want to move a single disk out of the array, that disk is useless on its own because it only contains encrypted slices of data. For that flexibility, you use raid-on-luks.

#RAID on top of LUKS (Raid-on-luks)

#Per-disk Encryption

In this approach, each disk is encrypted on its own first, then combined into an array:

sudo cryptsetup luksFormat /dev/sdb
sudo cryptsetup luksFormat /dev/sdc
sudo cryptsetup open /dev/sdb crypt0
sudo cryptsetup open /dev/sdc crypt1
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/mapper/crypt0 /dev/mapper/crypt1

The command sequence above creates LUKS on each disk, opens them as mappers, then builds the array from those mappers. The result: each disk is standalone and encrypted, and the array's data never appears in plaintext on any disk.

#Raid-on-luks Tradeoffs

The main drawback: when a new disk replaces a failed one, you must create a fresh LUKS on the replacement with the same configuration. And at boot, every mapper needs to be opened — with many disks, this becomes cumbersome without keyfiles.

#Native ZFS Encryption

#ZFS Encryption

ZFS has built-in encryption that doesn't need dm-crypt:

sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase tank/secret

The zfs create -o encryption=aes-256-gcm command creates an encrypted dataset with AES-256-GCM. The advantage: snapshots, replication, and compression all keep working normally on top of encrypted data — encryption is integrated with the ZFS ecosystem.

#Native ZFS Advantages

Native ZFS encryption brings major benefits:

• Encrypted snapshots: snapshots can be received to another host while still encrypted.
• Per-dataset: part of the pool encrypted, part not, as needed.
• Key rotation without rewriting data.

#Key Management

ZFS keys can come from a passphrase, a keyfile, or auto-loaded at boot with tools like zfs-load-key and systemd:

sudo zfs load-key tank/secret

The zfs load-key tank/secret command loads the key into the kernel. For production, avoid passphrases that must be entered manually at every reboot; use a keyfile stored on a TPM or a separate key management server.

#Key Management and Safety

#Key Management Principles

• Store key copies in a location separate from the data — not on the same disk as the LUKS container.
• Back up the LUKS header: cryptsetup luksHeaderBackup saves the header containing the encryption keys; a corrupted header means unreadable data.
• Use a keyfile for automatic boot, with a passphrase as fallback.

sudo cryptsetup luksHeaderBackup /dev/md0 --header-backup-file /backup/luks-header.bin

The cryptsetup luksHeaderBackup command saves the LUKS header to a backup file. Store this file on secure media — without the header, all encrypted data becomes unopenable.

#Checksums and Silent Corruption

#ZFS and btrfs Checksums

Encryption protects against theft; checksums protect against corruption. ZFS and btrfs store a checksum per block, so when reading data, the filesystem can verify whether a block is still intact. This detects silent corruption — bit flips that hardware fails to catch.

sudo zpool status tank

The zpool status tank output shows an errors: column for every vdev. Any number other than zero indicates corrupted blocks were found. If ZFS has redundancy (mirror or RAIDZ), it repairs them automatically; if not, it reports the corruption — and that's when the backup from episode 12 comes into play.

#Scrubbing as Verification

A full checksum sweep is done through scrub — we'll cover how to schedule and run it in episode 15. For now, remember: checksums let ZFS and btrfs know when data is corrupted; plain RAID can't.

#Conclusion

Episode 14 completed the storage security layer: LUKS and dm-crypt encryption above or below RAID, native ZFS encryption with tidy key management, and checksums for detecting silent corruption. Your data is now safe from theft and silent corruption.

Key takeaways:

• Luks-on-raid is simple with one passphrase; raid-on-luks is flexible per disk.
• Native ZFS encryption integrates with snapshots and replication.
• Back up the LUKS header and keys in a location separate from the data.
• ZFS and btrfs store checksums to detect silent corruption.
• zpool status shows checksum errors per vdev.
• The combination of encryption and checksums is the foundation of modern storage.

In the next episode, episode 15, we'll discuss maintenance & scrub — running mdadm --check and --repair, zpool scrub, btrfs scrub, scheduling them routinely, plus physical care like UPS, disk aging, and firmware updates. You'll learn to keep storage healthy long-term.