The first step in drafting a disaster recovery plan is conducting a thorough risk analysis of your computer systems. List all the possible risks that threaten system uptime and evaluate how imminent they are in your particular company. Anything that can cause a system outage is a threat, from relatively common man made threats like virus attacks and accidental data deletions to more rare natural threats like floods and fires. Determine which of your threats are the most likely to occur and prioritize them using a simple system: rank each threat in two important categories, probability and impact. In each category, rate the risks as low, medium, or high.
What would you do if a storm flooded your companies data centre? Or how would you respond if a power outage blacked out your servers? How would you recover your data and keep the business running after an unforeseen disaster? When disasters strike unprepared companies the consequences range from prolonged system downtime and the resulting revenue loss to the companies going out of business completely, yet many companies are not prepared to deal with such scenarios. The key to surviving such an event is a business continuity strategy, a set of policies and procedures for reacting to and recovering from an IT-disabling disaster, and the main component of a business continuity strategy is a disaster recovery plan (DRP). Step 1
Once you’ve figured out your risks, ask ‘what can we do to suppress them, and how much will it cost?’ Can I detect a threat before it hits? How do I reduce the potential of it occurring? How do I minimize its impact to the business? For example, our small company could employ an emergency power supply to mitigate its power outage threat and have all its data backed up daily off site, at a remote datacentre in case of a disaster. The more preventative measures you establish upfront the better. Pounds spent in prevention are worth more than Pounds spent in recovery.”
The feedback from the business units will begin to shape your DRP procedures. If, for example, they determine that the company must be up within 48 hours of an incident to stay viable, then you can calculate the amount of time it would take to execute the recovery plan and have the business back up in that timeframe. Now you can have the recovery systems tested, configured, and retested 24 hours prior to launching them.
Once your DRP is set, test it frequently. Eventually you’ll need to perform a component-level restoration of your largest databases to get a realistic assessment of your recovery procedure, but a periodic walk-through of the procedure with the Recovery Team will assure that everyone knows their roles. Test the systems you’re going to use in recovery regularly to validate that all the pieces work. Always record your test results and update the DRP to address any shortcomings.