AND CHANGE THE OIL EVERY . . .

By Andrew M. Munro

Are you comfortable with the idea of purchasing a new car, and never changing the oil or washing the exterior? Amazingly, this is precisely the attitude taken by management in many companies who have formulated Disaster Recovery Plans.
The maintenance of Disaster Recovery plans is becoming a very key issue in the realm of Contingency Planning. It is increasingly common for corporations to take a reactive posture in Disaster Recovery. The design of plans is treated as a high priority project, but once complete they are inadequately maintained. With the rate of change present in most automated operations today, it is imperative for completed recovery plans to be kept up to date.

DESIGN OF THE PLAN

One common reason for a lack of maintenance is that the plan itself may not be easily maintainable. There are numerous schools of thought on how plans should be configured, and no general agreement in the industry. As a result, many well intentioned planning efforts generate plans which are not organized in a maintainable way.
In order to maximize maintainability, it is important to construct your plans in a modular fashion. The construction of an indexed “Recovery Plan Data Base” which contains only reference information is a good start. If a high enough level of detail is included in this documentation, then the actual Recovery Plan, the steps to be followed for recovery, can be documented quite simply. Your Recovery Plan document should include references to appropriate portions of your plan’s “Data Base.” By using this method you not only aid maintenance, you can also eliminate redundancy of documentation as well.

THE MAINTENANCE SYSTEM

Assuming that your plan is constructed in a maintainable fashion, how to proceed? It
is a very common error to simply schedule maintenance on the entire plan at some interval. Usually, the entire plan is reviewed on a quarterly or annual basis, and updated. Then it sits unattended until the next maintenance cycle comes around.
Some planners take a different approach and agree that it is wasteful to spend any effort on maintenance unless change is taking place. Planners with this outlook usually key their maintenance efforts off of a change control process.
Both of these approaches have merit, but using either one alone is almost sure to lead to an improperly maintained plan. Any change control based maintenance scheme will inevitably miss certain changes. Furthermore certain types of changes, for example updates to critical files, may occur at such a rapid rate that the change control process is almost guaranteed to become unwieldy. Other elements in the plan may change infrequently, and/or in a predictable manner. These portions of the plan may be perfect candidates for a change control based scheme.
In order to adequately maintain a complicated and detailed plan, both methods of maintenance should be used in concert. It is certainly important to key major elements of the plan to a change control process. This ensures “as needed update” in most cases, and should help prevent “windows of obsolescence” between scheduled maintenance cycles.
In addition however, all elements of the plan should be scheduled for periodic review. This is especially critical for elements of your plan that will not receive consistent levels of attention during normal operations. If special procedures are used for IPL’ing your operating system during a recovery, will these procedures receive attention as environmental change takes place? In most organizations they will not unless such attention is scheduled.
Maintenance scheduling can be done using methods parallel to those used to schedule production of applications processing. In fact, certain production control software products allow for the scheduling of manual events. The following chart details one possible manual calendar system for maintaining scheduling.

DEFINING THE STEPS

Individual instructions outlining all detailed steps to be taken for maintenance of each part of the plan should also be constructed. This is especially important in situations where maintenance is a group responsibility, or personnel turnover may be high. In addition, a log of all updates to the plan should be maintained for reference purposes.
At the beginning of each maintenance procedure, note the procedure description and indexing information. This will enable easy cross reference to other sections of the Maintenance Calendar and to the Recovery Plan Data Base, or the Plan itself. Footnotes should appear on all procedures to indicate the date the procedure should be coordinated jointly through the Disaster Recovery Coordinator and the operational area(s) concerned with that part of the plan. An example of such maintenance procedures follows.

MAINTENANCE OF PHONE LIST: REFERENCE 1

1) Review is to be monthly. (see maintenance calendar)

2) Review section 1 of Recovery Plan Data Base in its present form.

3) The Information System’s Administrative Staff is responsible for continuous updating of both the external contact list (includes vendors and users) and the I/S Personnel List.

4) DR Coordinator is responsible for inclusion of these current listings in the monthly updates of this Phone List.

5) Review all updates with the Administrative unit’s supervisor to verify accuracy and completeness.

6) Record any updates in the UPDATE LOG section of the Maintenance Calendar Manual.

PUTTING IT ALL TOGETHER

It is quite possible to manage the seemingly overwhelming process of plan maintenance. By using a modular documentation method for your plan, and designing a maintenance system that is based on both scheduling and change control, you can simplify the upkeep of your plan enormously. Unless a functional maintenance method is used, and appropriate resources for maintenance are available, your elaborate planning efforts will all be for nought in the long run.

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

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.