Rule #2: Have a tested Backup and Recovery Plan

I’m sure no one out there isn’t doing a backup on their database server at some interval compatible with the nature of their data.  If you’re updating your data weekly, weekly is fine; if you’re updating every minute of every day, you need to backup more often.  The only problem with making backups is deciding how long to keep those backups before you overwrite the previous backup.

The amount of time you keep old backups will usually be determined by how much space you have to store your backups.  With drive space being so cheap, you can keep these backups for a long time indeed.  But you then have to consider the other aspects too.  How far back would you really need to go.  Most of the time this is as little as a week.  So some people will keep one weekly backup on hand and seven daily backups.  The goal is to create as little to restore at a time as possible.

That comes to the “tested” part of my rule.  Backups are good, but have you ever attempted to restore from one?  If not, then how do you know they will be there for you when you need them?  I’m not suggesting you try to restore every backup you make.  But you should make it a regular part of your maintenance plan to restore a backup, and verify it’s contents.

Most places I’ve worked would only verify right before an external audit. You may want to consider updating  your maintenance plan to check your infrastructure slightly more often than that.  But really, more than once a quarter is overkill, twice yearly would be sufficient for the environments I’ve seen.

You may question why this is rule number two and not rule number one?  Well, to be honest, most companies get this one 1/2 right, and never get rule number one right.

Have any questions or comments on the rules?  Send them in!  If you have better rules, let me know.  If you disagree with a rule, share that too.  I’m always willing to learn new things, or learn that a way I’ve been doing something has a better way!