Question re: replicating tiered snapshots to backup and space utilisation

TrueNAS General
,
1

Hi All

I’m just configuring backups for my TrueNAS Scale primary - the backup is also a TrueNAS Scale system.

I’m a little unsure about the implications of replicating 2 sets of periodic snapshots to the secondary (from a space usage perspective)…

SCENARIO

Consider the two periodic snapshot tasks on the primary:

tank/dataset1, daily, retention 4W

tank/dataset1, monthly, retention 4M

Now, if I want to have say a set of daily snapshots and a set of monthly snapshots available on the backup system - for example

tank2/replica/dataset1, daily, retention 2M

tank2 /replica/dataset1, monthly, 3Y

then I need to create two replication tasks:

one specifying tank/dataset1, daily, retention 4W, and

one specifying tank/dataset1, monthly, retention 4M

QUESTION

  1. Does this result in two full copies of tank/dataset1 on the backup system? That is
  • a copy of /tank/dataset1 from daily snapshots (and subsequent deltas)
  • a copy of /tank/dataset1 from monthly snapshots (and subsequent deltas)

Or, does a a singe dataset get created on the backup system for dataset1, with the two replications creating snapshots off this dataset?

Or something else?

My concern here is threefold:

  1. Choosing a strategy that somehow doubles the amount of space used on the backup vs the primary (ignoring retention times…)
  2. Making sure I fully understand this before I do it
  3. Using an approach that is aligned with best practice.

Can anyone help?

Note: the snapshot periodicities, names of datasets are to illustrate the point only.

Thanks

Pete

2

No. A snapshot is a property of a dataset. Each snapshot points to blocks that existed on the live filesystem at the time the snapshot was created. A single block can be referenced by multiple snapshots.

Snapshots never add space. They can hold space that would otherwise free up once the snapshot is deleted.

Here’s an analogy with a truck that has limited space for storing boxes.

You might bump into an issue because of how TrueNAS and zettarepl is designed.

There is no native ZFS feature for snapshot “expirations” and “pruning”.

When you have 2 different replication tasks for the same source and destination datasets, it will either fail or rollback the destination if the destination has newer snapshots than what the running replication task is configured to look for.

It gets more complicated when you want to change the retention on the destination side, but the source has more than one type of automatic schedule. The GUI is not designed for that. The alternative is to configure multiple tasks for the same source/destination, but then you might bump into the issues I explained.

It would be easier to set the retention policy to “Same as source”.

3

Hi

Thanks for your quick response

I follow the relationship between a snapshot and a dataset I think.

I read (where I can’t remember ) that two replication tasks are needed to replicate two sets of snapshots.

From your point, it seems that if you want to do replicate two different sets of snapshots to the target, then you would need a separate dataset on the target, one per replication task?

…which brings me back my query; wouldn’t this then use more space on the target as you have two datasets?

This all suggests to me that replicating tiered backups isn’t that feasible (is that a correct conclusion?)

It’s shame that there isn’t a pruning process on the target.

Regards

Pete

4

You can select multiple Periodic Snapshot Tasks in the drop-down for the Replication Task configuration page. It also lets you specify multiple naming schemas.

No. One dataset.

The problem is that the snapshots on a dataset must remain in sequential order of creation. You cannot change the order or create new snapshots on the destination when it is a backup target.

Let’s say you have a replication task that only sends your daily snapshots.
@auto-daily-2026-08-13 is the latest one to be sent over.

Then you have another replication task that only sends your weekly snapshots.
@auto-weekly-2026-08-07 is the latest one that exists.

In order to replicate to the destination, the destination’s dataset must be rolled back to 2026-08-07. This will destroy any daily snapshots later than 2026-08-07.

This is why you should use a single replication task that is aware of all snapshot tasks or naming schemas, so it can handle it sequentially and properly.

The problem you have is that you won’t be able to set custom expirations for the different types of snapshots (daily, weekly, monthly). That’s why there was a feature request for this.

EDIT: If it helps, think of your snapshots as having sequential numbering. Whenever a snapshot is created, it doesn’t matter what “name” you give it. Pretend in the background it has a number.

#500 is named @auto-daily-2026-08-14
#501 is named @auto-weekly-2026-08-15
#502 is named @auto-daily-2026-08-16

If one replication task sends snapshot #502, how would a different replication task send snapshot #501 if it happens to run after the other task? It would need to rollback to #501 on the target. This is inefficient.

When you combine your intended replications into a single task, TrueNAS (zettarepl) will curate a list, based on the naming schema or selected snapshot tasks, and send them in sequential order, one after the other, incrementally. You will lose out on custom retentions for each type of snapshot.

5

Thanks.

I guess for know the best thing is to pick one of the periodic snapshots (which the most appropriate frequency) and just replicate that and keep any other periodic snapshots for the dataset only on the source.

Shame the feature request didn’t go anywhere…

One odd thing:

I made an error in the naming schema. I wanted to add the TZ code (%Z), but I added (%z) which is the offset vs UTC instead.

However, when I attempted to change …-%z to …-%Z the Periodic Snapshot screen complains about a format mismatch - even if I delete ALL snapshots relating to the dataset, AND the original periodic snapshot task.

Adding %Z to the naming schema for Periodic Snapshot which doesn’t have %z appended works OK, whether there are existing snapshots or not.

The para in italic seems to be a bug - I can’t see how that can be expected behaviour.

Thanks again for your help

Rgds

Pete

6

You may want to look into sanoid (portable sanoid).

I went through this a while ago and took me several tries and testing.

Had to script and automate the pruning of old snapshots, as, even with the right naming scheme, the old snapshots were not being deleted.

I found this portable sanoid solution and have been testing it.

I’m happy with it for snapshot production so now I’m checking its counterpart for replication syncoid.

Do I care that I won’t see the possible failures in the GUI, or the email alerts sent upon failure?

No. Disappointed with the native TN alert providers, ended with my own wrapper/scripts to run jobs. It logs and sends pushover alerts so I can tailor them exactly to my liking.

I may end up with a hybrid solution:
sanoid for snapshot creation/deletion, and TN Replication, using the snapshots naming scheme (or a simple .+ regex in order to replicate all/any snapshots).

7

Interesting - thanks. I’ll take a look