RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Disaster Recovery and Business Continuity Planning : Page 3

A disaster recovery plan is the main component of a business continuity strategy, the policies and procedures an organization uses to recover from an IT-disabling disaster.


Step 3 of Disaster Recovery Planning: Develop the Plan

The feedback from the business units will begin to shape your disaster recovery plan 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. Emerson suggests that you have the recovery systems tested, configured, and retested 24 hours prior to launching them. He says the set up takes anywhere from 40 hours to days to complete.

The recovery procedure should be written in a detailed plan or "script." Establish a Recovery Team from among the IT staff and assign specific recovery duties to each member. The manner in which your team conducts its recovery probably will be no different than its regular production procedures: the chain of command likely won't change and neither will the aspects of the network for which each member is responsible.

Define how to deal with the loss of various aspects of the network (databases, servers, bridges/routers, communications links, etc.) and specify who arranges for repairs or reconstruction and how the data recovery process occurs. The script will also outline priorities for the recovery: What needs to be recovered first? What is the communication procedure for the initial respondents? To complement the script, create a checklist or test procedure to verify that everything is back to normal once repairs and data recovery have taken place.

Step 4 of Disaster Recovery Planning: Test, Test, Test

Once your disaster recovery plan 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 disaster recovery plan to address any shortcomings.

As your business environment changes, so should your disaster recovery plan. Reexamine the plan every year on a high level: Do you still need every part of the plan? Do you need to add to it? Will the budget need to be adjusted to accommodate changes to the plan? As applications, hardware, and software are added to your network, they must be brought into the plan. New employees must be trained on recovery procedures. New threats to business seem to pop up every week and a sound disaster recovery plan takes all of them into account.

Glen Kunene is the Senior Editor at DevX. You can reach him at gkunene@devx.com
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date