I previously wrote about backing up TrueNAS SCALE to a Synology NAS using rsync. This works well when the backup target is a Synology device, but when both the source and destination are TrueNAS SCALE, there is a much better option in the form of ZFS replication.
ZFS replication is snapshot-based and operates at the block level. The first run sends a full copy of the dataset. Every subsequent run is incremental, sending only the blocks that have changed since the last snapshot. This makes it a lot faster and more resilient than file-level rsync. If a transfer is interrupted, the next run picks up from the last successful snapshot rather than re-scanning every file. A snapshot is a pointer to the state of the data at that moment in time and initially consumes almost zero space. A snapshot only grows as live data changes, because ZFS holds onto the old blocks that the snapshot still references. If 5GB of files change between two snapshots, that snapshot uses roughly 5GB.
This write-up documents how to configure ZFS replication between two TrueNAS SCALE systems on the same network, with the secondary acting as a dedicated backup server.
Secondary TrueNAS Configuration
- Create a storage pool:
- Storage > Create Pool
- Name the pool (e.g.
backup) - Assign disks and configure the VDEV layout
- Do not create any datasets manually, the replication task will create them automatically to mirror the source
Primary TrueNAS Configuration
SSH Keypair
- Generate an SSH keypair:
- Credentials > Backup Credentials > SSH Keypairs > Add
- Name:
primary-to-backup - Click Generate Keypair
- Save
SSH Connection
- Create an SSH connection to the secondary:
- Credentials > Backup Credentials > SSH Connections > Add
- Name:
backup-server - Setup Method: Semi-Automatic
- TrueNAS URL: the URL of the secondary box (e.g.
https://192.168.1.50) - Admin Username:
root(or your admin user on the secondary) - Admin Password: the password for that user on the secondary
- Private Key: select the keypair created above
- Save
The semi-automatic method pushes the public key to the secondary automatically, so no manual key copying is needed.
- Verify the connection shows as connected after saving. If it does not, confirm that the SSH service is enabled on the backup NAS and not firewalled on the secondary.
Periodic Snapshot Task
- Create a snapshot task for the dataset(s) to be replicated:
- Data Protection > Periodic Snapshot Tasks > Add
- Dataset: select the source dataset (e.g.
tank/data) - Recursive: enable if child datasets should be included
- Snapshot Lifetime: how long snapshots are retained on the primary (e.g. 2 weeks)
- Schedule: match the desired backup frequency (e.g. daily at 00:00)
- Save
- Run the task once manually so at least one snapshot exists before creating the replication task
Creating the Replication Task
- In TrueNAS, go to Data Protection > Replication Tasks > Add
- Configure the task:
- Source Location: On this System
- Source Dataset: select the dataset(s) to replicate (e.g.
tank/data) - Recursive: enable if child datasets should be included
- Destination Location: On a Different System
- SSH Connection: select
backup-server - Destination Dataset: the path on the secondary (e.g.
backup/data); this will be created automatically if it does not exist - Replication Schedule: set the cadence (e.g. daily)
- Destination Dataset Read-Only: set to Require
- Under advanced options:
- Replicate from scratch if required: enable (essential for the first run)
- Snapshot Retention Policy on Destination: Same as Source, or define a custom policy (e.g. keep last 30)
- Transport: SSH for encrypted transfers, or Netcat for faster unencrypted transfers on a trusted LAN
- Compression: lz4 is a good default with minimal overhead
- Save
Running the Initial Replication
- On the Replication Tasks list, click Run Now on the newly created task
- The first run performs a full send of all data and may take several hours depending on the dataset size and network throughput
- Monitor progress by clicking on the task to view the transfer log
- If the transfer is interrupted, simply run it again; it will resume from the last successful snapshot
Verifying the Backup
- Log into the secondary TrueNAS web UI
- Go to Storage and confirm the replicated dataset exists under the backup pool
- Browse the dataset to spot-check that files are present
- The dataset should show as read-only
Notes
Setting the destination dataset to read-only is important. It prevents accidental writes to the backup and keeps the replication chain clean.
Subsequent replication runs are incremental and only transfer changed blocks since the last snapsho, so this makes ongoing backups fast and bandwidth-efficient compared to file-level methods like rsync.
It is worth configuring alerts (System > Alert Settings) on both systems so that failed replication tasks are flagged. Email, SNMP, or webhook-based alerts all work depending on your monitoring setup.
Both TrueNAS systems should ideally run the same version of TrueNAS SCALE. Cross-version replication is possible but can occasionally cause issues with newer ZFS pool feature flags.