1. Define Your Key Assets & Operations
Business Continuity and Disaster Recovery (BC/DR) efforts start with identification of key assets of your infrastructure and processes that are most important to keeping your business operational. Define the financial and operational impact of the loss of each asset. Before you begin reviewing the available technologies that support disaster recovery, you need to know what you’re protecting, its value to the business, and how it should be protected.
2. Determine Downtime, Availability, & Recovery Window
Time is money. Documenting the cost of assets and not meeting availability requirements helps you determine the value of an investment used to strengthen your BC/DR Plan. This information also helps you prioritize the processes to analyze. Once you have defined your assets, you need to determine how long you can go without access to these resources.
Following any unplanned outage, how quickly must you have the organization up and running as close to normal business operations as possible? Your recovery will depend on two objectives: your recovery time and your recovery point. How much time it takes to recover data and restore applications to there fully functional state and the point at which the business absolutely cannot afford to lose data to put the applications/systems and business back in operation – is a high priority.
3. Define Recovery Solutions
Define the appropriate approach and solutions based on the defined assets and recovery window. Solutions can include recovering from tape backup, disk backup, or data replication to an offsite location with ‘hot’ failover. As a business becomes more reliant on continuous access to stored data, the more data it will store – and the more frequently it must be backed up. Costs will be identified here.
4. Draft a Plan
The BC/DR plan will be defined by the critical assets, operations identified, and how they will be protected. Key processes, communication procedures, and assigned responsibilities should also be addressed. Without a solid documented plan, data restoration can be extremely challenging and there is no guarantee that it will be successful – some files could be simply gone for good. This data may pertain to customers, transactions, and not be easily reproduced; lost data becomes lost revenue.
5. Establish a Communications Plan & Assign Roles
Establish a communication plan and assign roles and responsibilities to the key members and stakeholders of the BC/DR team. A disaster is troublesome enough – communicating with your team during the recovery process shouldn’t be.
6. Disaster Recovery Site Planning
The next step is to implement the systems or capabilities required to deliver the BC/DR plan. In most cases this will involve definition of some type of offsite disaster recovery location, storage requirements, and connectivity needed to deal with situations where the primary production data center is unavailable.
7. Accessing Data & Applications
Define the appropriate communications and security protocols for accessing your data and applications. It’s likely your apps and data will be offsite in a remote location while users may also be in disparate locations.
8. Update the BC/DR Plan, In Detail
Develop a more detailed plan for each system and determine exactly what needs to be in place to implement failover to secondary/redundant connections and offsite storage. Each component of your plan needs to be very specific and detailed – in the middle of a disaster you don’t want there to be any misinterpretation or uncertainty about the plan.
9. Test Your BC/DR Plan
Organize and execute according to each system’s plan, documenting results of each step to ensure all recovery goals are met. It is also important that your plan be kept up-to-date as systems are updated or change.
10. Refine and Re-test the BC/DR Plan
Repeat Step 9 and conduct a re-test based on revisions until all objectives and goals of the BC/DR plan are achieved. The subsequent tests should put you in a position where you are ready to execute against the plan in the case of a real disaster. Re-testing should occur annually or when major infrastructure changes are implemented.