Expecting the transition to cloud to do away with the need for a disaster recovery plan is wishful thinking. Consider some common causes of IT disasters:

• accidental loss of data
• network outages
• natural disasters
• DDoS attacks

All of those can still occur when your IT resources reside in the cloud, so you still need to develop a disaster recovery plan to guide your response.

Building a Good Disaster Recovery Plan

A good disaster recovery plan is very detailed. To make sure you don’t invest time documenting details that don’t matter, start by making sure you know which disasters you need to tackle and what the goals of the plan are—for instance, the goal of minimizing downtime can conflict with the goal of minimizing the cost of the interruption, since some solutions to getting back up quickly can be very expensive.

Next, make sure your plan covers all critical systems. This can require stepping back and developing an inventory of your hardware and applications, if you don’t have a trustworthy database already. This inventory needs to be specific, including details such as the vendor and version number.

Understand the possible effect of an outage on each system through a risk analysis that assesses both the likelihood of a specific cause of downtime and the impact of any downtime. Based on the impact, assess the recovery point objective and recovery time objective that will guide you in building the recovery plan for that resource. Different systems will have different recovery objectives due as they aren’t equally critical. It’s sometimes helpful to separate systems into three tiers: those that are most critical and require an immediate recovery effort, to those that can be down for about a day before impacting the business, and finally those that can be offline for several days without major impact.

Once the systems are prioritized properly, the steps to recover them can be documented. Along with technical procedures, document the personnel who are assigned to the recovery. During the middle of a crisis, you’ll want to know who to call to address issues with each workload. There should be more than one person familiar with each recovery task, in case someone is unavailable.

Make sure to test the plan at least once per year to make sure it works. Because recovery plans can be complicated, set aside time to prepare for the test. This also provides an opportunity to update the plan to reflect any system changes in case the plan wasn’t kept current throughout the year.

Prescient Solutions helps businesses in the Chicago and Schaumburg areas develop, test, and support disaster recovery procedures and environments. To learn more about developing an effective disaster recovery plan, contact Prescient Solutions.