3 ms·

I have been using ZFS and rsync for around a decade. I wrote management tools on top of it so that it is maintenance-free, integrates with Nagios, and has a we

I have been using ZFS and rsync for around a decade. I wrote management tools on top of it so that it is maintenance-free, integrates with Nagios, and has a web UI including recoveries. https://github.com/tummy-dot-com/tummy-backup https://github.com/tummy-dot-com/tummy-backup It uses ZFS to do the heavy lifting of managing deltas and deduplication and rsync to do the snapshots. Combined with backup-client (https://github.com/realgo/backup-client https://github.com/realgo/backup-client) it can run as non-privileged users and trigger database dumps or snapshots, LVM snapshots of virtual machine instances, etc... We have had it running internally on clusters of 10 backup servers, and several external backup servers over ~a decade, and it has worked very well.

drKarl 12y ago
I apreciate that you created a user in HN to comment on this thread! Thanks for your input!
- linsomniac 12y ago
  "Long time listener" and all that. Finally had something to say.
linsomniac 12y ago
As an aside, this started a decade ago as a personal backup script using rsync and hardlinks for a few personal machines. But hardlinks really start falling apart once you get a lot of machines, say more than 10, or large systems with lots of files. At one point we switched to BackupPC, but ended up switching back to this after around a year. BackupPC implemented its own rsync code, which (maybe this is fixed now) didn't support incremental file-data transfers in the rsync version 3 protocol, so large systems could take hours to build the file index and then hours to re-walk the file-system to send the data. Larger systems were taking longer than 24 hours and tons of IOPS to backup. It also wasn't very efficient, when we switched back to ZFS, we consolidated 4 Backup PC servers down to one with ZFS holding the same data. The biggest issue there was log and database files, big files that had small changes resulted in the whole file getting stored multiple times. Particularly Zope ZODB files killed us, they are append-only and we had users with 2+GB files that had small changes every day.
- linsomniac 12y ago
  Another aside, it looks like BackupPC 4, which is in alpha state, includes rsync v3 code and a new back-end format, so it probably will be much improved in all regards.

drKarl 12y ago

I apreciate that you created a user in HN to comment on this thread! Thanks for your input!

linsomniac 12y ago
"Long time listener" and all that. Finally had something to say.

linsomniac 12y ago

As an aside, this started a decade ago as a personal backup script using rsync and hardlinks for a few personal machines. But hardlinks really start falling apart once you get a lot of machines, say more than 10, or large systems with lots of files. At one point we switched to BackupPC, but ended up switching back to this after around a year. BackupPC implemented its own rsync code, which (maybe this is fixed now) didn't support incremental file-data transfers in the rsync version 3 protocol, so large systems could take hours to build the file index and then hours to re-walk the file-system to send the data. Larger systems were taking longer than 24 hours and tons of IOPS to backup. It also wasn't very efficient, when we switched back to ZFS, we consolidated 4 Backup PC servers down to one with ZFS holding the same data. The biggest issue there was log and database files, big files that had small changes resulted in the whole file getting stored multiple times. Particularly Zope ZODB files killed us, they are append-only and we had users with 2+GB files that had small changes every day.

linsomniac 12y ago
Another aside, it looks like BackupPC 4, which is in alpha state, includes rsync v3 code and a new back-end format, so it probably will be much improved in all regards.