There's something vastly superior over rsync still: "btrfs send" and "btrfs receive" (but require you to have btrfs on source and destination).

▲

greaber a day ago | parent [-]

Thanks for the suggestion! I'm not very familiar with btrfs send and btrfs receive. Browsing the documentation, it looks cool, but maybe you could say more about the specific things that make it so much better for your use case? Could any of them be incorporated into a more general tool like syq? Also, it doesn't look like btrfs send helps transfers go fast by parallelizing them or has anything like syq's remote-remote transfer feature, which made me wonder if it would actually make sense to make syq able to work as an authenticated fast transport for a stream generated by btrfs send/receive.

	▲	gcr a day ago \| parent \| next [-]
		'btrfs send' is more like diff/patch than it is like rsync. It requires both source and destination to agree about the source snapshot.
	▲	amelius a day ago \| parent \| prev [-]
		btrfs send is useful for sending incremental updates; this is used a LOT for backups; and it saves a lot of time because it does not need to traverse files/directories that were not changed You cannot do this without help from the filesystem. That's why rsync itself does not support this, and it has to be done by a specialized btrfs tool in this case.