This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it.

It might seem a little unusual to be talking about making backups in the middle of a series of articles about developing free software, but bear with me and you'll see why I'm going to spend this week's slot talking about ensuring you won't lose your data or code unexpectedly.

When we spoke about revision control a few weeks ago, I mentioned that if nothing else, putting your code into revision control and pushing it somewhere would mean that you had two copies of the code. This is, in a crude sense, a backup of sorts. Couple it with making regular commits and pushing to more than one location and you could claim it was even a good backup strategy for your source. Indeed, I believe there are people out there who truly believe that this is enough.

I believe that ensuring you don't lose your code is only one part of ensuring that your software development life won't stutter to a halt if you lose a hard drive. There are so many more things on your development system which deserve protection from disaster. For example, your dotfiles (the files which configure your development software such as .gitconfig or .bashrc) -- are they somehow less worthy of preservation than your code? Also the set of packages your have installed, or the arrangement of icons on your desktop. All these are pieces of data which you would be less efficient if you had to recreate.

Also, previously I suggested you should ensure you had pushed your work elsewhere in order to help preserve it. The server you pushed it to -- is that safe from the ravages of disk failure too? From this therefore comes the need to keep backups. Make them often, make them well, and as with my previous article, test them. If you don't know you can restore from them, then your backups are nothing more than pretty piles of otherwise worthless data.

Your homework for this week is to go and find something you don't keep regularly backed up and think "If I were to rm -rf this, right now, would I be upset?" If the answer is "no" then delete it. If the answer is "yes" then find some way to change it to a "no", perhaps by deriving, implementing and verifying a backup strategy for it.