Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How a proper disaster recovery planning process addresses problems

Disaster recovery isn't about crossing your fingers and hoping for the best. A proper disaster recovery planning process means anticipating problems, how to respond to them, and also looking for ways to prevent them, according to Jon Toigo of Toigo Partners International.

"The nature of disaster hasn't changed, not one little bit. Disasters are still disasters," Toigo told his Storage Decisions audience, adding that, "A lot of disasters are preventable, as weird as that sounds." His basic advice for DR administrators: Plan ahead.

"What we try to do is avoid preventable interruption events, and recover as quickly as we possibly can from interruption events we can't prevent," Toigo said. "That's the essence of disaster recovery."

He said administrators have to accept that disasters will occur, and they'll need an effective disaster recovery planning process to best respond to these events.

"Disaster recovery isn't just about migrating workloads from one machine to another, disaster recovery is about business processes," Toigo said. "Disaster recovery is about ensuring that you make your systems purposeful, so people that use them still have a way to access the information they need in order to make decisions and take the actions that need to be taken."

Ultimately, Toigo said the difference between a crisis and a disaster is the amount of time it takes to resolve an incident.

"If the time becomes protracted, you have a disaster," he said. "If the time is short-lived, if it's a hiccup, you have an inconvenience."

View All Videos

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Many years ago I went through a disaster recovery, it was not pretty. I was working on a S/38. During the nightly IPL process we took a power hit during a bad storm. When the power returned we tried to bring up our S/38. No luck. When IBM came it to check out the system we found that the drive that contained the microcode, all the address for the data was "fried". That meant a total reload of the system from tape. The tape library was not the best and after about 2 weeks of restoring and reprocessing the data over again to get all files in sync we were back in business. I have learned over the years, no matter where I was working, to speak up if I found flaws in their process. Better to be safe than sorry.