Look at that.
root@halleck:~# tarsnap --list-archives -v | sort -k2 | head -n1
M2009-09 2009-09-01 05:24:01
Having been using the Tarsnap backup service for five years kind of deserves a blog post? Let me share a few of the reason why I keep using Tarsnap for offsite backups, and why you too might want to.
- Encryption happens locally, allowing one to worry less about the files being included.
- Data deduplication on a block level, allowing for every kept backup to be a full snapshot.
- Client uses basically the same command line option as regular tar, making Tarsnap familiar as well as scriptable.
- While not open source, the Tarsnap client source code is fully available, coupled with a serious bug bounty program.
- Server side Tarsnap uses Amazon S3 for storage, which has a proven record for durability.
- IPv6 support.
Then there are these potential issues, which may or may not be an issue for you.
- Restoring files tend to be a bit slow. That limitation can partially be worked around by restoring separate folders in parallel.
- You can only use the Tarsnap backup client together with the Tarsnap backup service. Backing up to your own infrastructure is not supported.
- Payment can only be made a head of time, and if your account runs out of money there is a relatively short window before your backups are deleted. Personally I can keep track of that, but it makes me hesitant to recommend Tarsnap in any work environment.
For more info, see the pages Tarsnap design principles and Tarsnap general usage.
In case you start using Tarsnap, then feel free to take a look at my tarsnap-helpers git repository. It contains a couple of monitoring scripts as well as some bash completions.
While I have been using Tarsnap for a while now it is first recently I have gotten around to make Nagios monitor those backups. Given that I really don’t want to give the nagios user any actual access to my backups, I instead take the approach of having my backup script create a status file containing a Unix timestamp of the most recent backup.
My check_tarsnap Nagios plugin can then use that status file to check that the most recent backup isn’t older than a specified number of hours. For my nightly backups I have the Warning threshold set to 26 hours and the Critical threshold set to 42 hours.
(See the top comment in the plugin source for an example on how to create the status file.)
I’m currently trying out the Tarsnap backup solution (beta). Since it doesn’t come with a bash-completion of its own I’ve created one myself. I really can’t stand working with –long-options without proper completion.
For now I maintain it as a “junk branch” in Launchpad.
So far there is only the initial commit, hence it is most likely far from perfect. Feel free to point our errors and suggest improvements.
(Once I’ve used Tarsnap some more, I’ll probably put my experiences into a blog post of its own.)
For my personal backups I usually prefer to use rdiff-backup.
Since current Ubuntu versions doesn’t provide any packages from the recent stable branch of rdiff-backup I nowdays like to create my own debs. Also, rdiff-backup tends to work best if you have the same version on both ends of the backup.
At first I maintained my own repository, had a whole set of different pbuilder chroots, etc. While it was a good learning experience I’m not really sure it’s worth the effort for just one package. Hence I now maintain my packages in a Launchpad PPA.
In case you’d like to use my rdiff-backup packages you are very welcome to do so. They can be found in the PPA for Andreas Olsson.
EDIT: Use PPA for rdiff-backup packages (also mine) instead.
Actually, you really shouldn’t use my PPA unless: 1) You have a somewhat good reason to trust me and/or 2) You have the means to get even with me if my packages break your system.
I use rdiff-backup for most of my private backups. It’s a great piece of software. I just wish it had its own bash-completions.
Update October 6th: Now included in Debian (sid).