Note how they run ZFS, "FreeBSD."

We tend to ignore it shipping cloud services and mobile apps and websites, and just focus on Linux based deploys. But FreeBSD is out there. It has all the amenities you'd expect from a modern Linux and more including:

1. Compatibility with nearly all Linux binaries.

2. A more robust implementation of containerization (Jails), with a matching implementation of a docker API.

3. Proven OpenZFS support.

4. A really robust framework for moving and standing up software.

5. Proven performance.

In a way, tbh, it's like one of many tech stacks we've neglected for the "mainstream" even though it has a proven track record and great features. ZFS is also in that family, as is stuff like Mono and OCaml.

One thing that FreeBSD doesn't have is a well known public face. Every software project (and company) needs one.

Linux is Torvalds. Of course there's a lot more to a distribution than the kernel, but most people don't think that far.

OpenBSD is Theo. Love him or hate him.

But FreeBSD? A while ago Jordan Hubbard came to mind. But he was never "the" guy, and he left a long time ago. I view it as being run now by a nameless, faceless cabal.

Anyway, that's just my opinion on one reason why we tend to ignore it.

A while back, my personal mail server ran on FreeBSD 9.x on bare metal. I wanted to rebuild the physical host but run everything in jails on a "clean" 10.x install instead. I created a new virtual machine on our ESXi cluster, booted it with an mfsbsd image, and prep'd the hard disks. Back on the server, I shut down all the services, took snapshots, and shipped them off to the VM using ZFS send/receive. In short order, I had P2V'd my mail server and it worked wonderfully. I left everything running in that VM for a few days while I rebuilt the physical server and got all of my jails set up and then moved it all back.

Allan Jude gave a cool talk at vBSDcon a few months ago entitled "Interesting Things You Didn't Know You Could Do With ZFS" [0]. If you've never used ZFS or you're wondering what it might have over your current filesystem of choice, you might check it out.

[0]: https://www.youtube.com/watch?v=qXOZmDoy2Co

rsync.net has always had a "HN readers discount" which is quite substantial. Just email [email protected] and ask about it.

