لطفا منتظر باشید ...
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.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.
