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
.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
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.