ZFS Snapshots and TrueNAS Replication Setup (2026)

Losing data is the one disaster every TrueNAS user dreads. Whether it is a failed drive, a accidental deletion, or a ransomware attack, having a second copy of your data on another system is the single most effective safeguard you can build. ZFS snapshots and TrueNAS replication make that process remarkably straightforward once you understand the workflow.

In this guide, I will walk you through every step of setting up ZFS snapshots and automatic replication between two TrueNAS boxes. We will cover SSH connection setup, periodic snapshot task configuration, the replication task wizard, VPN security for offsite setups, and the troubleshooting steps that most guides skip. By the end, you will have a fully automated backup pipeline that runs on schedule without any manual intervention.

If you have ever tried to set up ZFS replication between two TrueNAS instances, you might be surprised by how easy the actual replication wizard is. The part that trips most people up is the SSH setup and dealing with stuck tasks. I will spend extra time on both of those areas so you do not hit the same roadblocks I did.

Prerequisites and Requirements

Before you start configuring ZFS snapshots TrueNAS replication, you need a few things in place. The setup assumes you have two separate TrueNAS systems, which I will call the source (your primary NAS) and the destination (your backup NAS).

Here is what you need on both systems:

• Two TrueNAS systems: Both can be TrueNAS SCALE or TrueNAS CORE. Mixing them works fine for replication since the underlying ZFS send and receive process is identical. The UI differs slightly between CORE and SCALE, but the concepts are the same.
• Administrative access: You need root or admin-level access on both systems to create SSH connections, manage datasets, and configure replication tasks.
• Network connectivity: The two boxes need to reach each other over TCP. For local network replication, this is straightforward. For offsite replication across the internet, you will want a VPN tunnel (covered later in this guide).
• Matching ZFS pool versions: The source pool should not be running a newer ZFS feature flag version than the destination. In practice, if both systems run similar TrueNAS versions, this is rarely an issue.
• Sufficient storage on the destination: The destination pool needs enough free space to hold replicated snapshots. ZFS replication is block-level, so the destination uses roughly the same space as the source dataset.

One more thing worth noting: encrypted datasets on the source add a layer of complexity to replication. You can replicate encrypted datasets, but you need to manage encryption keys carefully on the destination. I recommend starting with unencrypted datasets for your first replication setup, then adding encryption once you are comfortable with the workflow.

Setting Up SSH Connection Between Two TrueNAS Boxes

The SSH connection is the backbone of ZFS replication. Every replication task sends data from the source to the destination over an encrypted SSH tunnel using zfs send and zfs receive. Getting this connection right eliminates 80 percent of the problems people encounter.

The process involves creating an SSH keypair on the source system, adding the public key to the destination, and then testing that the connection works. Here is how to do it step by step.

Step 1: Generate an SSH Keypair on the Source System

On your source TrueNAS system, go to Credentials and then Backup Credentials (in some versions this is under System or the Local Account section). Look for SSH Keypairs.

Click Add to generate a new keypair. Give it a descriptive name like replication-source-key so you remember what it is for. TrueNAS generates a public key and a private key. The public key is what you will copy to the destination system.

Step 2: Add the Public Key to the Destination System

Log into your destination TrueNAS system. Go to System Settings, then Services, and make sure the SSH service is enabled and set to start automatically.

Next, navigate to Credentials and then Local Users (or the equivalent user management screen). You want to add the public key from your source system to the authorized_keys of the admin or root user on the destination. In TrueNAS, you can paste the public key into the SSH Public Key field for the user account that will receive the replication.

Most users go with the root account or the admin account for simplicity. In production environments, you might want to create a dedicated replication user, but that requires configuring sudo commands for zfs receive, which adds complexity. For a first setup, using the admin account is perfectly fine.

Step 3: Create an SSH Connection on the Source System

Back on the source TrueNAS, go to System Settings and then SSH Connections (in newer SCALE versions, this may be under Network or Credentials). Click Add to create a new connection.

Fill in the details:

