ServePath Blog

When we last left our hero (me) he was telling us how to avoid cardiovascular illness. Really. Heart disease is the number one effect of data loss in IT. Or it feels like it, anyway. Probably the number one effect of data loss is simply failure. If you’re a small business, and you lose all your data, there’s a 70% chance that, this time next year, you won’t be a small business anymore.

Of the four points we’ve listed below, we’ve covered the what and the where; we still need to examine when and how to back up.

How to back up?

As I said below, ideally everything that needs to be backed up is in one spot. Ideally this spot is the backup media, which is in a government-controlled facility at the bottom of a mine under a mountain with four or five OC-768s. The real world is never ideal, unfortunately, so some of this just isn’t possible. However, you can get closer or further from ideal depending on how you set things up.

Try to keep whatever needs to be backed up on a separate partition; on a separate drive if you can manage it. This allows you to use tools such as dump (nww), which is pretty much the best tool for the job (on FreeBSD anyway). You can even keep configuration files in this space. The fewer places you have to hunt for files, the better.

If you use backups as a kind of undelete function (say, if you are backing up personal files and sometimes need to restore a file you’ve deleted), then you should keep incremental backups. Incremental backups store everything that has changed since the last backup. These allow you to make frequent, short, small backups. If your work changes often (for example if you are backing up an office fileserver) you can run such backups several times during the business day. Then, when a file is needed, you can grab it from an older incremental backup.

Alternatively you can make full backups each time. This minimizes restore time, since with only one backup file you can restore all your data.

More complicated structures, such as the Tower of Hanoi differential algorithm that is suggested in dump’s manpage, are nifty but not strictly necessary. They achieve an optimum between space consumed, time to back up, and time to restore.

A further consideration needs to be given to databases. You can’t simply dump the actual database files; when you restore, you’ll find the database is corrupted. Instead, regularly dump the database (a real database can dump without locking whole tables) and then back up the dumpfiles.

When to back up?

At what time to back up isn’t really hard to determine: whenever the load is lightest.

You might want to put some thought, however, into deciding how often to back up. As I said below, not everything need be backed up at once, but only as often as it changes significantly.

If you are making incremental archives or backups, you can run the backup three or four times daily, and then push those archives offsite at night.

Further reading

(all links open in a new window–sorry)

• Backup strategies
• Backup basics

Most of this has been directed at Unix-like operating systems. Some of this applies to Windows as well, though in Windows you can’t simply back up your configuration scripts and then restore them to have your applications work just as you remembered them. If you enjoy paying for software, there are many third party backup utilities availables, such as Veritas Backup Exec. But most of these guidelines should apply.