Hacker News Reader

Comment by robotmay | Hacker News Reader

Nice article. rsync.net is one part of my personal computing setup that I never even think twice about. It's simple and it works, and that clearly applies to the infrastructure too. I use ZFS locally and it has made managing my own data strangely pleasing, and it's nice to have the same system on my off-site storage too.

On the laptop-front, I find myself drifting towards a similar setup to John. I have a hefty workstation laptop but the battery life is dire and it weighs a ton, so I pretty much just run it as a headless machine next to my server now. I'm planning on picking up a Pinebook Pro as an "outdoors" machine to just remote in. I also find myself extremely unwilling to arse about swapping multiple machines on my monitors so being able to keep my work machine separate and secure but operate it from my desktop is a nice compromise.

View on HN

> rsync.net is one part of my personal computing setup that I never even think twice about

I've been using them in a small but important-to-me way continuously since 2008, and I have occasionally forgotten the service needed maintaining at all - at one point I forgot to pay them for an embarrassingly long time after a credit card expired, and they kept my storage going for me until I finally got myself in order. Please don't try that.

(My first contact with them was in 2007, to ask whether they supported pushing directly from git - the answer was no, though they added the feature a few years later - a bit ironically, I've never used it)

RE: git ...

We just added git-lfs / LFS support. So now, when you do things like:

  ssh user@rsync.net "git clone --mirror git://github.com/LabAdvComp/UDR.git github/udr"

... you can successfully pull over LFS assets, etc.

Oooh, nice!

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.

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