• Name: Something like destination-nas-ssh
• Host or IP: The IP address or hostname of your destination TrueNAS
• Port: 22 (or your custom SSH port if you changed it)
• Username: The admin or root user on the destination
• Private Key: Select the keypair you generated in Step 1
• Remote Host Key: Leave blank for now, TrueNAS will discover it

Step 4: Test the SSH Connection

This is the step most people skip, and it causes headaches later. Before you create any replication tasks, click Discover Remote Host Key on the SSH connection you just created. TrueNAS will connect to the destination and retrieve its host key fingerprint.

Once the host key is discovered, click Save. Then use the Test Connection button (or initiate a test from a shell) to confirm that the source can authenticate to the destination without a password prompt. If you get a password prompt or a permission denied error, go back and verify that the public key was pasted correctly into the destination user’s authorized keys field.

A successful SSH test means the hardest part of ZFS replication is done. Everything from here uses the TrueNAS GUI.

Configuring Periodic Snapshot Tasks in TrueNAS

Before you can replicate data, you need snapshots to replicate. A periodic snapshot task automates the creation of ZFS snapshots on a schedule. TrueNAS handles this entirely through the GUI, so no command-line work is needed.

Creating a Periodic Snapshot Task

On your source TrueNAS, navigate to Data Protection and scroll to Periodic Snapshot Tasks. Click Add to create a new task.

Here are the settings you need to configure:

• Dataset: Select the dataset (or pool) you want to snapshot. If you want snapshots of all child datasets under a parent, toggle Recursive on.
• Snapshot Lifetime: This controls how long snapshots are kept on the source. A common starting point is 2 weeks. You can use a format like 2W for two weeks or 3D for three days.
• Naming Schema: TrueNAS auto-generates snapshot names using a template like auto-%Y-%m-%d_%H-%M. You can customize this, but the default is usually fine.
• Schedule: Choose how often snapshots are taken. Daily is a good baseline. If your data changes frequently, hourly might make sense. Keep in mind that more frequent snapshots mean more storage usage and more data transferred during replication.
• Allow Taking Empty Snapshots: Enable this if you want consistent snapshots even when nothing has changed. This helps keep replication in sync even during quiet periods.

Understanding Snapshot Retention Policies

Retention is where a lot of people get confused. The Snapshot Lifetime field on the periodic snapshot task controls retention on the source only. It does not control how long snapshots live on the destination.

For the destination, the retention is managed by the replication task itself. When you set up replication, you can choose to keep a certain number of snapshots on the destination independently of the source. This lets you have, for example, hourly snapshots on the source that last two weeks, but daily snapshots replicated to the destination that last six months.

My recommendation for a starting configuration: take daily snapshots on the source with a two-week lifetime, replicate daily to the destination, and keep destination snapshots for 90 days. You can adjust from there based on your storage capacity and recovery needs.

Verifying Snapshots Are Being Created

After creating your periodic snapshot task, do not just set it and forget it. Wait for the first scheduled run (or manually trigger it), then go to Storage and then Snapshots on the source system. You should see your snapshots appearing with the naming schema you configured.

If snapshots are not appearing, check the task log under Alerts or System Settings and then Jobs. Common issues include insufficient permissions on the dataset or a schedule conflict with a scrub task.

Setting Up ZFS Replication Between Two TrueNAS Boxes

Now we get to the core of this guide: setting up ZFS snapshots TrueNAS replication. The replication task wizard ties together everything you have built so far. It uses the SSH connection to send snapshots from the source to the destination automatically.

Creating a Replication Task

On your source TrueNAS, go to Data Protection and find Replication Tasks. Click Add to open the replication wizard.

The wizard walks you through several configuration sections:

Source Settings:

• Choose Source Type as Local System (the source is the system you are currently on).
• Select the source dataset. This should match the dataset from your periodic snapshot task.
• Enable Recursive if your snapshot task was recursive.
• Under Source Snapshots, choose With Snapshots or specify a naming schema to match your periodic snapshot naming convention.

Destination Settings:

