[Discuss] rsnapshot vs. rdiff-backup

[tmetro+blu at gmail.com (Tom Metro)]

Richard Pieri wrote:
> rsnapshot is, as the name suggests, a snapshot system. It uses a
> combination of GNU cp's hard link directory replication and rsync itself
> to maintain time-based snapshots. It functions similarly to Apple's Time
> Machine...
[...]
> There are two big drawbacks to rsnapshot. The first is setup. It's
> tedious.

I've mentioned "Back In Time" before:
http://backintime.le-web.org/

It's one of several Time Machine clones, and uses rsync under the hood,
following the rsnapshot model.

Minimum required setup is largely trivial, mostly consisting of
specifying in the GUI what paths you want backed up, and where you want
them backed up to.

It's a great tool when you want to have some sort of data replication,
but only have a few minutes to set it up. It makes the process easy
enough that there is no real excuse to not use it, if you don't have
something better in place.

Not a suitable tool for managing the backups of multiple machines, but
handy as a way to keep historical versions on a local machine, so you
can trivially recover from an "oops, I shouldn't have deleted that"
situation.

It's been a while since I looked at the config settings for it, and it
looks like a bunch of new features have been added. It used to only deal
with local, and network mounted file systems, which means it didn't take
proper advantage of rsync to send backups efficiently over the network.
So it was less suitable as a real backup tool (per Rich's definition).

But I see it now has options to support backing up to remote file
systems via ssh, presumably tunneling the rsync protocol.

They've also added options for creating encrypted backup files. (I
haven't looked into what tech they are using for that.)

There are a bunch of scheduling presets (I'm using "every day"), as well
as options to customize. I see a few event triggered options too, such
as when the system boots, or when a removable drive is attached. So you
could set it up to back up to rotating portable USB drives.

Creating a Time Machine-style logarithmically history is handled by the
automatic removal settings. The default is "smart remove", which does
what you'd expect for Time Machine, but also lets you customize how many
monthly/weekly/daily snapshots to retain.

Plus, you can label significant snapshots, and they'll be retained
perpetually (if you have that option set).


> You need to match up the increments with associated cron jobs. And
> you need to make sure that the cron jobs are staggered so that they
> don't step on each other.

Back In Time sets up appropriate cron entries to make this happen.

By default it uses nice and ionice to minimize system loading. There are
also options to limit rsync bandwidth. (I presume only relevant if you
are transferring to a remote system over the network.)


> ...with one notable difference. Where Time Machine's snapshots run
> back forever until disk runs out then the oldest are pruned to make
> room, rsnapshot's snapshots are rotated at fixed points...

Back In Time appears to be closer to Time Machine. There are settings to
automatically prune old snapshots as space gets low. (You can set a
minimum space/inode percentage to leave free on the drive.)


The biggest problem I have with Back In Time is that it is too quiet. It
runs overnight, and I'll go months without interacting with it, so I
almost forget it is there. Presumably if it encountered an error it
would put up some sort of a notification, but it has been so long since
it encountered one, I don't remember what form that would take. I see
when I browse my historical backups through its GUI, it flags a couple
of backups from 2012 that had errors.

It would be nice to have an independent tool that would, on a regular
basis (say weekly), compare the source files to the latest snapshot, and
always report the percentage of differences found, even if there were no
differences, plus a few stats for sanity checking, like quantity of
files and total space used by the snapshot. Something to give you some
added reassurance that backups are still working, and that you're
actually backing up the files you thought, and not an empty mount point
or something. (I should throw together a script to do this.)


> The second is that it is terrible for things like databases that grow
> forever. Each run will copy an entire database dump or log file or
> whatever which can lead to massively inflated disk usage.

Same applies to Back In Time.


> The third...is that it only works on Unix
> file systems and their network equivalents.

Likewise, Back In Time seems to be Linux-centric. I see in the expert
options settings to preserve ACLs and another to preserve extended
attributes (xattr).

According to https://en.wikipedia.org/wiki/Xattr, NTFS will use extended
attributes to "implement Unix-like permissions." Not so clear whether
you can do the reverse, and have a SMB or NFS mounted NTFS drive that
gets its native NTFS attributes backed up by the backup tool accessing
them through an extended attributes API.

More importantly, Back In Time doesn't run on Windows, and this is
really a tool meant to run on the source system. Not something that runs
on a central server and "pulls" data from client machines. (It has no
option to use ssh for the backup source. Only the target. Sourcing from
SMB/NFS would be possible, but rather inefficient.)

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/