My friend Andy Mallon (b/t) is hosting T-SQL Tuesday this month. In case you aren’t aware T-SQL Tuesday is a blog party started by Adam Machanic (b/t) almost 7 years ago. Each month someone selects a topic and hosts the “party”. Then whoever is interested posts a blog on that topic. It can be a great way to get a good grounding on a subject as seen by a bunch of different bloggers or start your own blog.

Regardless, Andy’s topic this month is We’re still dealing with the same problems. The idea is that we’ve been dealing with the same problems for 20 years or more. Of course this being T-SQL Tuesday he wants a database spin.

So let’s talk backups.

We take backups for multiple reasons. One of the big reasons is to help us fix day to day mistakes. A table gets dropped, rows get deleted accidentally, etc. But let’s face it, the main reason we take backups is in case of a disaster. We want to be able to recover our databases if something goes wrong. We hope there won’t be a disaster, but we still plan for them. It’s important. In fact it’s so important that it’s one of the biggest parts of our job. We spend a lot of time talking about backups, planing our backups and making sure our backups get taken correctly.

If it’s so important why do so many people assume that’s the end? So often we forget that backups as just as likely (if not more so) to fail than the database itself. If you haven’t tested your backup then how can you be sure it’s actually valid? I mean you know what would really stink? To have the server go bad and think “Oh thank goodness. I have a backup!” You get the new server up and running only to discover that your backup is corrupt and you’re going to have to go back to last weeks backup file. Assuming it’s any good of course.

And in keeping with the theme I’ll tell you a story that happened to me almost 20 years ago. Oh wait. I just did.