• Choose Destination Type as Remote System.
• Select the SSH connection you created earlier.
• Specify the destination dataset path. This is where snapshots will land on the backup NAS. For example, if your source dataset is pool1/data/important, you might replicate to backuppool/replicated/important on the destination.

Replication from Scratch vs Incremental

The first time you run a replication task, TrueNAS performs a full send, also called “replication from scratch.” This copies every block in the dataset to the destination. For large datasets, this initial replication can take hours or even days depending on your network speed.

After the initial full send, every subsequent replication is incremental. Incremental replication uses zfs send -I to send only the blocks that changed since the last snapshot. This is what makes ZFS replication so efficient. A dataset that took 10 hours for the initial send might replicate its daily changes in under a minute.

Stream Compression

In the advanced options of the replication wizard, you can enable stream compression. I recommend using LZ4 compression. LZ4 is fast enough that it rarely bottlenecks the transfer, and it can significantly reduce the amount of data sent over the network, especially for datasets with compressible content like text files or databases.

You can also choose to include dataset properties in the replication stream. This sends configuration metadata (like compression settings, quotas, and ACL options) along with the data. It is generally a good idea to enable this so the destination dataset mirrors the source configuration.

Read-Only Destination Dataset

One setting that catches people off guard is the read-only policy on the destination. By default, TrueNAS sets the destination dataset to read-only when it is the target of a replication task. This is intentional and correct.

If the destination dataset is writable, any changes you make to it directly will break the replication chain. The next incremental replication will fail because the destination snapshot tree no longer matches what the source expects. Keep the destination read-only and let replication be the only thing that writes to it.

Testing with the Run Now Button

Before you rely on the automated schedule, test your replication task manually. Save the replication task, then click the Run Now button next to it in the task list.

The first run will take the longest since it is a full send. Watch the progress indicator and check the destination system after it completes. Go to Storage and then Snapshots on the destination TrueNAS and confirm that the snapshots from your source have arrived.

If the initial replication succeeds, subsequent scheduled runs should be quick and silent. You can check the task log at any time to see the last run status and duration.

Securing the Connection: VPN Setup with Tailscale and WireGuard

If your two TrueNAS boxes are on the same local network, you can skip this section. But if you are replicating to an offsite location, like a friend’s house, a colocation facility, or another building, you need a secure tunnel between them.

Sending ZFS replication traffic directly over the open internet is not a good idea. Even though SSH encrypts the data in transit, exposing your TrueNAS SSH service to the public internet makes it a target. A VPN tunnel adds a layer of network-level security and keeps your TrueNAS interfaces off the public internet entirely.

Option 1: Tailscale (Easiest Setup)

Tailscale is the simplest way to connect two TrueNAS boxes across different networks. It is a mesh VPN built on WireGuard that handles key exchange, NAT traversal, and routing automatically.

To set up Tailscale on TrueNAS SCALE:

• Go to Apps and search for the Tailscale community app, or install it from the catalog.
• Authenticate with your Tailscale account. You will get a login URL to authorize the device.
• Repeat the process on the destination TrueNAS, using the same Tailscale account.
• Both systems will receive Tailscale IP addresses (typically in the 100.x.x.x range).
• Update your SSH connection on the source to use the Tailscale IP of the destination instead of the local IP.

Once Tailscale is running, the two boxes behave as if they are on the same local network. Replication traffic flows through the encrypted WireGuard tunnel automatically. You do not need to open any ports on your router.

Option 2: WireGuard (Manual Setup)

If you prefer a self-hosted VPN without relying on a third-party service, WireGuard is the way to go. It is fast, lightweight, and well-suited for point-to-point tunnels.

WireGuard requires manual key generation and configuration on both endpoints. You need to generate private and public keys for each TrueNAS box, create configuration files, and open UDP ports on at least one end. On TrueNAS SCALE, you can run WireGuard inside a VM, a container, or use a network bridge to route traffic.

The setup is more involved than Tailscale, but it gives you full control over the tunnel with no dependency on an external coordination server. Many community members on the TrueNAS forums and the Level1Techs forum share working WireGuard configurations for TrueNAS.

