tl;dr: Picking what you are going to back up helps (i) keep the backup space usage minimal (ii) helps to inform choice of backup program
Following on from picking a backup system in the backups series, now that you’ve picked a system, what exactly should you back up?
You could make the argument that really, what you’re going to back up is part of your requirements gathering. Frequently-changing data (eg documents) is different from a snapshot of a Windows installation is different from an archive of the family photos.
My my case, I want to back up my home directory, which is a mix of things:
- documents of all sorts
- code (some mine, some open source tools)
- application configuration data
- browser history etc
- miscellaneous downloads
It totals less than 20Gb, most of which is split between downloads, browser and code (around 3:1:1, according to
ncdu). Some things like documents, code and browser data will change semi-frequently and old versions are useful; others will stay relatively static and version history is not so important (like downloads).
Some downloads were for a one-off specific purpose and removed. It would be possible to pare down further by removing some downloads and some code — wine is the largest directory in
~/code/, and I don’t remember the last time I used it — but it’s not enough that I feel it’s a priority to do.
Is there anything in this set of data that doesn’t need kept? Frequently-changing-but-low-utility files like browser cache would be worth excluding as they will cause the (incremental) backups to grow in size. Incidentally, cache was the next largest item in the ratio above!
Some of the files will change relatively frequently, and I’d like to keep the history of them. I have decided that I want to keep my entire home directory, minus browser cache. This help to inform me what things I need my backup program to do, and what to do with it when I decide.
You have backups, right?
— SuperUser’s chat room motto
This started out as an intro to
bup. Somewhere along the way it underwent a philosophical metamorphosis.
I’m certainly not the first person to say that backups are like insurance. They are a bit of a hassle to figure out which one will work best, you set it up and forget about it, and hopefully you won’t need it*.
Many moons ago, I had backups taken care of by a a simple shell script. Later, this got promoted to a python script which handled hourly, daily weekly and monthly rotation; and saved space by using hard links (
cp -al ...). It even differentiated between local and remote backups. That was probably my backup zenith, at least when time and effort are factored in.
Really, the more sensible approach is rather than reinvent the wheel, use an existing tried-and-tested solution. So I moved to
rdiff-backup and it was good; being simple it meant I could set up ‘fire-and-forget’ backups via
cron. I was able to restore files from backups that I had set up and then forgotten about.
With the recent expansion of the fileserver ongoing, now’s a good time to take stock and re-evaluate options. I have created a Xen DomU dedicated to backups (called pandora, aptly) with it’s own dedicated logical volume. From here, I need to decide:
1) whether to keep going with
rdiff-backup or switch to eg
2) figure out if different machines could use different schedules or approaches (answer: probably); and if so, what those would be (answer: …)
I don’t want to spend too long on this — premature optimisation being the root of all evil — but the aim is to create a backup system which is:
: If you *do use your backups or insurance a lot, it’s probably a sign that something is going wrong somewhere