In the last week I've had this discussion a couple of times. Something the last two years of work have taught me about infrastructure is people's perception of backup is a little incorrect.

If you ask most people to think about their backup procedure, nine times out of ten they will sit down and try to figure out the size of their backup set. Occasionally, they'll think about how that backup set might grow over the next whatever period. Their decision will then be based directly around that.

I think, from my experience, the attitude you need to adopt is "How quickly do I want to be able to get back to a working state?".

This leads to two questions. 1) What do I consider a "working state"? and 2) What assets are required to get back to this state. I'll speak specifically from the point of view of a software developer, but the same principles apply to accountants, plumbers, and zoologists.

What do you consider a working state?

For me, a working state means a usable IDE, source control and some kind of database server. So I need to consider these things when deciding on my backup strategy. What do I need to backup to have a working IDE in the shortest possible time? What do I need to backup to get my source control database back? What do I need to backup to get a database server back online?

What assets are required to get back to this state?

This is more than simply data. This will encompass settings (IDE configuration files, source code configuration files, permission settings etc) as well as third party addins (UI controls, libraries, IDE extensions) and data (source code, SCC database, database files).

Growth

Once you have though about these things, then you can start to factor in growth. Growth also comes from other areas, not just database files. As you use an IDE, for example, you collect little macros and addins that help you work more efficiently. There may be log files from other sources that might not seem important at first, but over time can help you diagnose any problems you might have with various tools. These suckers can grow quicker than anything.

How quick?

Now that you've properly considered what's required to get back to a working state, you need to decide how quickly you need to get there. This is entirely self-dependant. I can't tell you how quick you need. As a developer, you might be happy to simply install the IDE from the original disks and pick up and run with the last pile of source code you can find laying about the place, redoing however many days work you've lost. This means days to get back to where you were from disaster.

On the other hand, you might have tight deadlines and lots of code changes and can't afford to wait for two or three days while you rebuild your IDE and scrounge up some old source code.

Seeing a little clearer

All of these things now give you a clearer picture about how much you need to backup. You can see from this that it's more than the sum total of the data files. This should show you that backing up is more than fitting your source code database onto a CD or DVD once a month.

It also tells you how you should backup. Your IDE doesn't change daily, so it doesn't need to be part of the daily schedule. It doesn't even have to be part of a weekly schedule in most cases. When was the last time your SCC configuration changed? These things might be better handled by imaging your workstation after a rebuild. Your tools/macros/utilities folders can probably safely be backed up once a month. It goes without saying that your souce code database should be backed up daily. (Again, I'm making the bizarre assumption that you're a developer).

It's always obvious in hindsight, but nothing beats a good backup procedure. Whenever something goes wrong, be it a virus, a hardware failure, aliens, whatever, you'll feel confident that you can easily get back to where you were.