How to Use This Kit

---

Overview

Recovery and backup-it's an interesting twist on a common term we have heard for years, backup and recovery. When was the last time you heard someone lead with recovery? So much emphasis is placed on backup-high speed, highly compressed data, and backing up very large amounts of data. Backup is important; however, restorability defines our success. We want very fast backups of very large amounts of data with a minimum impact on our networks-at least that's what our management team has been telling us (and they want it done by 4:00 P.M. Friday afternoon). Unless we have done our due diligence, we will be poorly prepared to rebut their expectations. Simple responses such as 'that's just not possible' without the facts to back it up will fall on deaf ears.

Well, now that you are here, hopefully this appendix will help you better prepare your answers to management when certain expectations are placed on you for backup and recovery-or recovery and backup. Often, when we plan, we should consider starting with the end result and work backward. Just like the mazes that we used to do as children, it always seems to be easier when we start from the end and work our way back. Why? Well, we don't know of any specific scientific proof, but it probably has to do with the change in our perspective. Our perspective changes when we start to plan our data management policies backward: disaster recovery, recovery, and backup. When we plan backward, we can define our goals more clearly, identify management expectations, and present a concise message of the financial impact the expectations have on our overall plan.

BACKUP IS IMPORTANT; HOWEVER, RESTORABILITY DEFINES OUR SUCCESS

Before we discuss the disaster recovery plan, let's talk about recovery plans in general. A recovery plan can be divided up into four parts. The first part of the document contains every step system administrators, database administrators, or applications developers take for granted when, during the normal course of the day, they are called upon to 'fix' or maintain the server or application for which they are responsible. The second part contains the information documented as though these administrator and developers are not readily available. This is much more detailed and written to the level of the personnel most likely to be executing the plan. This means if the likelihood of a junior system administrator executing the plan is high, the person should be able to read and understand the recovery steps without question. The third part now includes a call tree to be used in the event any of the critical components (administrators) need to be contacted in their absence. Finally, the fourth part contains information as it pertains to differing levels of interruptions. These can range from severe weather to complete facility access having been cut off.

What rounds out the recovery plan and makes it a disaster recovery plan are the business impact analyses that tell you how much money it will cost the company if a particular application or server is unavailable for a period of time. A very strong element of your disaster recovery plan is the business impact analyses and assessments. These are prerequisites to beginning your DR plan. So if you haven't already done so, please begin with the business impact analysis planning kit that we prepared for this appendix or one that your organization has standardized on before you launch out into creating your DR plan. Without the valuable information that will be generated from these reports, your DR plan will be very weak.

---