How to tell sanoid not to take snapshot while syncoid is running?

[hth2]

I am setting up a backup server as follows:

• run syncoid to replicate desired zvols from several hosts to the backup server
• run sanoid on the backup server to implement retention

The issue I am facing is that if sanoid takes a snapshot of a zvol being received by syncoid, then that zvol is broken. What would be the recommended way to solve this? I am thinking of using the pre_snapshot_script to check and return 1 if syncoid is running.

The involved commands are like these:

# run syncoid to replicate a zvol:
syncoid --no-rollback --source-bwlimit=90m --compress=zstd-fast root@weila-pve:zpool2/vm-disk-images2/vm-1130-disk-0 zpool2/backup/sanoid/nfs2--vm-1130-disk-0
# zvol and snapshots created by the above command:
zpool2/backup/sanoid/nfs--vm-2030-disk-1
zpool2/backup/sanoid/nfs--vm-2030-disk-1@syncoid_teima-pve_2024-03-15:15:24:53

# when re-run syncoid, it seems to delete the snapshot and create a new one with a new timestamp

# create a test config for sanoid:
cat /root/test-sanoid/sanoid.conf
[zpool2/backup/sanoid]
  use_template = production
  recursive = yes
  process_children_only = yes

#############################
# templates below this line #
#############################

[template_production]
  frequently = 0
  hourly = 0
  daily = 30
  monthly = 3
  yearly = 1
  autosnap = yes
  autoprune = yes

# run sanoid manually
sanoid --configdir /root/test-sanoid --cron --verbose

# at this point the relevant zvol and its snapshots are:
zpool2/backup/sanoid/nfs--vm-2030-disk-1                                                1.73T  72.9T     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_yearly               0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_monthly              0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_daily                0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@syncoid_teima-pve_2024-03-15:15:24:53             0B      -     1.66T  -

[phreaker0]

as already said, this won't work with ZFS :-) Adding the "--no-rolback" flag to syncoid will just make syncoid abort with an error because it detected changes on the target of the replication which are not present on the source and because it's not allowed to do a rollback on the target it can't proceed with the replication.

You need to run sanoid on both the source and the target, but on the target you need to disable snapshot taking and only use the prune schedule as you like. On the source you let sanoid take the snapshots which will be replicated to the target by syncoid. You can choose a short retention of the snapshots on the source and on the target use a long retention plan.

[hth2]

thank you for your patience; I am still learning ZFS

my expectation is following:

• whenever I run syncoid it will sync zpool2/backup/sanoid/nfs--vm-2030-disk-1 with the source
• sanoid takes snapshots of zpool2/backup/sanoid/nfs--vm-2030-disk-1 and keeps them as stated in sanoid config. This should not change zpool2/backup/sanoid/nfs--vm-2030-disk-1, hence it should not break next run of syncoid

I also tested to verify:

• run syncoid => replicated zpool2/backup/sanoid/nfs--vm-2030-disk-1
• run sanoid => created snapshots zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_{yearly,monthly,daily}
• run syncoid again => updated zpool2/backup/sanoid/nfs--vm-2030-disk-1

so it seems to work for this case?

[phreaker0]

thank you for your patience; I am still learning ZFS

my expectation is following:

* whenever I  run syncoid it will sync `zpool2/backup/sanoid/nfs--vm-2030-disk-1` with the source

* sanoid takes snapshots of `zpool2/backup/sanoid/nfs--vm-2030-disk-1` and keeps them as stated in sanoid config. This should not change `zpool2/backup/sanoid/nfs--vm-2030-disk-1`, hence it should not break next run of syncoid

This expectation is wrong, taking the snapshot will change the target dataset/volume. You can easily check, take a snapshot of the target and try a syncoid run with the --no-rollback option. It should fail. If you omit the option and the replication is done, you can list all the snapshots on the target and will see that your created snapshot is gone now.

I also tested to verify:

* run syncoid  => replicated `zpool2/backup/sanoid/nfs--vm-2030-disk-1`

* run sanoid =>  created snapshots `zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_{yearly,monthly,daily}`

* run syncoid again => updated `zpool2/backup/sanoid/nfs--vm-2030-disk-1`

so it seems to work for this case?

You probably didn't check if your created snapshot is still there after the successful syncoid run :-)

[hth2]

I tried your instructions:

zfs snapshot zpool2/backup/sanoid/nfs--vm-2030-disk-1@for_testing_only

zfs list -t all |grep for_testing_only
zpool2/backup/sanoid/nfs--vm-2030-disk-1@for_testing_only                                  0B      -     1.66T  -

syncoid --no-rollback --source-bwlimit=90m --compress=zstd-fast root@weila-pve:zpool2/vm-disk-images2/vm-1130-disk-0 zpool2/backup/sanoid/nfs2--vm-1130-disk-0
Sending incremental zpool2/vm-disk-images2/vm-1130-disk-0@syncoid_teima-pve_2024-03-15:16:09:53 ... syncoid_teima-pve_2024-03-15:16:36:10 (~ 1.5 MB):
1.12MiB 0:00:00 [3.64MiB/s] [====================================================================>                       ] 75%

zfs list -t all | grep nfs--vm-2030-disk-1
zpool2/backup/sanoid/nfs--vm-2030-disk-1                                                1.73T  73.9T     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_yearly               0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_monthly              0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@autosnap_2024-03-15_15:23:08_daily                0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@syncoid_teima-pve_2024-03-15:15:24:53             0B      -     1.66T  -
zpool2/backup/sanoid/nfs--vm-2030-disk-1@for_testing_only                                  0B      -     1.66T  -

I didn't see any error though. What am I missing?