Spring World 2015

Conference & Exhibit

Attend The #1 BC/DR Event!

Summer Journal

Volume 27, Issue 3

Full Contents Now Available!

October 26, 2007

Is a Relational Database Necessary?

Written by  Jeffery E. Gardiner
Rate this item
(0 votes)

If someone tells you not to develop your Disaster Recovery Plan with a relational database system, you can be sure that he hasn’t developed (or had to maintain) many Disaster Recovery Plans.

That may sound like a bold statement, but I say it with confidence. CHI/COR has helped a large number of organizations develop and maintain plans using relational databases. I would like to express my views on relational databases and why I believe they are so important to disaster recovery planning.

After becoming convinced of the value of relational databases, we developed Total Recovery Planning Systems (TRPS), which is used in the U.S. and over 30 other countries for both data center and organization-wide recovery planning. Relational database systems are needed for disaster recovery planning for the following reasons:

  • Ease of Maintenance
  • Ease of Access
  • Reporting Flexibility
  • Support During Recovery
  • Other Applications
  • Ease of Use and Installation
  • Logical Structure

Ease of Maintenance

Ease of maintenance is perhaps the most valuable characteristic of Disaster Recovery Plans developed with relational databases. Once a plan is developed, organizations are faces with the formidable and never-ending task of keeping the information in their plans current. I have seen many companies re-develop existing Disaster Recovery Plans from “scratch” every two or three years because their old, typically word-processing-based plan had grown hopelessly obsolete. An easy-to-maintain approach can prevent these costly projects.

Disaster Recovery Plans developed with relational databases are easier to maintain for two reasons. First, information items in your plan are kept in only one place in the database. If that item changes, the Plan Coordinator only needs to change the data once, and the change is automatically and instantaneously reflected throughout the database and the Disaster Recovery Plan.

As an example, Mary Smith may be a vital person to be contacted at several stages of your recovery process. You may choose to insert her phone number directly into the eighteen action plan steps that require her presence, in lieu of having to look up her number in an appendix. With a relational database approach, you only need to change her number once, and that change is reflected automatically wherever it appears in your Plan, provided that your database is properly defined.

My second reason is that recovery information already being maintained elsewhere can easily be included in your database. Through an “importing” function, you can routinely and automatically update your personal computer or word processing system plan with data that exists on your mainframe computer. Since you don’t have to key that data separately into different systems, your maintenance task is smaller and you will know that your systems are synchronized.

Ease of Access

Ease of access is important during plan development, maintenance, testing, and actual recovery. Due to the information interrelationships that characterize relational databases systems, your plan data is easily and instantaneously available online, providing your plan includes the online feature. If those database relationships have been sensibly established, you can reach important information from any terminal accessing your mainframe system, providing your system is operational.

For example, you may be looking at data pertaining to an item of equipment. You realize that you need the telephone number of your equipment vendor for that item. As you dial the number, you want to know the vendor’s account representative who deals with your company. You also may want to know the recovery team to which that person has been assigned. The database “paths” that you may want to explore can be nearly endless.

Reporting Flexibility

Reporting flexibility will allow you to produce Disaster Recovery Plans (or individual reports) for different situations, audiences, and locations.

Relational database systems permit you to easily sort and select pertinent information and include only that information relevant to your plan. With some packages, you can maintain different recovery plans with the same or different contents, and you can quickly and easily tailor the data in those plans to be relevant to the immediate circumstances. A relational database plan can also allow you to send specific information or your entire plan to other systems. You can “export” your plan to your mainframe computer system to permit broader access to it or to take advantage of high speed printing capabilities.

Support During Recovery

You can use your relational database plan to support your recovery (or testing) process. Systems that are easiest to use have a sophisticated project management system built right into the database structure. As you proceed through the recovery process, you will enter actual completion information into the database, and use the system to determine the impact of your actual performance on your recovery time.

You can use a relational database system to track both planned progress and unexpected events. A properly-designed system can provide a complete chronology of the recovery or testing exercise. And the reporting flexibility mentioned earlier provides an unlimited variety of reports to highlight desired plan enhancements, to support a “post mortem” evaluation, and to answer any questions that may be posed by auditors.

Other Applications

If your disaster recovery planning system is useful for purposes other than disaster recovery, your disaster recovery planning efforts will be easier to cost-justify. And if your system is valuable for more than just disaster recovery, maintenance of your plan is more probable.

A relational database system should be a valuable resource management tool for three reasons. First, the system provides a comprehensive database for information about your resources (equipment, communications, applications, processes, vital records, software, miscellaneous items, vendor suppliers, customer/users, staff, preprinted forms), all of which is relevant to recovery. Second, the system provides a convenient way to document procedures, with a sophisticated project manager built right in. And finally, the reporting flexibility makes it easy to generate ad hoc reports that highlight areas requiring management attention.

Ease of Use and Installation

If your disaster recovery planning system only requires database management software, it will be much easier to use and install, tending to minimize or eliminate the need for consulting assistance. When needed, consulting can be focused on the more analytical processes of business impact analyses, organizing your disaster recovery planning program, protecting your vital records, selecting an alternate site, and reviewing your completed plan.

Logical Structure

This last benefit is perhaps a bit more technical than the others. To support disaster recovery, organizations need access to information items that are naturally interrelated. For example, vital records are related to the application systems and processes that use them. Application systems are related to equipment configurations required to support them. Equipment is related to vendors. Vendors are related to vendor representatives and telephone numbers. The list of possible relationships can be quite long.

A relational database makes establishing and using those relationships easy and natural. Trying to impose that complex structure of relationships with a different approach is difficult or impossible.


Jeffery E. Gardiner is Vice President of CHI/COR Information Management, Inc.

This article adapted from Vol. 1 No. 4, p. 32.

Read 1809 times Last modified on October 11, 2012