A disaster recovery plan is your business’ insurance policy. This single document outlines the steps for recovering from each disaster scenario that may be encountered. In my environments, databases are not allowed to go offline. Therefore, any situation that results in a service disruption constitues a disaster situation. This can range from someone deleted or modified the wrong data to a nuclear bomb just wiped out the entire city where your business was located. Granted I don’t accommodate a nuclear attack in my disaster recovery plan, but it gives a very clear picture of the degrees that are contained in a disaster recovery plan.

This document will contain a complete outline of your entire environment, server names, server configurations, software installed, databases, allocations, support contacts and numbers for each piece of hardware and software, and steps required to recover. This chapter will outline what needs to be in your disaster recovery plan and will fill in quite a bit of it. This section will only present an outline to be filled in with information pertaining to your environment. The disaster recovery plans that I deliver to my clients range from 30 to hundreds of pages. Most of this is information specific to that environment. However, you can fill in the blanks in this outline to produce a disaster recovery plan specific to your environment.

Dowload a Word template for creating a disaster recovery plan for both SQL Server 6.5 and SQL Server 7.0.

Overview

Any sound disaster recovery plan needs to encompass every known situation that can result in loss of service or data. Each of these shall be addressed in this document along with specific steps for recovering from a service or data loss.

But, there are also some extremely important factors in a disaster recovery plan that very few companies address. The disaster recovery plan must be validated and tested. This is not a one time process. The testing and validation of the disaster recovery plan must occur on a regularly scheduled basis. The entire plan needs to be tested once and validated before being rolled out. After that, the DBA staff needs to test and probe at least a part of the disaster recovery plan on a weekly basis.

This process requires a test server for the DBA staff that can accommodate one of the largest production systems. Many companies look on an expenditure such as this as an unnecessary expense. It is probably one of the best investments that can ver be made in a production system as long as it is utilized properly. This server gives the DBA staff the ability to continuously probe, test, break, fix, enhance, and validate the disaster recovery plan. No plan can account for everything that can occur in a production environment. The ability to continuously test the disaster plan allows the team to close these holes before they are encountered in a production system. Additionally, this also gives the team practice and familiarity with the disaster recovery plan. This increases the response time in the event of an emergency and also eliminates any errors that can occur. Having to recover a system after having been through the procedure dozens of times is much better than having to do it the first time while the system is down. This practice reduces the response time and brings systems online in a much more efficient manner. The service level increases, because the time estimates are based on practice and experience instead of simply estimates.

Backup Overview 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32