Manage Learn to apply best practices and optimize your operations.

Take a hard look at your disaster recovery plan

Four major steps are required to properly evaluate an IT disaster recover plan test. Disaster recovery expert Russell Olsen addresses the first two: identifying source files and doing a verbal walkthrough.

Russell Olsen
Russell Olsen

Arguably, the two most important factors in an IT disaster recovery plan testing are keeping the plan current and testing the plan to verify that in a crunch you could actually deliver what your plan has documented.

In an ideal world, every year you would take your disaster recovery team to an offsite location with nothing but your backup tapes and fresh hardware. You would then carry out a flawless rebuild and restoration of your production systems. Sound nice? Unfortunately, most companies don't have the capacity to annually execute a full test of their disaster recovery plan. Even companies that are able to do that should still do something to supplement that practice.

So here's my question: How can you avoid calling your boss at 2:00 a.m. , asking him or her to forgive you because you forgot to verify users who were placing important files on the DFS share?

There are four major components to testing a disaster recovery plan. Two of the activities are identifying source files and doing a verbal walkthrough of the plan. In our next article, the other two activities, using existing projects and learning from your mistakes, are described.

Identify source files

More on disaster recovery planning:

Part 1: Integrating DR plans into daily operations

Part 2: Charting a disaster recovery plan

Part 3: The disaster recovery execution methodology

Part 4: Testing your disaster recovery plan

Part 5: More testing of your disaster recovery plan

Part 6:  Integrating mobile devices into your DR plan

Source file identification is a fundamental concept to a disaster recovery plan, but many people fail to address it adequately. Do you know how to get copies of all the software and proprietary applications you would need to rebuild after a disaster? The answer given by the overconfident camp is "It is backed up." My first response is "Are you sure? Can I get a copy? Right now?"

You might find that most things are backed up, but if you evaluate the backup at your fingertips, you might find some things missing -- such as, database schemas, stored procedures, firewall rule sets and DFS shares. For a DFS share, are users placing all the source files in the appropriate directory? Another thing you might discover is that you are missing the basics – do you have a copy of Microsoft Windows Server 2003?

You never know when your image or backup will fail and you will need a copy to start from scratch.

Don't forget to ask your team members if they have offsite backups of the miscellaneous tools they use, such as custom LDAP search scripts, VB scripts and PowerShell scripts for Windows Server 2008 and Exchange 2007.

Verbal walkthrough

Pizza for the team -- $50. Catching a problem before it is too late -- priceless.

You'd be surprised at what you can get out of a half-hour lunch with your team. An open discussion is good for reviewing how prepared your organization is for a disaster. The key to make it successful is to invest some time in planning the agenda beforehand.

The agenda for reviewing your disaster recovery preparedness might look something like this:

  • Overview (goals and objectives of the meeting)


  • Windows Server Team
    * DRP presentation by team lead
    * What if analysis
    * Action items resulting from the analysis
  • Active Directory Team
    * DRP presentation by team lead
    * What if analysis
    *  Action items resulting from the analysis
  • Microsoft SQL Server Team
    * DRP presentation by team lead
    * What if analysis
    * Action items resulting from the analysis
  • Exchange/Messaging Team
    * DRP presentation by team lead
    * What if analysis * Action items resulting from the analysis
  • Action items (Summary)

A "what if analysis" is an exercise when each member of the team ask "what if" questions to the team to see how well prepared they are for a variety of disasters.

The final step to this exercise is to schedule a follow-up meeting to make sure each team addressed its action items. The team leads for each area should have ownership of their respective action items. This exercise can be repeated on a quarterly basis to make sure disaster recovery stays at the forefront of everyone's minds.

Continue to part two, Testing your IT disaster recovery plan: Learn from your mistakes.

Russell Olsen is the CIO of a medical data mining company. He previously worked for a Big Four accounting firm. He co-authored the research paper "A comparison of Windows 2000 and RedHat as network service providers." Russell is an MCP and GSNA. He can be reached at

Dig Deeper on Enterprise infrastructure management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.