A solid backup plan is the first thing a DBA is required to do. If a DBA does absolutely nothing else in your company, he/she has earned their money by providing a solid backup plan and protecting your data.  This article is the first in a series concerning backups and recoveries.

Nothing strikes fear into the hearts of managers, users, and administrators than a server crashing and data becoming corrupted.  A few short years ago, this would have been relatively important.  But nowadays, it is absolutely vital and is one of the most serious things that can happen to a company.  This is because just about every company in the world has turned to information to differentiate themselves from competitors.  Quite literally, the data contained in your databases respresents the competitive advantage of your company and its entire lifeblood.  Losing key data can be catastrophic to a company.

Therefore, it is absolutely imperative that you construct a solid and reliable backup strategy so that in the event of a disaster you can recover the data.

There are obviously degrees to the protection of your data and environment that has an associated cost involved.  Through this series of articles, we'll probe all of the issues surrounding backups and what to do in the event of a failure.  We'll delve into "cold" or offline backups, warm standbys, hot standbys and all of the associated tools and technologies that enable each of these.  We'll also cover several recovery scenarios and give you a blue print for each.

We'll touch on a variety of products and methods.  I encourage your feedback and also any additions and methods that you can provide.  I'll stay away from product reviews out here, but will instead just highlight products that can accomplish the topic being discussed and if there is a product review will link you to it.

The overriding theme out here will always be simplicity.  The last thing you want to have to do is wade through multiple platforms, tools, technologies, and media when you have a dead server and the CEO is looking over your shoulder.

A solid backup and recovery plan is always tied to a particular environment.   Please don't just take everything from here and blindly plug it into your environment.  You need to be able to understand what is out here, apply that to construct your own backup and recovery plan, and understand the impact each of the decisions you make will have on your environment.

You also must test and continually validate your recovery methods.  This is not something you design once and then forget about.  You should be constantly testing, breaking, fixing, and probing your backup and recovery system.  One of the best investments that can ever be made in any environment is to purchase a testing server for the DBA(s) whose sole function is to test your disaster recovery plan.  You should be constantly applying full and incremental backups to the server and validating the backups.   The first thing this tells you is if the backup is any good.  As you test your backups, you should constantly ask the question of: "If the server crashed right now, what is the potential for lost data?"  As soon as you find a gap in the backup plan, you can reevalute the entire strategy and adjust accordingly.  This is invaluable since Murphy's Law says that the gap you don't find will be the one that gets nailed the first time you have a disaster.  The other largest benefit this gains you is experience.  The ideal situation would be to become a disaster recovery expert, but never have to do a disaster recovery.  Doing a recovery is a very stressful experience.  Having been through the process numerous times brings a level of calm to the procedure and makes this run more smoothly.  I've lost count of the number of times I've had to recover a system after someone else has already failed in their attempts simply because they have never done it before.  Each recovery situation is unique in its symptoms.  Being intimately familiar with all of the recovery options makes diagnosing and applying the proper recovery method much easier.  In most environments I have been in, the DBA(s) run regular disaster drills using their testing server and then evaluate the process, outcome, and any problems encountered.  Even though I've done literally thousands of these, I still do them regularly.  The principle is very simple.  Which person would you want recovering your system when the machine has crashed, the users are lined up at your door/cubicle, and the CEO is on the phone demanding to know when the system will be back up and why it crashed in the first place: someone who is doing this for the first, second, or tenth time or someone who has done this hundreds of times?  I would prefer the latter.

Stop back often and send me your feedback.  I'm particularly interested in hearing about whether something worked or not, if you have another method, or there were any hurdles you ran into.  I'll address any of the hurdles, highlight alternative methods, and also post the feedback for techniques you have implemented or that have worked for you.