ZFS "live" replicatation

(EDIT)
TL;DR:
When using syncoid and sanoid with an A->B, A->C scheme, should I manually care about syncoid snapshots on the targets, and/or on the sources, or would a proper setup (sanoid prune configuration) handle this automatically? Should I write some cleaning job or should I just configure it correctly? Or am I doing something else in a wrong way? (I see increasing number of syncoid-Snapshots).
(Edit end)


I have some ZFS datasets I like to “live” replicate to remote servers. For example I may have three Proxmox nodes and one remote backup server (smaller link, slower disks…). Also I’m using snapshots (mostly to allow to help users if they damaged their files).

Currently I’m using sanoid, because I found it easy to install and configure and pretty straigh-forward. I really rarely need recovery, but it should be possible of course. For “mistake” kind of issues hourly snapshots are great. For “hardware failure” kind of issues I would like to replicate “live”. Best I could get is currently some datasets every minute (“Minute Man datasets”). As I’m already using sanoid, I think syncoid seems suited well, but I fail to correctly set it up.

Is this correct so far, or should I better use something else?

I read a lot here and elsewhere, but I still didn’t get how to use syncoid correctly. What I think I’d need would be a tool that manages one (or a few) local snapshots for each replication destination, then zfs-send the data and snapthos and remove all but latest (or a few) old snapshots (keep only 1, or a few).

Is my understand and approach correct?
And if so, how do I set it up?

As stated, I tried synchoid. I setup a send and remote recv user and used a push approach. Now I think pull would be better (safer), isn’t it?

I used a simple shell script invoking syncoid for each “Minute-Man” dataset (with user data) and a second for each hourly one (with backup images).

This works well, except the accumulation of snaps.

Why does this happen? Shouldn’t syncoid prune old snapshots “of the same kind” (i.e. for same --identity) somehow?

By default, syncoid creates own snapshots and, as several sources say, these accumulate on the remote sites (and I think even on local site). If I understand correctly I should have prune rules for sanoid, so I did. Apparently these prune the auto snapshots, but no the syncoid snaps. Do I missunderstand or are my prune rules wrong?

I tried using bookmarks, but then of course every minute a state up to one hour old is replicated, so makes not much sense.

I think I’m setting up it wrongly, because I assume sanoid + syncoid work out of the box without extra scripting if doing it right. Or are users expected to write own snapshot prune tools like sanoid --prune?

As I think syncoid works with any snapshot, I could create snaps like “me-remotename-1”, “me-remotename-2” and “rotate” them, but apparently nobody does this, so I think it probably is not a good idea.

Thank you for reading my long text!

script lines look like:

# cron@pve2-node1: rpool-pve2-node2.sh
# push to node1 to node2
flock -n "$lockfd" || exiterr "Other instance still running ($0 gets no .$0.lck)"
/usr/sbin/syncoid --quiet --identifier=pve2-node2 \
  --no-privilege-elevation --recursive \
  --source-bwlimit=200M --target-bwlimit=200M  \
  rpool/Homes \
  syncoid-bak@pve2-node2:dpool/pve2-node1/Homes

Sanoid.conf at pve2-node2:

[dpool/pve2-node1/Homes]
  use_template = prune_daily

[template_prune_daily]
        hourly = 2
        daily = 1
        monthly = 0
        yearly = 0
        daily_hour = 01
        daily_min = 01
        autosnap = no
        autoprune = yes