Return to Home Page

Database Disaster Planning

A disaster recovery plan is like insurance – you're glad you have it, but you hope you don't need it. With automobile insurance, you pay a regular fee so that you are covered if you have an accident. A disaster recovery plan is similar because you pay to implement your disaster recovery plan by designating a disaster recovery site, shipping backup copies of the data off-site, preparing recovery jobs, and practicing the recovery procedures.

But what is a disaster? One definition of a disaster is “any event that has a small chance of transpiring, a high level of uncertainty, and a potentially devastating outcome.” Most of us have witnessed a disaster situation, at least on television. Floods, earthquakes, hurricanes, and fires are some examples of natural disasters. Disasters can also be man-made, such as electric failure, bursting pipes, and war. The terrorist attacks of September 11, 2001 certainly qualify as disasters, especially for the former tenants of the World Trade Center towers.

Even though most of us have never personally lived through a disaster like those we see on television, many of us have had our basements flooded or been in an automobile accident. A disaster does not have to have global consequences in order for it to be a disaster to you.

Location plays a part in disaster planning (tornadoes and hurricanes near a coast, snow and ice in the north, etc.). But many types of disasters are not location-specific. Terrorism, sabotage, computer viruses, vandalism, air conditioning or heating failures, and health hazards can happen anywhere on the planet. So every company should have a comprehensive and tested disaster plan that details how to resume business operations in the event of a disaster. Companies with a disaster plan will be able to service their customers again after a disaster much quicker than those companies without a disaster plan. Indeed, a company facing a disaster without a disaster recovery plan may never resume business. So even though disasters are unpredictable and unlikely, every organization should have a plan to cope with them.

Your disaster recovery plan must handle business issues such as alternate locations for conducting business, communication methods to inform employees of new locations and procedures, and publicity measures to inform customers how to transact business with the company post-disaster. A component of that plan must be the overall plan for resuming data processing and IT operations.

A big component of the plan is the resumption of DBMS operations. It is the responsibility of the DBA to ensure that the DBMS is restartable at a remote location and that all critical databases are accounted for in the disaster recovery plan. The key for the DBA is to be able to integrate at two levels: the disaster recovery planning level and the day-to-day backup and recovery planning level. Database backups are required both on-site for regular recovery and off-site for disaster recovery. The DBA must incorporate both levels of recovery planning into the regular backup mechanisms deployed for the company’s databases.

But before your company can ascertain the appropriate level of (disaster) recoverability, you must analyze the risks and determine your objectives. One goal of disaster recovery is to minimize costs resulting from losses of, or damages to, the resources or capabilities of your IT facilities. The success of any database disaster recovery plan depends a great deal on being able to determine the risks associated with data loss. What is the impact to your business if the data is lost? It will differ for each piece and type of data.

There are three different types of business risk associated with data loss: financial loss, business service interruption, and legal responsibilities. Within each category, there are varying degrees of risk. Each application has a different impact on the company's bottom line the longer it is unavailable.

Different data and applications also will have different impacts on business service interruption and legal responsibilities. Data and application should be performed to determine the level and type of risk. The disaster recovery plan needs to factor all types of risk into the resulting plan to determine which applications and database objects are most critical.

As you create your database disaster recovery plan, remember that business needs must dictate your priorities – not technical needs and issues. It is a good idea to rank your applications into groups to determine which applications have the biggest impact if they are not available:

• Very Critical Applications. The most critical applications in your organization will require current data upon recovery. Immediate access to such applications are required in a disaster situation.

• Business Critical Applications. These applications are important to your company and should be addressed after the very critical applications. These applications frequently require current data but may not need to be available at the remote site right away.

• Critical Applications. These applications need not be available immediately or can get by with older data. But they are still important and required.

• Required Applications. These applications are not critical but must be backed up such that its data can be recovered at the remote site when needed.

• Non-critical Applications. These applications need not be supported in the event of a disaster. Very few applications fall into this category.

The criticality of an application must be determined based on the overall importance of the application to the organization. As a DBA you must create the disaster recovery plans with application criticality in mind. In this way the most important data that is absolutely necessary can be recovered and made available immediately in the event your company experiences a disaster.

NOTE: Portions of this column were adapted from Craig’s forthcoming book Database Administration: Practices and Policies, to be published by Addison Wesley early in 2002.

From Database Trends and Applications, November 2001.
 

© 2001 Craig S. Mullins,  All rights reserved.
Home.