Setting up a TrueNAS replication task takes five steps: give the remote admin user SSH access and passwordless sudo, add an SSH connection under Credentials > Backup Credentials using Semi-automatic, build the task in Data Protection > Replication Tasks > Add with Use Sudo for ZFS Commands ticked, click Run Now, then prove the copy with a restore.
Local replication between two pools in one box skips the SSH steps and uses the LOCAL transport. Menu paths here are from TrueNAS 25.10 “Goldeye”. The first run sends everything the source snapshot references; every later run sends only what changed since the last snapshot both sides share.
Skip this if your second copy is a USB disk or a cloud bucket: replication needs ZFS on both ends, and rsync or cloud sync tasks cover those. The cloud is a perfectly good third copy. Everyone else, budget an evening for setup and a night for the first send.
What do you need before creating a replication task?
You need a source dataset with snapshots on a schedule you chose, an empty dataset on a ZFS destination, and, for remote replication, an admin account on the remote system with a home directory, SSH access and passwordless sudo, plus its SSH service running. Root isn’t required; the 25.10 docs walk the whole flow with a non-root admin.
An empty destination. The remote replication tutorial says to verify the destination “is free of existing snapshots, or that snapshots with critical data are backed up before you create the task.” Unrelated snapshots on the target are how people end up reaching for Replication from Scratch, which destroys them.
A schedule you designed. TrueNAS “automatically creates a periodic snapshot task for sources that have no existing snapshots.” Convenient, but it’s a schedule you never designed. Build tiered snapshot tasks first using our snapshot schedule best practices, then hang replication off them. The advanced replication docs require the replication task’s Recursive and Exclude Child Datasets settings to match the snapshot task it uses.
The destination needs no horsepower: a small TrueNAS box with a mirrored pair of drives, ideally in another building, covers a household’s documents and photos.
Step 1: Prepare the admin user on the remote system
For a push backup, the remote system is the destination. Edit its admin user under Credentials > Users and work through the tutorial’s list:
- Home Directory: select Create Home Directory and pick a dataset;
/var/emptywon’t do. - SSH Access: enabled.
- Sudo Commands: the documented choice is Allow all sudo commands with no password.
- SSH service: under System > Services > SSH, set Start Automatically and start it.
“Allow all” is broad for an account that only moves backups. The advanced docs name the binaries that matter, /usr/sbin/zfs plus /usr/bin/python3 for SSH+NETCAT; scoping passwordless sudo to those is reasonable hardening, at the cost of leaving the documented path.
Step 2: Add the SSH connection
On the local system, open Credentials > Backup Credentials and click Add on SSH Connections, or choose Add New from the wizard’s SSH Connection dropdown. Per the SSH screens reference:
- Setup Method: Semi-automatic (TrueNAS only), the default. Manual is for non-TrueNAS ZFS servers.
- TrueNAS URL: the remote system with a scheme, such as
https://192.168.1.50. - Admin Username: defaults to root; change it to your admin, and add the Admin Password (plus a One-Time Password with two-factor).
- Username: the SSH login on the remote, normally the same admin.
- Private Key: Generate New.
After saving, do the step that’s easy to miss: copy the connection’s public key into the remote admin user’s Public SSH Key field, as the tutorial instructs.
Going offsite: Tailscale, not a port-forward
For a box at a relative’s house, don’t forward port 22 to the internet. Tailscale’s TrueNAS guide covers replication directly: install the Tailscale app on both systems, “Uncheck the Userspace box and check the Host Network box,” and use the remote’s 100.x.y.z tailnet address as the host. Nothing listens publicly, and there’s no dynamic DNS record to babysit.
Step 3: Fill in the replication wizard
Open Data Protection > Replication Tasks and click Add. The wizard has two screens, What and Where then When. For a push backup, per the replication task screens reference:
| Field | Set it to | Why |
|---|---|---|
| Source Location | On this System | Push from the main NAS |
| Destination Location | On a Different System | On this System makes it local |
| Destination | Pool path plus /newname | A new name creates the dataset |
| Use Sudo for ZFS Commands | On | Needed for a non-root admin |
| Recursive | Match the snapshot task | Includes child datasets |
| Replication Schedule | Run On a Schedule | Run Once suits one-off migrations |
| Destination Snapshot Lifetime | Same as Source | Never Delete grows forever |
Save, and the task shows PENDING. Click Run Now rather than waiting for the schedule, and watch the first full send while you’re around to fix it.
Consider pulling instead: create the task on the backup box with Source Location set to On a Different System, and Step 1 applies to the main NAS. The backup box then holds the key, so an attacker who owns the main NAS finds no stored connection to the backups.
Then confirm from a shell on the backup box:
# newest snapshots that landed on the backup
zfs list -t snapshot -o name,creation -s creation -r tank/backup/documents | tail -n 5
# reports "on" once the read-only policy is SET
zfs get -H -o value readonly tank/backup/documentsWhich advanced settings should you change?
Change three: turn on Save Pending Snapshots, set Destination Dataset Read-only Policy to SET, and pick the transport on purpose. Leave Replication from Scratch off and treat Allow Blocks Larger than 128KB as permanent. All of them live on the Advanced Replication Creation screen, or the task’s Edit screen once the wizard has made it.
- Save Pending Snapshots “prevents the source TrueNAS from automatically deleting any snapshots that failed to replicate to the destination system.” Without it, snapshots taken during an outage can expire before they’re ever sent. The cost is a pile-up on the source while things are broken.
- Read-only policy SET makes destination datasets read-only after each successful run, so nobody, including you at 1 a.m., edits the backup and drifts it from the source.
- Transport: SSH is the default. SSH+NETCAT connects over SSH, then uses py-libzfs to send an unencrypted data stream for higher speeds. Use it on a trusted LAN or inside a tailnet, nowhere else.
- Replication from Scratch is documented as “Destroy all data in destination snapshots, and do a full replication,” for when the two sides share no snapshot. The advanced docs call the related sync option “a very destructive option.”
- Allow Blocks Larger than 128KB is one-way: tasks that use it only keep working while it stays on. Per zfs-send(8), “The receiving system must have the large_blocks pool feature enabled as well.”
How does encryption work with replication?
An encrypted source stays encrypted. The destination inherits the source dataset’s encryption, and per the encrypted replication docs, after replication “you must unlock the dataset to access the data.” On an offsite box that’s the property you want: the data stays locked until someone supplies the key.
The wizard’s Encryption checkbox adds encryption on the destination side, with a Hex or Passphrase key that can be stored in the sending system’s database. One documented limit: “TrueNAS does not support preserving encrypted dataset properties when trying to re-encrypt an already encrypted source dataset.” Export every key to a password manager. A backup you can’t unlock after the main NAS dies is decoration.
How do you test a restore?
Click Restore on the replication task. It creates a new task, with a name and storage location you choose, that brings the replicated data back. Point it at a new, empty dataset, never the live one, run it, open real files from the result, then delete the restored copy.
- Monthly: check the task’s last successful run and list the newest snapshot on the backup with the
zfs listcommand above. - Quarterly: restore one dataset, open a few documents and a photo, and start one app against the restored config.
Apps on Host Path storage keep data in ordinary datasets that replicate like anything else. ixVolume storage lives in the hidden .ix-apps dataset that came with the k3s to Docker apps migration, so confirm your recursive source actually covers it. And never roll the replicated source back to an older snapshot as a test: TrueNAS documents rollback as breaking configured replication tasks, as the snapshot schedule guide explains. Clone the snapshot or copy files out instead.
Why does a TrueNAS replication task fail?
Usually one of four things: the two sides share no common snapshot, sudo is missing or Use Sudo for ZFS Commands is off, the SSH service or tailnet path is down, or the task’s naming schema and recursion don’t match the periodic snapshot task. The replication schedule is rarely the problem; the plumbing around it is.
A task that succeeds but sends nothing usually points to a naming schema that doesn’t match what the snapshot task creates.
Resist deleting destination snapshots to tidy up. TrueNAS “always preserves the latest snapshot so replication can resume later”; remove it by hand and the next run has nothing to build on. Then route alerts somewhere you actually read, because a FAILED status nobody sees is the same as no backup.
FAQ
Does TrueNAS replication need SSH?
Only for remote replication. A task between two pools on the same TrueNAS uses the LOCAL transport, which “efficiently replicates snapshots to another dataset on the same system without using the network,” so no SSH connection or admin sudo setup is needed. Replicating to another machine requires an SSH connection from Credentials > Backup Credentials.
How long does the first TrueNAS replication take?
The first run sends every block the source snapshot references, so its length depends on your data size, network and the destination’s disks. Later runs send only changes since the last common snapshot. Seed the first copy over the LAN with Run Now, then move the backup box offsite and let incrementals cross the tailnet.
Can I replicate TrueNAS to a Synology?
Not with a replication task. Replication sends ZFS snapshots, so the destination has to run ZFS: another TrueNAS, or a Linux server with OpenZFS reached through a Manual SSH connection. For a Synology or any other non-ZFS target, use a TrueNAS rsync or cloud sync task, and accept that ZFS snapshot history won’t travel with it.
Does TrueNAS replication delete snapshots on the destination?
Yes, if the retention setting tells it to. Same as Source deletes destination snapshots on the source task’s lifetime, Custom applies your own lifetime, and Never Delete keeps everything until you prune by hand. Replication from Scratch is the exception to watch: when the two sides share no snapshot, it destroys the destination’s snapshots and starts a full copy.
Related across the network
- TrueNAS Snapshot and Replication Strategy — truenasguide.com
- How to Set Up an iSCSI Target on TrueNAS: Zvol to Login — iscsihub.com
