Best alternative to replication of ZFS pools to ZFS Send/Recv?

I am currently using Sanoid/Syncoid to control snapshotting and replication between to pools.

As part of the 3-2-1 Backup strategy, best practice is to use a secondary replication/back method to one of the targets. So I am researching the best option for this.

My setup is not a grand one. Around 10 TB raidz2 pool that eventually will move to a 12 TB mirror, with the former being the 1st backup target. Most of this is media files (5+ TB), Documents (2+ TB) and then about 2 TB of VM disks. A lot of the VM disks is actually in Snapshots and a more trimmed vm dataset currently has closer to 0.5 TB, but that is partly also due to me having closed down containers and VMs. This is more than likely to rise back up.

I guess that rsync will be brilliant for the media and document files as they are less likely to change much and those that do will be limited in size. Additions of files is most likely with a similar sync profile to zfs send/recv although traversing file trees will be slower - I expect bandwidth to be of a bigger issue.

But what about the vm/container disks? They are files on a dataset, not VDEVs but small changes, like log entries would trigger a full re-transfer with rsync. Is there a better option for this? I could split the backup solution between the two different data types.

Thanks in advance.

Not if you use the --inplace argument. You’ll still have to read in the entire file on both sides locally, but you’ll only transfer and write the delta. For an example of the difference that makes, see the replication section of the ZFS 101 piece I wrote during my stint at Ars Technica:

Thank You for the enlightenment! I will incorporate this.

Is it still a good idea to split the two areas as to minimise the read load to the Virtual Disk area(s), or does it make less of a difference?