4 ms·

"Would I be better off using ZFS native encryption and replicating the encrypted stream without giving a key to the rsync.net side?" I think you mean you are u

by rsync 4y ago

"Would I be better off using ZFS native encryption and replicating the encrypted stream without giving a key to the rsync.net side?" I think you mean you are using borgs "repo key" method where the key to the repo is stored, remotely, inside the repo, correct ? Just to clarify for others: That repo-stored key has a passphrase so this method still keeps all of your files encrypted in a way that nobody at rsync.net can access. FWIW, I use this method personally - I like the idea of storing the key with the repo and unlocking it with a passphrase.

gorgoiler 4y ago
Thanks for responding and for providing such a great service. I meant dropping borg altogether and using zfs send/receive to sync my data to rsync.net. As I understood it, if my dataset is encrypted then rsync.net only sees the name of the snapshot and the encrypted data. I’m not sure this would be a great solution for my most common restore use case though: fetching a single file back with borg while I’m at a third location that is remote to both rsync.net and my ZFS host. The fact that I can do that with just Borg and rsync.net is incredibly useful (yes, I travel with my keys!)
- rsync 4y ago
  "As I understood it, if my (zfs) dataset is encrypted then rsync.net only sees the name of the snapshot and the encrypted data." Prior to encrypted datasets in ZFS we did, in fact, have a stopgap measure where we would create your zpool on top of GELI devices such that it was, in fact, encrypted - but we held the keys. This was for HIPAA compliance and such things. Currently, we run the latest stable/release ZoL codebase which includes bona fide encrypted ZFS datasets where you hold the key and we see nothing. That being said, we do have a 4TB minimum[1] for these zfs-send enabled accounts where you get your own zpool ... so a smaller account with the (excellent) borg utility is a better bet for most individual users. [1] https://www.rsync.net/signup/order.html?code=4e9783 https://www.rsync.net/signup/order.html?code=4e9783

by rsync 4y ago

gorgoiler 4y ago

Thanks for responding and for providing such a great service. I meant dropping borg altogether and using zfs send/receive to sync my data to rsync.net. As I understood it, if my dataset is encrypted then rsync.net only sees the name of the snapshot and the encrypted data. I’m not sure this would be a great solution for my most common restore use case though: fetching a single file back with borg while I’m at a third location that is remote to both rsync.net and my ZFS host. The fact that I can do that with just Borg and rsync.net is incredibly useful (yes, I travel with my keys!)

rsync 4y ago
"As I understood it, if my (zfs) dataset is encrypted then rsync.net only sees the name of the snapshot and the encrypted data." Prior to encrypted datasets in ZFS we did, in fact, have a stopgap measure where we would create your zpool on top of GELI devices such that it was, in fact, encrypted - but we held the keys. This was for HIPAA compliance and such things. Currently, we run the latest stable/release ZoL codebase which includes bona fide encrypted ZFS datasets where you hold the key and we see nothing. That being said, we do have a 4TB minimum[1] for these zfs-send enabled accounts where you get your own zpool ... so a smaller account with the (excellent) borg utility is a better bet for most individual users. [1] https://www.rsync.net/signup/order.html?code=4e9783 https://www.rsync.net/signup/order.html?code=4e9783