Handling ZFS Encryption Keys Right in TrueNAS Replication

ZFS native encryption has been production-grade in TrueNAS for years — and with SCALE 25.10 (“Goldeye”) it is the default on the primary storage for most of our clients. The moment a replication task enters the picture, however, the questions pile up: Is the data transferred encrypted? Does the key also end up on the secondary system? And who can still get to the data when the management workstation is down?

This article clears up the most common misconceptions and shows a setup that we run in production across several sites — including the exact steps that actually matter during recovery.

Raw Send: why you almost always want it

ZFS offers two ways to replicate an encrypted dataset. With classic zfs send the dataset is decrypted on the source, plaintext flows through the send stream and gets re-encrypted at the destination using its own encryption root (or not at all). With raw send — the option is simply called “Encryption” in the TrueNAS replication task and corresponds to zfs send --raw — the dataset stays encrypted from start to finish. The source does not even need the key loaded, the destination stores the blocks exactly as they sat on disk.

For almost every SMB backup scenario raw send is the right choice:

• The key never travels over the replication link.
• A compromised secondary or a stolen backup appliance does not leak any plaintext.
• The replication link does not strictly need an additional TLS layer — TrueNAS uses SSH anyway, but even a passive listener would gain nothing.
• Snapshots, properties and the entire key hierarchy are preserved 1:1.

The price: on the secondary the dataset is not readable without the key. In most cases that is exactly what you want.

Setup in TrueNAS SCALE 25.10 — step by step

Consider a typical setup: primary NAS nas01 in Neuburg, backup NAS nas02 at a sister site, both running TrueNAS SCALE 25.10. On nas01 the pool tank holds the dataset tank/fileserver, encrypted with a 256-bit AES key (key format hex, stored in the TrueNAS KMIP interface or as a local encrypted file).

1. Periodic Snapshot Task on nas01 for tank/fileserver, recursive, every 30 minutes, retention 2 weeks.
2. SSH connection from nas01 to nas02 — set up semi-automatically through the TrueNAS UI so the public key lands cleanly in the replication user’s ~/.ssh/authorized_keys.
3. Replication task: source tank/fileserver, destination backup/nas01/fileserver on nas02. Transport: SSH+NETCAT for highest throughput on the LAN, plain SSH over the WAN. Crucial: enable “Replicate encrypted dataset” and “Encryption” so the stream runs as a raw send.
4. Property excludes — TrueNAS hides a few properties by default, but the encryption hierarchy is kept intact.

After the first run backup/nas01/fileserver appears on nas02 as an encrypted, locked dataset. zfs get keystatus reports unavailable, the content is not mounted — exactly right.

Key management: the management station as the single source of truth

The real security question is not “is it encrypted?” but “who holds the key?”. For our clients we typically recommend the following model:

Location	What lives there	Purpose
Primary NAS nas01	Key loaded, dataset unlocked	Production operation
Backup NAS nas02	Key NOT loaded, dataset locked	Pure block retention
Management station	Master copy of all keys, GPG-encrypted	Recovery, audit, key rotation
Offline vault	Printed hex key or smartcard	Last-resort fallback

In our setups the management station is a hardened Linux client (Debian 13 or a dedicated mini-PC with disk encryption) holding the keys in a GPG-encrypted file or a pass database. It is used exclusively for recovery and rotation tasks — not for day-to-day work.

Important: the replication user on nas02 may create and write datasets, but must not automatically load keys. That separation is what makes the difference between “backup” and “second attack surface”.

Recovery walk-through: when the backup becomes the primary

Let us walk through a real incident. nas01 is gone after a water damage, the pool is lost, the TPM-backed key on the system is gone too. nas02 holds every snapshot as a raw replica. This is how you bring the data back online:

# 1. Log in to nas02 and check the state
zfs list -t all backup/nas01/fileserver
zfs get keystatus,encryption,keyformat backup/nas01/fileserver

# 2. Fetch the key from the management station (scp from GPG container)
#    and place it temporarily on nas02, e.g. /root/keys/fileserver.key
chmod 600 /root/keys/fileserver.key

# 3. Load the key and unlock the dataset
zfs load-key -L file:///root/keys/fileserver.key backup/nas01/fileserver
zfs mount backup/nas01/fileserver

# 4. Roll back to the desired snapshot if needed
zfs list -t snapshot backup/nas01/fileserver | tail
zfs rollback backup/nas01/fileserver@auto-2026-06-25_22-00

# 5. Re-publish the share (SMB/NFS config from the config backup)
#    and shred the key file
shred -u /root/keys/fileserver.key

With practice this runs in under ten minutes and depends on exactly one critical input: the key from the management station. That is precisely why every emergency runbook needs a clear entry titled “key access: who, how, where”.

Common traps from the field

When we take over existing environments we keep seeing the same patterns that bite hard during recovery:

• Key permanently loaded on the backup NAS. Convenient, but pointless from a security standpoint — a break-in at the backup site immediately yields plaintext.
• Replication without raw send. The secondary either inherits no encryption at all or grows its own encryption root whose key nobody has documented.
• Key stored only inside the TrueNAS web UI. When the boot pool dies and no export exists, the key is gone. TrueNAS exposes the export under Datasets > Encryption Options — use it after every rotation.
• Snapshots pruned automatically on nas02. Sounds logical, gets dangerous when the destination pruning policy is stricter than the source. We always configure longer retention on the destination than on the source.
• No regular restore drill. Once a quarter a random dataset should actually be unlocked and mounted on an isolated system — anything else is hope, not backup.

DATAZONE as your sparring partner

Encrypted replication is no black magic, but it requires a thoughtful interplay of storage design, key hygiene and documented recovery processes. We build exactly these setups for mid-market clients in Bavaria and beyond — with a clear runbook, tested restores and verifiable key management.

DATAZONE supports you with planning, migrating to TrueNAS and building a resilient backup strategy including replication. Reach out — the first conversation is free of charge: Get in touch.