Why do you choose not to use Btrfs' send and receive commands? They do what rsync does, a bit more efficiently, unless I am missing something.

http://marc.merlins.org/perso/btrfs/post_2014-03-22_Btrfs-Ti...

In addition to what has already been said, the last time i used btrfs in this manner the protocol had issues with some extended attributes which happened to manifest in issues on binaries which lets them gain additional capabilities[0] for example. Most notably this made iputils ping[1] utility unusable after branching of a previously made snapshot for further usage. This appears not to be a too common thing in other distributions but in arch the ping utility uses CAP_NET_RAWIO capability in order to avoid the need to use setuid which appears to be more common elsewhere. None the less i think that is something one would want to know the consequences of as i am sure there are quite a few more binaries with extended capabilities set in the extended attributes of its file or use them in another manner like security labels for SELinux. I just rechecked if this is still the case and found this patch[2] but i am not sure this has already landed.

[0] https://linux.die.net/man/7/capabilities

[1] https://linux.die.net/man/8/ping

[2] https://patchwork.kernel.org/patch/10388011/

For my usage, I have BTRFS on my backup host, but not on all (or even any) of the machines I want to back up. They're variously macOS, Windows, Linux ext4, FreeBSD, and OpenBSD.

rsync has the upside of being universal.

btrfs send will only work on btrfs filesystems, you probably also want to backup other stuff.

Go for the btrbk tool - automates snapshots, and sends / receives them incrementally via SSH to a Server, with pretty fine-grained retention settings. Awesome.