Disaster Recovery Exercises, Part 2
I have seen organizations schedule a DR exercise with very little preparation or planning in advance. While this may sound like a good test (“we don’t know when a disaster will happen, so let’s exercise it that way”), it is really a poor use of your time. Particularly if you are testing at a 3rd party recovery center with a limited time allowance. You risk running out of time messing with little problems that could have been solved in advance, and having a useless exercise (there is no fail, only learn – Yoda?:-) )
Know what you want to exercise, and don’t get derailed by something that is not part of the scope. For example, if you want to see if users can get into your backup site via VPN, be sure your users that will be testing are able to do so. You’re testing the technology and availability, not user skill at this point. Give them sufficient training or step by step scripts so that you can focus on your exercise, not on holding the user’s hand. You can evaluate the skills of your users in a smaller subsequent exercise if you want to do so.
Pretest everything you can. If you have a dedicated recovery site, verify your backups and network connections, etc. to be relatively confident that they will perform as expected on exercise day.
Set expectations. Review exactly what you expect to happen on exercise day with your team in advance, and go over important milestones repeatedly. This will help minimize surprises and the associated stress they bring.
Keep it simple. I have seen numerous examples of people creating piles of colorful and detailed spreadsheets, thick documents with infinite details that take hours to compile, etc., only to have management glance at them and have no idea how things went. These documents look good, but no one in senior management wants to see that stuff. They want easy to understand executive summaries that tell them where the company stands in a snapshot. The same goes for your functional testers (users). Over complicating their role will cause undue stress and opportunities of error. Just tell them something like “I want to you log in, and see if you can use the application just like you do every day. If not, write down what doesn’t work”.