(See http://popho.be/#gift for some more details, search unison)

[1] As in, full, native support - not just using an sshfs mount...

Edit: Never mind, I found a handy list of differences here: https://borgbackup.readthedocs.org/en/stable/#differences-be...

I guess that's a 'daemon' vs. 'executed binary on the remote side', but I think that'd be awesome.

My filesystems are pretty massive, but my internet connection is pretty crappy. I currently am running a script I hacked together which rsyncs my files up to rsync.net in (roughly) file size order - smallest first, largest last. This way, changes to huge files don't spend hours/days backing up, and preventing the backup of smaller files.

I haven't yet found a better way to do this.

http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendre...

https://www.illumos.org/issues/2605

https://github.com/zfsonlinux/zfs/issues/3896

e: Ah, they run ZFS on FreeBSD, but I don't think FBSD has it yet either...

> And I'm also unsure whether it's even possible interrupt a transfer and resume it later, if the underlying data has changed

There is no "underlying data has changed" in a snapshot, it's a revision of the filesystem. As for interrupting and resuming later, Delphix apparently has contributed a resumable zfs send/receive to OpenZFS, though I don't know if it's available in yours or rsync.net's distribution: http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendre...

As for the concerns of sending small files first, I don't think ZFS could even use that: I don't believe it's content-addressed, so if you send a set of blocks from snapshot 1, interrupt and send snapshot 2 instead the blocks common to both will still be re-sent, ZFS only knows the block commonality from snapshots and since snapshot 1 hasn't been pushed its contents can't be used for snapshot 2. Unless the resumable replication support uses content addressing but that doesn't seem to be the case.

Because then you have to start form scratch every time. The snapshots are so large that if you wanted to send a complete one, a large amount of stuff will have changed.

[1] https://en.wikipedia.org/wiki/Andrew_Tridgell

It may interest you to know that in 2006, when we were about to spin off rsync.net from JohnCompanies[1][2] we emailed all of the rsync authors and asked them if they had any objections at all to our naming the new company, and registering the domain name 'rsync.net' ... and they gave us their blessing.

As for the stock photos ... the old site had no photos at all. Baby steps ...

[1] The first VPS provider (circa 2001)

[2] Yes, really.

I tweaked them about this a few weeks ago, and got a detailed answer here on HN. But I guess they haven't gotten around to updating their site yet.

https://news.ycombinator.com/item?id=10674029

It's possible they are no longer related.

edit: I just looked at http://johncompanies.com/about.html and they do still mention rsync.net on that page.

You can install on, e.g., ext4, and then create /home as ZFS and then take advantage of all that ZFS offers (such as sending full/incremental snapshots like this article talks about). Or you could put your databases on ZFS and use snapshots to back them up, and so on.

Or you try ZOL (ZFS on Linux): good luck!

I'm not sure if it's usable now and if it will be good with 16.04.

ALL rsync.net accounts run on a ZFS infrastructure.

The 1TB+ accounts that you can send/recv to do not have snapshots enabled, since it's your zpool and you can set up whatever snapshots you want.

But, our normal accounts[1] that you cannot ZFS send/recv to do have ZFS snapshots set up that we create and maintain for you, and they are immutable[2].

So this means you can just do a plain old 1:1 rsync mirror to your rsync.net account, forget all about incrementals or versions, and we will do whatever snapshot schedule you like.[3]

So it's just like time machine, but more efficient (block level vs. hard links) and you don't have to set it up or worry about it and an attacker that gets your rsync.net credentials cannot wipe out your historical backups, since they are immutable here.

[1] As always, HN-readers discount - just email [email protected]

[2] even for our local root ...

[3] default, for free, is 7 daily, or 7 daily + 4 weekly for TB+ customers, but you can set up any schedule you want (21 days, 8 weeks, 6 months, etc.)

Is it because there isn't one filesystem per customer? Is that something that could be done, feasibly? Would be curious to hear. :)

You can do neat things like: create a base filesystem, create a snapshot of it (i.e. "freeze" the filesystem in time), send the snapshot to another system (or over the network for S3 storage, etc), continue modifying files, create another snapshot on top of your first one, now you can send/backup the new snapshot which is only a diff of the original snapshot.

Many other systems besides ZFS support snapshots/copy-on-write layers, but they are mostly hacks and your performance will drop considerably during the "snapshot existing" time. ZFS is different because the snapshot mechanism doesn't kill your performance (unlike the 18 layer Linux file system organization).

"Sending" a snapshot can either be directly over the network to another system to ingest the snapshot (enabling you to stream a new filesystem/snapshot into existence on a remote machine), or you can gzip the snapshot stream and send it off to backup storage.

You can layer your snapshot diffs as much as you like. As long as you have all the diffs back to the original file system, you can re-create any point-in-time snapshot layer from your backup archive.

Longer details with examples are all over, but a good overview point is: https://docs.oracle.com/cd/E18752_01/html/819-5461/gbchx.htm...

Also, it's basically the only sane way to run containers in production since all the copy-on-write and snapshot sending isn't an 8 layer deep hack cake. In Solaris, containers are aware of filesystems at the deepest levels and the networking is aware of containers too. All Linux-based container fads over the past 5 years still haven't caught up to Solaris+ZFS+Zones+Crossbow from 6 to 10 years ago.

All hosted e-mail lives under /var/vmail on its own ZFS dataset ("filesystem"). I snapshot this dataset (via cron) several times per hour and ship those snapshots off to another machine in a different datacenter for safekeeping. If anything tragic were to happen to the mail server itself, I've got a pristine copy of all my users' mailboxes I can turn to that will be, at most, roughly 15 minutes out of date.

With S3, I don't believe it has any ability to diff and/or store and transmit diffs - S3 is just a data store.

ZFS replication / rsync is more for the use case where you want to make sure files on multiple sides of the data transfer equation are the same, and can pass diffs back and forth between them.

Basically, if you need and only use S3 and file storage, this isn't want you want at all. The closest analogue is a binary git merge for very very very large files.

rsync is smarter it actually can compare and send parts of modified files. This article talks about new functionality which utilizes zfs snapshots. Now zfs knows better what has changed (for example whether file was renamed or moved) so it can be even faster when replicating the changes.

Since it runs over SSH (and since we deprecated webdav years ago) it is certainly encrypted over the wire.

If you would like it encrypted at rest, on our side, you should use attic or borg. borg appears to be the most popular:

http://www.stavros.io/posts/holy-grail-backups/

We just enabled our support for attic and borg and are very excited about it.

Of course, tarsnap pretty much does that all by itself and does it quite well.

Or you use a different tool like tarsnap that can be built on top of this.

With ZFS you can have about 35TG usable (ZFS filesystems degrade in speed at 80% in my experience)

My cost is $.007 USD per GB.

https://www.backblaze.com/b2/cloud-storage-pricing.html