©  2021  Mullins Consulting, Inc.   All Rights Reserved   Privacy Policy   Contact Us

Database Contingency Planning
Preparing for Disasters You Hope Won't Happen

by Craig S. Mullins

A disaster recovery plan is like insurance—you’re glad you have it, but you hope you never need it. With automobile insurance, you pay a regular fee so that you are covered if you have an accident. In other words, it’s an investment. A disaster recovery plan is similar in that you invest in it by designating a disaster recovery site, shipping backup copies of the data off-site, preparing recovery jobs, and practicing the recovery procedures.

THE NEED FOR PLANNING

Disaster recovery planning, also called contingency planning, is the process of preparing your organization’s assets and operations in case of a disaster. But what is a disaster? One definition of disaster is any unplanned, extended loss of critical business applications due to lack of computer processing capabilities for more than a 48-hour period. Your own definition may be more or less stringent with regard to the timeframe, but the basic definition is a sound one.

Most of us have witnessed a disaster, at least on television. Floods, earthquakes, hurricanes, and fires are some examples of natural disasters. Disasters can be man-made, such as electrical failure, bursting pipes, and war. 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 for you.

You must recognize potential disasters and understand their consequences. How these disasters might impact your business is the purpose of disaster recovery planning. Even though disasters are unpredictable and unlikely, every organization should have a comprehensive and tested plan to cope with a disaster situation. For example, consider some recent disaster such as Hurricane Sandy in 2012 that impacted the Northeastern region of the United States. Or more recently, Typhoon Haiyan, one of the strongest tropical cyclones in recorded history, which made landfall on November 2013 in central Philippines. These natural disasters damaged or destroyed many businesses and left local residents without shelter or unemployed.

Just because your organization has not yet experienced a disaster, or is not in a high-risk area, does not absolve you from the need for contingency planning. Many disasters are not location specific: sabotage, computer viruses, vandalism, air conditioning or heating failures, and health or environmental hazards can happen anywhere on the planet. In the wake of a disaster, companies with a disaster plan will be able to service their customers again much more quickly than those companies without one.

DATABASE DISASTER RECOVERY SHOULD BE PART OF AN OVERALL BUSINESS RECOVERY PLAN

Database disaster recovery must be an integral component of your overall business recovery plan. A disaster recovery plan must be global in scope. It 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. It must restore the IT infrastructure. Finally, and most important to our discussion, a component of that plan must be for the recovery of database and DBMS operations.

Before your company can ascertain the appropriate level of recoverability, you must analyze the risks and determine the objectives. The goal of a disaster recovery plan is to minimize the 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?

The DBA must perform an evaluation of each database object for disaster recovery. The emphasis in disaster recovery needs to be placed on criticality of the data to the business. With regard to data, there are three categories of risk—financial loss, business service interruption, and legal responsibilities—with varying degrees of risk within each category. The unavailability of each application has a different impact on the company’s bottom line.

As you create your database disaster recovery plan, remember that business needs must dictate your priorities, and not technical needs and issues. Consider separating your systems into critical and noncritical applications based on business needs. The task of defining criticality can become a political nightmare if it is left to each business unit. The decision to rank one system as more critical than another must be made at a high level—with the overall business in mind—and not individually by each business unit.

It is a good idea to rank your applications into the following groups to determine which applications have the biggest impact if they are not available. The criticality of an application must be based on the overall importance of the application to the organization.

5 CATEGORIES TO CONSIDER FOR DISASTER CONTINGENCY PLANNING

1. Very critical applications. first applications required at recovery site; data must be current.
2. Business-critical applications.  Secondary importance, but critical; next set of applications required.
3. Critical applications.  important, but need not be available immediately.
4. Required Applications.  not critical but must be backed up so they can be recovered at the remote site if needed.
5. Noncritical applications.  need not be supported in the event of a disaster. Very few applications fall into this category.

CREATE DISASTER RECOVERY PLANS WITH APPLICATION CRITICALITY IN MIND

As a DBA, you must create the disaster recovery plans with application criticality in mind. In this way, the most critical data can be recovered and made available immediately in the event your company experiences a disaster. Based on these application rankings, an appropriate backup strategy can be deployed for each database object supporting your database applications.

From Database Trends and Applications, March 2014.

© 2014 Craig S. Mullins,  

March 2014