Can you provide any examples of disaster recoveries you have been involved in?
Some of the disasters that I have been involved in have included power outages, generator failure, hardware failure, data corruption, DBA mistakes, network changes and system overloads. Each area requires a different set of people and a different approach of how to handle the issues. The disaster recovery plan should address each of these items and the steps for a successful recovery.
What are the biggest mistakes people make when they create a disaster recovery plan?
They do not keep it current and they do not test. All things sound great in theory and look good on paper, but if you do not test your plan, how will you know if it works? Also, keeping documentation current is extremely important. Configurations constantly change and not maintaining your documentation will make your plan fail. Generally once a step in the plan does not work, people are prone to throwing aside the plan and trying to fix the problem based on their knowledge.
What are some myths about disaster recovery plans?
I think the biggest myth is that a disaster recovery plan is only needed for total site recovery. Since the odds of this are not great, most people look at putting a plan together as a futile exercise that is not going to reap any benefits. Disaster recovery should be redefined as “recovery from unplanned downtime”.
How can a DBA learn more about disaster recovery?
There are several great resources on the web that DBAs can consult. Just doing searches for keywords on search engines will reveal a lot of information specific to SQL Server as well as more general information. The areas that DBAs should continue to improve on are planning and documentation skills. These two areas are key to Disaster Recovery, but also to any other procedural process that needs to be developed for their database environment.
Besides what has already been covered, what else would you like to mention?
A disaster recovery plan is definitely a key process that all companies should invest the time in preparing and maintaining. It’s like an insurance policy, most of the time you think it’s a waste of money and you don’t need it, but that one time you really need it you’re sure glad you had a plan in place. When a plan does not exist, more time is wasted on communicating the issue and how it is going to be resolved instead of actually fixing the problem. If a plan exists, you can just tell your users and management that the details are in the plan, so let me get to resolving the problem!
]]>