* When to get management involved in disaster recovery, and other advice
First, the winner of last week’s Stupid IT Tricks Award goes to: Iron Mountain! Once again, the company has lost more tapes, this time from City National Bank of Los Angeles. City National’s depositors shouldn’t worry though – the company says the tapes were “merely lost,” and that identity theft was not a factor.
I am sure you City National customers all feel much better about things now. The tapes are likely warm and safe, perhaps cuddled up against the tapes from Time Warner that Iron Mountain lost in March. Looks like it might soon be time for more columns on tape encryption.
On to a happier note: Last week we published the first set of responses from IT managers who shared their favorite single rule for planning for disaster recovery. What follows is a set of simple rules of the road for disaster recovery – cheap, elegantly simple, and useful. I’ll print more next week.
From reader John Weinhoeft:
* Assume in a disaster that your best people will not be available. Thus, don’t just test the plan; test the plan with people who have never seen the plan before. That way you find all the missing assumptions.
From reader Paul Rivers in the U.K.:
* Yes, test the plan, but ensure that senior management also tries out (through role play) scenarios that might, or might not, initiate the recovery plan. Not all disasters start with a big bang! It’s a major decision, and a difficult one, to take a company into recovery mode – especially when the systems director is confident that the problem will be fixed in a few hours more ………!
* Also, evaluate and plan (how do you test?) switching back from the recovery site into full production mode.
Reader Jim Morin (Morin Consulting) has put together the following business continuity guidelines during his many years of experience:
1. Categorize applications (A, B, C) by business criticality to determine protection level requirements.
2. Develop your cost of downtime for these applications.
3. Formulate solutions that balance solution cost for data protection vs. cost of downtime.
4. Plan for longer implementation period than expected because of process changes.
5. Implement mandatory periodic testing.
6. Fit data center disaster recovery strategy within overall corporate business continuity objectives.
Thanks to all who contributed!
