Why
rsync and not
zfs send/receive between two pools?
In the past it was a flexibility I wanted to have between ZFS and other filesystems - today - just continuing to use what works - I have my own 'parallel' scripts for backups - need to create an article about it some time.
As for the
ZFS send/recv ... its really good - especially with incremental ones - but managing these snapshots - creating them - cleaning after them when the network connection is broken - resuming them - I believe I would need some *external* ZFS snapshot/sync manager instead resolving this by my own ... of course I can - but do I want to/need to? Probably not.
Its also a 'problem' of
rsync(1) that its just good enough and also works well with ZFS (or anything else).
My backups are usually throughput limited - so does not matter if I would use latest ZFS incremental snapshots or
rsync(1) - they would still take similar time.
Its also another thing - and I am not a big fan of it - so called cloud backups - for these I use
rclone(1) instead - so even if I would 'migrate' to
ZFS send/recv for everything - I would still need
rclone(1) for the cloud - so again - lack of motivation here ...
Also the structure of devices below the data makes ZFS usage harder - if it would be sync between one redundant ZFS pool to another - then
ZFS send/recv is simple - but in my case I prefer to have multiple sets/copies, a local online copy, local offline copy, and also a remote offsite copy - each of these places have different disks below, some are 2TB + 5TB, some are 2TB + 4TB - so with
rsync(1) its a lot easier to sync dirs in the
/data dir then making all the exceptions with ZFS.