Disaster recovery planning is a bit like building a bridge with toothpicks. Just when you think you have the support beams in place, they float away. Disaster recovery planning can be an enormous task — and proportionally so with a larger network.
You have probably heard the adage "If you fail to plan, you plan to fail." This clearly applies to the disaster recovery process. You can develop a very robust plan, but if you never test it, how can you know how well it works? No matter what technique you choose to test a response plan, keep the following points in mind:
♦ Failures don't exist. No matter what you do during a test, any results that you receive are worth something. The only failure is not testing at all. All tests yield results, and these results help administrators gain a better knowledge of their system and the systems with which it interfaces.
♦ Set objectives. Because most administrators have very limited time, a thorough plan with objectives can drastically reduce the time necessary to test a system. This plan and its objectives can usually be performed in steps. Completing all the steps at once isn't necessary; you can complete a few steps one day and maybe a few more the next week. You can also quite possibly test the steps out of order, which might suit the schedule of the administrators. In testing a system, make sure that the objectives are well defined. Set time limits on the tests and compare those times to the actual results. This procedure ensures that the modifications you make to the test plan in the future accurately reflect the time that recovery takes for your particular system in its current environment.
♦ Action items. Every test should be timed and well documented, and all the steps and the final outcome should be well documented. This enables you to review all the steps and provide training material to other employees who may become responsible for portions of the system. Documenting a system, testing it, and then keeping all the results in your head doesn't do anyone any good. (If you should happen to, say, step in front of a bus, all progress is lost if you failed to document the test results.)
♦ Frequency. Test often! Creating a plan and testing it once is only good until certain aspects of your system change enough to make your plan obsolete. Not only should you schedule regular tests on your system, you should also ensure that you test it whenever anything major changes. If new routers or servers are added or the network topology changes, you should automatically begin a new test of your plan. If enough changes in your system and its surroundings, the plan is quite likely to need updating.
♦ Consultants. Some consultants specialize in testing systems. It may be helpful to pick their brains and gain some insight into the world of testing. Many software packages out there can also assist you in your testing. To be of any use, however, these software packages must be extremely configurable; some may even contain a scripting language. Look into these products and try to locate a consultant who specializes in them.
Response plans and their testing is a very large subject that can consume not only a single book but literally volumes. For many of the sophisticated technologies out there today, you can pick up a book that can help you narrow your testing and get very specific with it.
Was this article helpful?