Selfhosted

Using plain rsync sounds sane.

Sending local ZFS snapshots to the remote ZFS might be problematic. Consider accidentally deleting important data locally and nuking all of your local snapshots, then sending that to the remote ZFS. You lost all of your snapshots and there's no way to recover the deleted data. Instead do what I do - keep the two ZFS systems separate and use a non-ZFS mechanism to transfer data - rsync, Syncthing, etc. That way even if you delete everything locally, nuke all local snapshots and send the deletions via rsync remotely, you could still recover your data by restoring the remote ZFS to a snapshot prior to the deletions. For reference I have two ZFS machines doing frequent snapshots and Syncthing replicating data between them on immediate basis.

!selfhosted, please do critique if you find some fundamental issues with this.

That is rsync.net's entire business model.

I still rclone my Borg repos there instead of relying on snapshots though.

Don't use filesystem snapshots as backup. They're a safety measure against accidental deletion or casual modifications but they're not backups.

If you want backups then use a proper, dedicated solution like Borg Backup. It connects remotely, takes care of deduplication, compression, encryption etc. and you can fully verify the backups and manage them individually.

It'd be worth checking out Borg as an alternative to rsync. Borg will handle snapshotting, and automatically de-dupe on a block-by-block basis.

I use it for all of my remote backups, and it provides a lot of quality of life stuff that rsync isn't going to handle.

Have you tried a restore? A non-differential smap snapshot should be fine, but differential snapshots would make a restore difficult to impossible.

A zfssend and zfsrestore with a differential snapshot would be more traditional. If one put mbuffer in the middle, it would even be fast.