IT Disaster Recovery Planning For Dummies Quotes

“Why test a DR plan? Disaster recovery plans contain lists of procedures and other information that an emergency response team follows when a natural or man-made disaster occurs. The purpose of the plan is to recover the IT systems and infrastructure that support business processes critical to the organization’s survival. Because disasters don’t occur very often, you seldom can clearly tell whether those DR plans will actually work. And given the nature of disasters, if your DR plan fails, the organization may not survive the disaster. Testing is a natural part of the lifecycle for many technology development efforts today: software, processes, and — yes — disaster recovery planning. Figure 10-1 depicts the DR plan lifecycle. Figure 10-1: The DR plan lifecycle. When you test the DR plan, note any discrepancies, and then pass the plan back to the people who wrote each section so they can update it. This process improves the quality and accuracy of the DR plan, which increases the likelihood that the organization will actually survive a disaster if one occurs. Another great benefit of DR plans and their tests is the likelihood that, by undertaking them, you can improve the organization’s everyday processes and systems. When teams closely scrutinize processes and figure out how they can protect and recover those processes, often the team members discover opportunities for improvement. Sometimes the question, “How can we recover this system?” gives people the opportunity to answer the question, “How can we improve the existing system?” Be open to those opportunities because they’ll come, sometimes in droves. The types of testing that I discuss in this chapter are Paper tests Walkthrough tests Simulations Parallel tests Cutover tests These tests range from the simple review of DR procedure documents to simulations to running through procedures as if you’re experiencing the real thing. Developing a test strategy DR testing in all its forms takes considerable effort and time. To make the best possible use of staff and other resources, map out a test strategy well in advance of any scheduled tests. Structure DR testing in the same way you structure other complicated undertakings, such as software development and associated testing. Just follow these steps: 1. Determine how frequently you should perform each type of test. 2. Test individual components. 3. Perform wider tests of combined components. 4. Test the entire plan. When you perform DR testing as outlined in the preceding list, you can identify many errors during individual tests and correct those errors before you do more comprehensive tests. This process saves time by preventing little errors from interrupting comprehensive tests that involve a lot of people. Virtually every enterprise that builds actual products performs testing as outlined in the preceding list. Businesses have found this test methodology to be the most effective way to ensure success in a reasonable timeframe. Figure 10-2 shows the flow of DR testing.”
― Peter H. Gregory, IT Disaster Recovery Planning For Dummies®