Hacker News Reader

Comment by nicolaslem | Hacker News Reader

I would love to use this simple setup as well. It's too bad ZFS snapshots cannot be sent and stored encrypted. I would love to use rsync.net but the idea to have my data sitting in someone else's computer in plain text feels wrong.

So instead I have to use restic, which re-implements many features of ZFS and this also feels wrong.

View on HN

You can 'zfs send' to a (special kind of) rsync.net account.

We support encrypted zfs[1][2][3] and raw-send, etc.

The pricing is the same but there is a 1TB minimum because we need to give you your own VM (bhyve) and we have to burn an ipv4 address for you, etc.

[1] https://www.rsync.net/products/zfs.html

[2] https://arstechnica.com/information-technology/2015/12/rsync...

[3] https://www.servethehome.com/automating-proxmox-ve-zfs-offsi...

could you allocate the VM on demand? xinetd style

(you could route the ssh traffic similarly based on login)

Is this VM like a DigitalOcean or Linode VM with storage attached and the customer is fully responsible for it or is this VM managed by rsync.net like the normal storage accounts?

No. Yes.

> The snapshots are immutable (read-only) and cannot be altered in any way. In this way, your rsync.net account protects you from ransomware or malicious parties.

Is this still true for these special ZFS enabled accounts?

Not /u/rsync, but I have one of these accounts. The snapshots are immutable (as are all ZFS snapshotss) but you have the ability to run `zfs destroy` on them, so there is a risk there. (When they're doing the snapshots for you, you don't have that ability, but then you just have a filesystem, with no access to the underlying ZFS.)

My solution to the `zfs destroy` risk is to make my backups pull-based, where rsync.net connects inbound to my production server, and rsync.net specifies the necessary commands on the production box to grab the raw encrypted streams. That eliminates the ability of an attacker that is on the production server to run arbitrary commands at rsync.net.

There is still a small risk of data destruction if an attacker gets your rsync.net credentials, but those can be protected via off-line storage and secured workstations, which works pretty well.

While that sounds like a workable solution, out of curiosity does rsync.net support multiple users and OpenZFS' delegated permissions for more fine-grained control? They're pretty useful, and amongst other things can ensure any given user can create/clone/send/receive/etc, with per-file system capability, inheritance and so on.

Sounds like a good opportunity for an IPv6-only version at a discount/lower minimum. Many people (Google says 45% in the US) don't need servers to have v4 these days.

I have a local ZFS backup server which sends encrypted incremental snapshots to my rsync.net account, no problem. You can't mount the encrypted snapshots since freebsd ZFS doesn't support that yet, but I don't need that (and it would defeat the security point anyway).

This seems strange to me - any version of ZFS recent enough to support receiving encrypted snapshots should support mounting them (which, AFAIK, means "OpenZFS-running FreeBSD implementations" - I don't believe the non-OpenZFS, integrated implementation ever got encryption support of any kind).

I've seen several people report using OpenZFS encryption on FBSD on various mailing lists, so I'm 95% sure it's not secretly broken on there.

Reply on news.ycombinator.com