Encryption Considerations for Replication

There are two levels of encryption to think about. The first is transport encryption, which SSH and your VPN handle. The second is data-at-rest encryption on the ZFS datasets themselves.

If your source datasets are encrypted with native ZFS encryption, you have two options for replication. You can replicate with the encryption key included, which means the destination dataset will also be encrypted and you need to manage the key on the destination. Or you can replicate unencrypted, which means the data is decrypted during the zfs send process and stored unencrypted on the destination.

For most home and small business users, I recommend leaving datasets unencrypted on the source and relying on transport encryption (SSH plus VPN) to protect data in transit. If you have regulatory requirements for at-rest encryption, consult the TrueNAS documentation on encrypted replication streams.

Troubleshooting Common Replication Issues

This section covers the problems that come up most often in the TrueNAS forums and Reddit. I have hit most of these myself, and the fixes are usually straightforward once you know what to look for.

Replication Task Is Stuck

A replication task that shows as running but never completes is the most common complaint. The first thing to check is whether the SSH connection is actually working. A stalled SSH tunnel will make the task appear to hang indefinitely.

Go to your SSH connections and click Test Connection. If that fails, fix the SSH issue first. If the connection works, check whether the previous replication run was interrupted. An interrupted run leaves behind a partial state on the destination that needs to be cleaned up.

Clearing a Resume Token

When a replication is interrupted mid-transfer, TrueNAS saves a resume token on the destination. This token allows the next run to pick up where the previous one left off, which is useful for very large datasets. But sometimes the resume token itself becomes corrupted or points to an invalid state.

To clear a resume token, you need to access the destination system’s shell. Run the following command to find the interrupted receive:

zfs receive -V is not the direct fix, but you can list resume tokens with:

sudo zfs list -t receive

Then clear the specific token with:

sudo zfs receive -c <dataset>

Alternatively, you can delete the partially-received dataset on the destination and let the next replication task start fresh. This means a full initial send again, but it is the cleanest way to reset a broken state.

Destination Dataset Already Exists Error

If you manually created a dataset on the destination before running replication for the first time, you will get an error saying the destination dataset already exists. The replication wizard expects to create the destination dataset itself.

To fix this, either delete the manually created dataset on the destination and let replication create it, or choose the Replication from Scratch option in the task settings, which will overwrite the existing dataset.

Incremental Replication Failing

If incremental replication suddenly stops working, the most common cause is that a snapshot was deleted on the source since the last successful replication. Incremental replication relies on a continuous chain of snapshots. If a snapshot in that chain is removed, the next incremental send has no reference point.

Check the source system for any gaps in the snapshot history. If snapshots were removed (perhaps by a different retention policy or a manual cleanup), you may need to do a fresh full replication. Going forward, make sure your retention policies do not delete snapshots that have not yet been replicated.

Checking Replication Logs

For any replication issue, the task log is your best diagnostic tool. In TrueNAS SCALE, go to System Settings and then Jobs, find your replication task, and view the log output. The log will show the exact zfs send and zfs receive commands along with any error messages.

Common log errors to watch for include permission denied messages (SSH key problem), connection timeout (network or VPN issue), and dataset property mismatch (source has properties the destination cannot accept). Each error has a specific fix, and the log text usually points you in the right direction.

Frequently Asked Questions

Conclusion

Setting up ZFS snapshots TrueNAS replication between two TrueNAS boxes comes down to three main steps: establishing a working SSH connection, automating snapshots with periodic snapshot tasks, and configuring the replication task wizard. Once those pieces are in place, your data flows automatically to your backup system without any ongoing manual effort.

The best advice I can give is to test everything with the Run Now button before you trust the automated schedule. Run your first full replication, verify the snapshots arrived on the destination, and then let the schedule take over. If something breaks, the troubleshooting steps in this guide cover the most common issues you will face.

Start with a simple setup, get comfortable with the workflow, and then layer in advanced features like VPN tunnels, encryption, and custom retention policies. Your data deserves that level of protection.