This is the piece that’s easy to skip because it doesn’t feel urgent the way a dead drive does. It only matters on the day it matters, and by then it’s too late to retroactively encrypt a drive that already left the building unencrypted.

What “encryption at rest” actually protects against

Encryption at rest protects data on a drive that is powered off or otherwise not actively unlocked. It does not protect against:

• A compromised, already-unlocked system (if someone has shell access to a live, mounted encrypted volume, encryption isn’t doing anything at that point)
• Malware or ransomware running under your own user account
• You forgetting the passphrase and having no recovery key saved anywhere

It does protect against:

• A drive being physically removed, lost, stolen, or improperly disposed of
• A failed drive going back to a manufacturer or recycler with your data still readable on the platters
• Someone with physical access to a powered-off machine pulling a drive

If your threat model is “what happens when hardware leaves my control,” encryption at rest is the right tool. If your threat model is “what happens if my running server gets compromised,” you need different controls entirely (network segmentation, backups that aren’t reachable from the compromised host, etc.) - encryption at rest won’t save you there.

The three real options

LUKS (Linux Unified Key Setup)

LUKS is the standard block-device encryption layer on Linux, sitting underneath whatever filesystem you put on top of it (ext4, XFS, even a ZFS pool’s member vdevs, though that’s an unusual combination). It encrypts the entire block device, so everything written to it, filesystem metadata included, is opaque without the key.

Strengths:

• Mature, extremely well-audited (it’s been the Linux standard for two decades), no filesystem-specific quirks to learn
• Works under literally any filesystem you put on top of it
• Supports multiple key slots, so you can have a passphrase for daily unlock and a separate recovery key stored somewhere safe, without sharing one secret between both uses
• TPM-backed auto-unlock is well-supported (clevis + tang, or systemd-cryptenroll with a TPM2 chip) if you want a server to unlock itself on boot without typing a passphrase into a headless machine

Weaknesses:

• It’s a block-device layer, not filesystem-aware, so it doesn’t get any of ZFS’s self-healing/checksum benefits for free, you still need those from the filesystem on top
• Per-drive LUKS containers in a multi-drive array mean you’re unlocking N separate volumes, which is more key management overhead than a single ZFS pool with native encryption
• No built-in replication or send/receive story, that’s the filesystem’s job if you layer one on top

Best fit: a non-ZFS array (mdadm/LVM, or a single external drive), or any setup where you specifically want the encryption layer decoupled from the filesystem.

ZFS native encryption

Added in ZFS 0.8 (OpenZFS), this encrypts data at the dataset level rather than the whole pool, meaning you can have encrypted and unencrypted datasets side by side in the same pool, each with its own key. The pool structure and dataset names remain visible unencrypted; only data content and most metadata are encrypted.

Strengths:

• Fits straight into an existing ZFS workflow if you’re already running ZFS for the pool-layout reasons covered in the ZFS pool layout guide - no extra layer, no extra tooling
• Per-dataset keys mean you can encrypt just the sensitive dataset (say, a tank/documents dataset) and leave bulk media unencrypted if you don’t care about privacy for that content, saving the CPU overhead where you don’t need it
• zfs send/zfs receive can transmit encrypted datasets without decrypting them first, so an off-site replication target never needs the key at all, it just holds encrypted blocks it can’t read. That’s a genuinely unique property neither LUKS nor VeraCrypt gives you cleanly.
• Native AES-GCM/AES-CCM, hardware-accelerated on any modern CPU with AES-NI, overhead is close to negligible in practice

Weaknesses:

• Some metadata (dataset names, snapshot names, properties) is not encrypted, so it leaks structural information even with data encrypted - usually a non-issue, but worth knowing
• Raw send (zfs send -w) for encrypted datasets has had real historical bugs around certain edge cases in older OpenZFS versions; keep your ZFS version current and test a restore before trusting it blind
• Key management is pool/dataset-specific, different mental model if you’re used to LUKS’s single-block-device-per-key approach

Best fit: anyone already running ZFS (TrueNAS, Proxmox-with-ZFS, a DIY ZFS box) who wants selective, low-overhead encryption that plays nicely with send/receive-based off-site backups.

VeraCrypt

VeraCrypt (the actively maintained successor to the abandoned TrueCrypt) creates encrypted containers or encrypts whole volumes, and crucially, it’s cross-platform: Windows, macOS, and Linux all read the same container format. It also supports hidden volumes (plausible deniability via a decoy volume) which neither LUKS nor ZFS offer.

Strengths:

• The only option here that’s genuinely cross-platform without extra tooling, if you need the same encrypted volume readable from both a Linux NAS and a Windows desktop, this is the practical answer
• Container-file mode means you don’t need to dedicate a whole physical drive or partition, a single large file can be the encrypted volume, which is convenient for portable/removable media
• Hidden volume support, a real feature if your threat model includes someone compelling you to reveal a password

Weaknesses:

• Container-file mode adds a filesystem-on-top-of-a-file-on-top-of-a-filesystem layer, with the performance and complexity overhead that implies, not ideal for a large active media library
• No native integration with ZFS/RAID redundancy or checksumming, it’s a straightforward encryption layer with no awareness of what’s underneath or on top
• Mounting/unmounting at scale (dozens of TB, many datasets) is clunkier than LUKS’s or ZFS’s native tooling, VeraCrypt is built around the mental model of a handful of volumes, not a large multi-dataset archive

Best fit: portable/removable drives, cross-platform shares, or any case where the encrypted volume genuinely needs to be read on a non-Linux machine without a Linux-specific driver stack.

The decision in practice

For a homelab data hoard specifically, the choice usually comes down to what you’re already running:

• Already on ZFS (TrueNAS, Proxmox ZFS pool, DIY OpenZFS box): use ZFS native encryption. It’s already there, the overhead is minimal, and the encrypted-send-to-off-site-target property is a real, concrete win if you’re doing zfs send-based off-site backups per the 3-2-1 backup guide.
• mdadm/LVM array, or a filesystem other than ZFS: LUKS underneath whatever filesystem you’re using. It’s the most mature option and doesn’t care what’s on top of it.
• A drive or volume that needs to move between Linux, Windows, and Mac, or that you want to carry around: VeraCrypt. Nothing else here is genuinely cross-platform.

Key management is the part people skip

Whichever option you pick, the encryption itself is the easy part. The failure mode that actually bites people is losing the key.

• Store a recovery key somewhere that isn’t the encrypted drive itself. A LUKS header backup (cryptsetup luksHeaderBackup), a ZFS wrapping key, or a VeraCrypt volume header backup all need to live somewhere independent of the volume they unlock, a password manager, a printed copy in a safe, a separate encrypted USB stick kept elsewhere.
• Test the recovery path before you need it. Restore from the backup key on a spare machine at least once. A recovery key you’ve never actually used to unlock anything is a recovery key you don’t actually know works.
• Decide your unlock model up front for anything headless. A home server that reboots unattended needs either a TPM-backed auto-unlock (LUKS+TPM2, or a ZFS key stored in a protected location) or someone physically present to type a passphrase after every reboot, including after a power outage your UPS didn’t fully cover. Pick one deliberately rather than discovering the gap the first time the server reboots while you’re not home.

None of this is exotic cryptography. It’s standard, well-supported tooling on every platform covered here. The only real risk is treating it as optional because a dead or stolen drive feels like someone else’s problem, right up until it’s an unencrypted drive with your data on it in someone else’s hands.