Replicating ZFS datasets to TrueNAS

alecz

Dabbler
Joined
Apr 2, 2021
Messages
18
Hi,

I'm new to the forum and to TrueNAS but wanted to use it for a long time. I've been mostly using Linux with ZFS because the system had to do more than just storage. Now I have a dedicated storage server and wanted to give TrueNAS a try.

After setting up the server, I wanted to send my ZFS dataset from the old system to TrueNAS. Traditionally, I've been using syncoid for this which basically does a zfs send and zfs receive over SSH:
Code:
/sbin/zfs send storage/data@syncoid_alex-desktop_2021-04-02:15:06:02 | /usr/bin/pv -s 346777203064 | /usr/bin/mbuffer  -q -s 128k -m 16M 2>/dev/null | /usr/bin/ssh     -S /tmp/syncoid-sagent-sagent@192.168.5.112-1617390355 sagent@192.168.5.112 '  /sbin/zfs receive -F data/tank/alex_data'


However, this failed because TrueNas no longer has (and won't have) /sbin/zfs (https://jira.ixsystems.com/browse/NAS-107132), so I made a symlink.

With the symlink sorted out, I get this error: cannot receive new filesystem stream: permission denied
I just can't figure out how to allow my custom synch account (sagent) to do zfs (create) operations.

After some researching, I decided to give a try to the GUI option for replication tasks in PULL mode. I managed to get the SSH authentication, but the task completes prematurely saying: No snapshots to send for replication task 'task_1' on dataset 'storage/data'

I didn't have snapshots on the source, so I created one (storage/data@1), but no change, TrueNAS replication did not pull my dataset.

So I ended up allowing root SSH connections to receive my ZFS data set, but I feel this is against the spirit of TrueNAS.

My two main questions:
  1. Is it even possible for TrueNAS to act as a destination for zfs datasets from the GUI, or only the other way around?
  2. Is is possible to give permission to a non-root user to perform zfs operations from the GUI (like using zfs allow from CLI)?
 
Joined
Oct 22, 2019
Messages
3,579
After some researching, I decided to give a try to the GUI option for replication tasks in PULL mode. I managed to get the SSH authentication, but the task completes prematurely saying: No snapshots to send for replication task 'task_1' on dataset 'storage/data'
Did you use a matching Naming Schema for your snapshot? Does it look like this:

syncoid_alex-desktop_%Y-%m-%d:%H:%M:%S
 

alecz

Dabbler
Joined
Apr 2, 2021
Messages
18
Thanks for the reply. That part of the naming schema was not very clear to me, I thought it was the naming on the destination, so I have it something that had all it asked for (%Y, %m, etc)

So I have to give it the naming schema of the snaphots to copy from source? What if I have a custom snapshot without date and time informaiton (as it seems TrueNAS requires all %Y-%m-%d:%H:%M:%S elements), or can I tell it to copy just a specific snapshot?
 
Joined
Oct 22, 2019
Messages
3,579
So I have to give it the naming schema of the snaphots to copy from source?
The GUI doesn't explain it as thouroughly as I believe it should, but to answer your question: yes.

It has to match exactly with the sequential snapshots, whether they were created automatically or manually.

I've never made snapshots "down to the second", since "down to the minute" is good enough for me.

What if I have a custom snapshot without date and time informaiton (as it seems TrueNAS requires all %Y-%m-%d:%H:%M:%S elements), or can I tell it to copy just a specific snapshot?
%S for "seconds" is not required. Mine are named only up to %M for "minutes". What is required at minimum is time-based snapshot names.

You cannot use the GUI to create a Replication Task (even one that you plan to only use once or invoke manually without a schedule) without a time-based naming schema. Before pushing or pulling, TrueNAS's Replication Task searches for the most recent snapshot (from the sending source) that exactly matches the naming schema. If none exist, it cannot continue.

The reason such names are required is to look at it from a different perspective. What if you manually created custom snapshots without time-stamps in their names? How will the Replication Task ever be able to send or receive an incremental stream?
  • You make a snapshot under the dataset storage named this-is-important
  • You send this snapshot (storage@this-is-important) to another pool
  • You later make a snapshot under the dataset storage named minor-changes-since-last-project
  • From a command prompt, you can manually write in the two snapshot names and do an incremental send. Only the changes from storage@this-is-important to storage@minor-changes-since-last-project will be sent
  • But how is a Replication Task supposed to know? There's nothing sequential nor time-based in those snapshot names to tell the Replication Task "These are the snapshots and their incremental changes to send from dataset to dataset; source to destination."
I hope that makes sense?

UPDATE: Just be aware that if you ever delete a snapshot from the source that has not yet been sent to the destination (or you delete from the SOURCE the most recent snapshot that exists on both sides), you will not be able to do incremental sends anymore until you do another full send with the latest snapshot from the source. At minimum, keep the two most recent snapshots that live on the destination pool also on your source pool, to play it safe.

Good​
SOURCE
DESTINATION
storage@backups_2021-04-06_00-00storage@backups_2021-04-06_00-00
storage@backups_2021-04-13_00-00storage@backups_2021-04-13_00-00
storage@backups_2021-04-20_00-00storage@backups_2021-04-20_00-00 <-- "You want incremental replication? I must live on SOURCE!"
storage@backups_2021-04-27_00-00
storage@backups_2021-05-04_00-00

You still have a chance to send an incremental replication from SOURCE to DESTINATION.





Bad​
SOURCE
DESTINATION
(deleted)storage@backups_2021-04-06_00-00
(deleted)storage@backups_2021-04-13_00-00
(deleted)storage@backups_2021-04-20_00-00 <-- "You want incremental replication? I must live on SOURCE!"
(deleted)
storage@backups_2021-05-04_00-00

There's no wy to send an incremental replication from SOURCE to DESTINATION anymore.
 
Last edited:

alecz

Dabbler
Joined
Apr 2, 2021
Messages
18
Thanks for the clarification. Indeed syncoid works the same way: it makes incremental snapshots which are in fact named with a time stamp. I'll give it another shot with the GUI
 
Top