Preparing Disaster Recovery Documentation

Disaster recovery policies and procedures are highly recommended for an ISA environment. Every organization should go through the process of contemplating various disaster scenarios. For instance, organizations on the West Coast may be more concerned with earthquakes than those on the East Coast. Each disaster can pose a different threat. Therefore, it's important to determine every possible scenario and begin planning ways to minimize the impact of those disasters.

Equally important is analyzing how downtime resulting from a disaster may affect the company (reputation, time, productivity, expenses, loss in profit or revenue) and determine how much should be invested in remedies to avoid or minimize the effects.

A number of different components comprise disaster recovery documentation. Without this documentation, full recovery is difficult at best. The following is a table of contents for the areas to consider when documenting disaster recovery procedures:

 Executive Summary or Introduction Disaster Recovery Scenarios Disaster Recovery Best Practices         Planning and Designing for Disaster Business Continuity and Response         Business Hours Response to Emergencies         Recovery Team Members         Recovery Team Responsibilities         Damage Assessment         Off-Hours Response to an Emergency         Recovery Team Responsibilities         Recovery Strategy         Coordination of Equipment Needs Disaster Recovery Decision Tree Software Recovery Hardware Recovery Server Disaster Recovery Preparation         Documentation         Software Management         Knowledge Management Server Backup         Client Software Configuration Restoring the Server         Build the Server Hardware         Post Restore Training Personnel and Practice Disaster Recovery 

Outlining Disaster Recovery Planning

The first step of the disaster recovery process is to develop a formal disaster recovery plan. This plan, while time consuming to develop, serves as a guide for the entire organization in the event of an emergency. Disaster scenarios, such as power outages, hard drive failures, and even earthquakes, should be addressed. Although it is impossible to develop a scenario for every potential disaster, it is still helpful to develop a plan to recover for different levels of disaster. It is recommended that organizations encourage open discussions of possible scenarios and the steps required to recover from each one. Include representatives from each department, because each department will have its own priorities in the event of a disaster. The disaster recovery plan should encompass the organization as a whole and focus on determining what it will take to resume normal business function after a disaster.

Documenting for Backup and Recovery

Backup procedures encompass not just backing up data to tape or another medium, but also a variety of other tasks, including advanced system recovery, offsite storage, and retention. These tasks should be carefully documented to accurately represent what backup methodologies are implemented and how they are carried out. Step-by-step procedures, guidelines, policies, and more may be documented.

Periodically, the backup documents should be reviewed and tested, especially after any configuration changes. Otherwise, backup documents can become stale and can only add more work and more problems during recovery attempts.

Recovery documentation complements backup documentation. This documentation should include where the backup data resides and how to recover from various types of failures (such as hard drive failure, system failure, natural disaster). As with backup documentation, recovery documentation can take the form of step-by-step guides, policies, frequently asked questions (FAQs), and checklists. Moreover, recovery documents should be reviewed and revised if necessary.

ISA backup and recovery provides for unique capabilities, such as import and export to XML files, so particular attention should be placed on the individual needs of ISA in a recovery situation. For more information on ISA's backup and restore capabilities, see Chapter 18, "Backing up, Restoring, and Recovering an ISA Server 2004 Environment."

Outlining Monitoring and Performance Documentation for ISA

Monitoring is not typically considered a part of disaster recovery documentation. However, alerting mechanisms can detect and bring attention to issues that may arise. Alerting mechanisms can provide a proactive way to determine whether a disaster may strike. Documenting alerting mechanisms and the actions to take when an alert is received can reduce downtime and administration.

Documenting Change Management Procedures

Changes to the environment may occur all the time in an organization, yet often those changes are either rarely documented or no set procedures are in place for making those changes. IT personnel not responsible for the change may be oblivious to those changes, and other administration or maintenance may be adversely affected.

Documented change management seeks to bring knowledge consistency throughout IT, control when and how changes are made, and minimize disruption from incorrect or unplanned changes. As a result, documentation of change procedures should include the processes to request and approve changes, high-level testing procedures, the actual change procedures, and any rollback procedures in case problems arise.

Change control can be particularly important in an ISA Server environment, where improper configuration of an ISA server can leave a network vulnerable to attack. Implementing either a formal or information change control process is therefore highly recommended.