Tip

Take a hard look at your disaster recovery plan

Russell Olsen

    Requires Free Membership to View

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 russgolsen@gmail.com.

This was first published in May 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.