About the Author
Jan Persson has worked in the Information Technology arena since 1967. He began his formal disaster recovery involvement in 1979 following a major corporate data center incident that resulted in an immediate Hot Site recovery capability. For the next six years he served the role of disaster recovery coordinator helping seven operating companies and numerous remote locations establish their disaster recovery plans.
In 1985 Mr. Persson established his consulting practice which specializes in assisting all size companies create disaster recovery plans. He has personally developed over 200 plans, all of which included testing as a final step. The client base includes many businesses such as manufacturing, financial, distribution, food service, legal, health care, recovery services and more.
The scope of the plans that Mr. Persson has developed include mainframes, mid-range systems, client servers, business units, networks, voice systems, and most recently e-Business Web Servers.
Mr. Persson has worked both for and with the three leading Business Recovery companies (Comdisco, SunGard & IBM) and has been a speaker at the Disaster Recovery Journal annual conferences. He also conducts regularly scheduled Disaster Recovery Plan Development workshops for a major business recovery vendor.
He is certified (holds a CDP Title) by the Institute for the Certification of Computer Professionals.
He is the author of GO.RECOVER-EUC, GO.RECOVER-MID, and, GO.RECOVER-EBIZ for small and mid-range data centers and e-businesses, respectively (all published by Rothstein Associates Inc.).Jan Persson has worked in the Information Technology arena since 1967. He began his formal disaster recovery involvement in 1979 following a major corporate data center incident that resulted in an immediate Hot Site recovery capability. For the next six years he served the role of disaster recovery coordinator helping seven operating companies and numerous remote locations establish their disaster recovery plans.
In 1985 Mr. Persson established his consulting practice which specializes in assisting all size companies create disaster recovery plans. He has personally developed over 200 plans, all of which included testing as a final step. The client base includes many businesses such as manufacturing, financial, distribution, food service, legal, health care, recovery services and more.
The scope of the plans that Mr. Persson has developed include mainframes, mid-range systems, client servers, business units, networks, voice systems, and most recently e-Business Web Servers.
Mr. Persson has worked both for and with the three leading Business Recovery companies (Comdisco, SunGard & IBM) and has been a speaker at the Disaster Recovery Journal annual conferences. He also conducts regularly scheduled Disaster Recovery Plan Development workshops for a major business recovery vendor.
He is certified (holds a CDP Title) by the Institute for the Certification of Computer Professionals.
He is the author of GO.RECOVER-EUC, GO.RECOVER-MID, and, GO.RECOVER-EBIZ for small and mid-range data centers and e-businesses, respectively (all published by Rothstein Associates Inc.).
Excerpt. © Reprinted by permission. All rights reserved.
Many people faced with the task of developing a disaster recovery plan have a number of questions and frequently a number of fears about the project. "How do I know if I’m covering all the right tasks?" "Where do I begin and is there an order to the required project steps?" "Are there any analysis steps that could change the results of the recovery effort?" "This is all new to me and I really don’t know what the end product should look like".
The good news is that Disaster Recovery Planning (DRP) is a very logical, straightforward "Process". The steps, once presented, fall into a definite sequence of events, analysis points, and development tasks. This product, GO.RECOVER-Data Center,, is a step-by-step guide to developing a DRP.
In terms of an overview, which is always helpful to start with, the process can be outlined as follows:
• One of the first tasks is to simply identify the personnel that will be included in the DRP process. These are usually the people responsible for the computer Operations, Network, Applications, and a few more (Facilities, Security, and often key vendors). A number of these people form the Recovery Team.
• Once the team is identified is it always a requirement to make sure the basic precautions and emergency procedures are known and included in the DRP. This would include emergency evacuation steps, notification procedures, escalation procedures and a process to assess the damage. These constitute the next set of tasks in defining the DRP. Safety of personnel is very important and a good plan includes the necessary procedures.
• Following the personnel identification process and emergency steps documentation, the next step is to set the project scope and establish the assumptions. These are necessary to be sure the expectations about what the DRP will cover are well documented and known. This is usually a fairly quick process. Often, the initial scope is simply the computer center. Later, once this is competed, the scope can be expanded.
• No DRP can be completed without a very thorough and complete inventory of the installed computer hardware, software, and applications. This inventory step serves to make sure the complete environment if known and documented. For Insurance purposes it is mandatory in order to recoup any loss. From a recovery standpoint, it is a basis on which to determine exactly what components are required to backup the mission critical applications. It is in effect a straightforward inventory step with some degree of analysis to determine which applications are critical.
• The following next tasks move on to the somewhat more complex "Network" inventories. The network components are often viewed as complex and difficult to understand. In order to make the tasks easier; a set of specific worksheets is included. They can be discussed with the people that have the network experience (and/or with specific vendors) in order to document what components are in place. This includes the LAN (Local Area Network) and WAN (Wide Area Network) components.
• Based on the above steps, the next logical task is to identify what the "Recovery Environment" will include. This actually is a list of all components needed to support a recovery effort for the critical business applications.
• Moving along, the next task is to make sure that all of the necessary data is backed up and stored offsite (often at an Offsite Storage Vendor). It is often said that any recovery effort becomes impossible without the proper data and software to restore to. What the task involves is simply to evaluate the current backup process (daily, weekly, monthly, etc) and make sure copies (usually on tape or cartridges) are sent off for safekeeping.
• Once the recovery environment is known (defined in the DRP) the next step is to fit the proper alternate site strategy. This involves evaluating how closely the alternate site strategy can provide recovery to meet the critical business applications requirements. The traditional alternate site options include a Hot Site, Cold Site, internal location, outsourcing, and more recently a mirrored location (redundant facility and equipment, ready to process quickly). The matching process simply evaluates the required recovery time (for example, 24 hours) against the alternate site solution (Hot Site). Once that is done the costing and funding process can be started.
• After the decisions are made, the alternate site is selected the actual restoration tasks (Operations Restoration) can be developed. These are the specify tasks which each team member is expected to carry out at the time a recovery effort is required or during the testing of the DRP. These can be thought of as a checklist of tasks.
• Finally, the process of developing a DRP must include a Maintenance Process. This is absolutely required or the DRP will fall into obsolescence due to lack of updates. If the DRP becomes out of date (a year old) the possible chance that it will be effective at a recovery event is very small. The data and contents simply change too fast.
This brief DRP development description should set the stage for a smooth plan development process. In the end it is a very logical process, one containing a specific set of steps that build on each one in sequence. Once again, welcome to GO.RECOVER-Data Center.
