Did you first address this?
Why and how are you trying to replicate it back?
Replication only works in one direction. If you go in the opposite direction, then it requires destroy either the entire target (from scratch) or destroying up to the sender’s latest snapshot.
What is the configuration you use for the Replication Task to “send it back”? Is it tied to a Periodic Snapshot Task?
Here’s a screenshot of the replication task.
My goal is to get the data the same on both TrueNAS systems and then be able to send changes from the primary to the secondary on a scheduled basis. Ideally, both the primary and secondary will be encrypted. I’d like to get to the point that the primary can send a WOL packet tot eh secondary to wake it up and complete the backup/sync, however I am trying to get through one thing at a time.
I added disks to the pool on the primary, and felt it would be better to delete the pool and recreate it to get past the issue of the extended pool having less space than when created from scratch.
Now I am at the point of trying to get the data back to the primary from the secondary. Hopefully that helps to explain the situation.
Thanks
No reason to leave “Recursive” and “Full Filesystem Replication” unchecked.
You want everything and you want to invoke a raw stream.
Does SCALE (“CE”) allow you to manually type inside the text fields for the locations?
This should be your source:
GamakBaseBackup/GamakBaseBackupEnc
This should be your target:
GamakBase/Gamak_Base_Enc
The child dataset Gamak_Base_Enc should not exist on the target pool. The replication will create it for you. If it already exists (and there’s no important data on it), then delete it. It’s unclear from your screenshot if it exists or if you manually typed in the target.
You want everything, including children, from GamakBaseBackupEnc? Correct?
Gamak_Base_Enc is to be an exact replica of GamakBaseBackupEnc on the new primary pool? Including all of its children?
If this doesn’t work, then you might have to resort to the command-line for this one-time migration.
I setup a new replication task with the options you list. I am still getting the no matching snapshot message.
[2025/05/21 07:45:05] INFO [Thread-11] [zettarepl.paramiko.replication_task__task_2] Connected (version 2.0, client OpenSSH_9.2p1)
[2025/05/21 07:45:05] INFO [Thread-11] [zettarepl.paramiko.replication_task__task_2] Authentication (publickey) successful!
[2025/05/21 07:45:05] INFO [replication_task__task_2] [zettarepl.replication.pre_retention] Pre-retention destroying snapshots: []
[2025/05/21 07:45:05] INFO [replication_task__task_2] [zettarepl.replication.run] No snapshots to send for replication task 'task_2' on dataset 'GamakBaseBackup/Gamak_Base_Backup_Enc/Gamak_Backup_Enc'
[2025/05/21 07:45:05] ERROR [replication_task__task_2] [zettarepl.replication.run] For task 'task_2' non-recoverable replication error ReplicationError("Dataset 'GamakBaseBackup/Gamak_Base_Backup_Enc/Gamak_Backup_Enc' does not have any matching snapshots to replicate")
Below is a capture of the settings.
Tick “Replication from scratch”.
The same error is produced with Replication from Scratch set.
[2025/05/21 07:59:33] ERROR [replication_task__task_2] [zettarepl.replication.run] For task 'task_2' non-recoverable replication error ReplicationError("Dataset 'GamakBaseBackup/Gamak_Base_Backup_Enc' does not have any matching snapshots to replicate")
Did you do this?
Does the Replication Task match the latest snapshot that exists on the source?
This can be by name or schema.
So my snapshots started with “manual” and the replication task was looking for “auto” at the beginning of the name. I think I possibly have this part of accomplished. It appears to have created a new dataset on my primary TrueNAS, so fingers crossed I at least have this one time transfer solved.
After the replication is complete, will the newly created dataset unlock itself? I assume at that point I can download the new encryption key for that data set?
This is why.
TrueNAS does not push ZFS replications with on-demand snapshots. Other tools, such as Syncoid, can do this.
TrueNAS expects there to be a related Periodic Snapshot Task to tether the replications, or at least a naming schema that zettarepl can parse through to know what to send.
Do you mean at boot or after the replication finishes?
Since this is a raw stream, it shouldn’t be unlocked after the replication completes.
Since you’re using a key instead of a passphrase, unlocking it once will have it auto-unlocked at boot, since TrueNAS will save the key on the boot-pool.
The replication ended up being successful and I was able to unlock the new encrypted dataset.
Now that I have the data back on the Primary TrueNAS. What is the proper/recommended way to backup the changes over time to the dataset on the Primary to the secondary? Hopefully without having to do another full replication/backup.
Thanks for your help!
You have to play by TrueNAS’s rules.
It will do incremental replications as long as the latest snapshot on the Backup matches the naming schema of the periodic snapshots on the Primary.
Would the best option be than to resync from the primary to secondary to start the process? It’s not Ideal, but I have 25Gbe between the primary and secondary, so it only takes about a 10 hours or so to transfer all my data.
If you really don’t mind, but if you’re going to use the same snapshot naming schema, you should be able to just resume with incremental replications.
It’s possible to rename the one “manual” to “auto” on both ends, and zettarepl should be able to work like normal if you switch to using “auto” in the Periodic Snapshot Task.
What is the procedure to rename the snapshots? Being that use of mv caused issues before, I want to make sure I’m not causing nay extra issues.
Thanks
I would create a temporary checkpoint on both ends first.
To rename a snapshot[1]:
zfs rename tank/parent/child@manual-20250515 tank/parent/child@auto-20250515
Because zettarepl is name-based, you want to preserve the datetime at the end of the snapshot name. The only thing you’re changing is the “manual” part. This way zettarepl will treat it as part of the naming schema for the replication task.
I supposed you would have to use zfs rename on both ends, since your Periodic Snapshot Task and Replication Task are expecting “auto”, correct?
You have to remember, TrueNAS (really, zettarepl) is not a straight forwards translation of plain zfs commands. It’s doing a lot in the background that most users are unaware of.
With zfs, you don’t need to follow any naming schema or even “pass the baton” from snapshot to snapshot when you replicate from one target to another. (That’s the zettarepl method.)
That’s a whole different topic.
Do not use a “shortcut” when you use zfs rename. If you remove the first part of the dataset/snapshot location, then zfs rename will “move this dataset/snapshot elsewhere in the pool” rather than do a simple “rename in place”. Type out the full path every time, for both parts of the command. ↩︎
I have the scheduled replication now from the primary to secondary. It currently snapshots nightly and the replication runs nightly. However after adding some files yesterday on the primary and letting the tasks run overnight, I am not seeing the new files on the secondary. Am I misunderstanding replication?
