Personally, I would choose option 3.

If you control the NAS, physically, then you can reduce some complexity by having unencrypted (and easily browsable) backups there ... and save the encryption for the rsync.net side of things ...

ALSO, if the NAS side of things is unencrypted, then you can establish a nice zfs snapshot schedule on the NAS and have those quickly and easily browsable as well. If you have borg backups on the NAS then even the simplest of restores becomes a full blown "restore" operation with decryption and keys, etc.

If you have ZFS clients and server, what benefit does inserting borg provide on top of a continuous ZFS send from client -> server and server -> rsync.net? ZFS send can already do encryption, and ZFS supports compression. And snapshots automatically "dedups" files that haven't changed between snapshot points, which I'd guess saves more space than deduping literal duplicate files which are not very common ime.

I guess I just don't see what value borg provides if you're already using ZFS throughout.

I guess my concern is that I'd like the data to be encrypted at rsync.net, which means I'd need to use raw ZFS send. Would it be possible to mount/browse those raw datasets remotely to verify my backups? Or would I need to recv it all back to be able to test them?

Just wanted to point to the FAQ section inside the borg docs.

https://borgbackup.readthedocs.io/en/stable/faq.html#can-i-c...

I'd say this depend on where you want to introduce the encryption and de-duplication.

I'd lean towards 1, so each machine has a standalone encrypted backup, but 3 would provide easier access without the borg client for local backups, and better de-duplication if files are shared across machines.

I'd prefer 1, as it allows each machine to easily and quickly restore itself directly from a local backup. This way the ZFS and rsync.net backup components are only used incase of catastrophic failure.