kldload — your Linux construction kit

ZFS Wiki

Encryption — per-dataset, native, and replication-aware.

ZFS encryption operates at the dataset level, not full-disk encryption. Each dataset can have its own key. Keys can be prompted, loaded from a file, or fetched from a URL. And crucially: ZFS can replicate encrypted datasets without ever decrypting them.

ZFS encryption vs LUKS

ZFS native encryption

Per-dataset keys. Snapshot-aware. Replicate encrypted data without decrypting (zfs send -w). Clone and manage encrypted datasets independently. Keys managed by ZFS properties.

LUKS / dm-crypt

Entire volume encrypted with one key. Can't snapshot or replicate without decrypting first. If the LUKS header is lost, the data is permanently unrecoverable. No per-user or per-dataset granularity.

Real-world patterns

Multi-tenant encryption

A hosting company creates per-client encrypted datasets, each with a separate key. /clients/acme is encrypted with Acme's key. /clients/globo with theirs. Snapshots are retained for years. Backups replicated offsite. The receiver can't read the data — keys never leave the origin.

Even AWS can't read your data when you replicate encrypted datasets to S3. Keys never leave your machine.

Boot + encrypted home

Boot environment stays unencrypted (for ZFSBootMenu access), but /home is encrypted. Passphrase entered at boot. Or automated with systemd to load keys from a TPM or network keyserver.

# Create encrypted dataset
zfs create -o encryption=aes-256-gcm \
           -o keylocation=prompt \
           -o keyformat=passphrase \
           rpool/home

# Load key manually after reboot
zfs load-key rpool/home
zfs mount rpool/home

# Change passphrase
zfs change-key rpool/home

No recovery mechanism for forgotten passphrases. This is by design. If there were a backdoor, it wouldn't be encryption. Store your passphrase somewhere safe.

← ZFS Wiki ↑ Top