It's summer across the United States, and that means that hurricanes, tornadoes, floods, wildfires, powerful thunderstorms, and other natural disasters can take out your company's IT systems in a flash.
As a result, you no doubt have disaster recovery plans and procedures in place for your company's IT systems and critical enterprise applications. However, those capabilities are just the start.
Once built, those plans, from off-site data centers hosting your critical applications to data backups that are available at the flick of a switch when needed, have to be maintained, updated, and tested on a regular basis so that they absolutely, positively can be relied on in a real disaster.
For many IT organizations, that kind of testing is often nonexistent. Without scheduled reviews and testing, your disaster recovery efforts could themselves be a second disaster waiting to happen.
"I know that it's really scary for organizations to reach over and flip a switch to power down a server that's running in production, but that has to be done once in a while to check out a disaster plan," says Daniel M. Kusnetzky, principal analyst at Kusnetzky Group LLC. "The last thing that you want to have is a plan that hasn't been tested before a disaster."
A key reason for testing your procedures, Kusnetzky said, is that if they don't go as planned it's certainly better to know that when the power is on, your staff is onsite and your business isn't being threatened by a true natural disaster.
Your IT staff needs to be able to ensure that in an emergency they can get critical business applications up and running, as well as all the connected systems on which those apps rely, Kusnetzky says. "It isn't just the applications, but also the complete configuration that the application is used to running on. It all needs to be there or it will require a reconfiguration of the processes or the application itself."
The only way to know if it will all works as designed is to test it, push it, and test it some more, he says.
"Just copying the application somewhere and just turning it on won't necessarily make it available to your company's workers," Kusnetzky says.
This is an instance where virtualization could be helpful, because if the workload is running inside one or more virtual machines, then they are not reliant on hardware differences within your disaster recovery strategy, according to Kusnetzky. For those same reasons, using virtual storage could be beneficial.
At the same time, virtualization won't solve all related disaster recovery complications. "Virtualization can help, but like anything else, it's not a panacea," he says. "It's just a tool. You need to do other things as well."
Dan Olds, an analyst with Gabriel Consulting Group, says that a good way to approach disaster recovery testing inside an enterprise is to do it one system at a time to minimize the impact on your IT staff and procedures.
"It's not only testing your [disaster recovery] vendors to be sure that it can all be done in an emergency, but it's teaching your people how to do it," Olds says. "It's getting that knowledge so they're not scared to death about it if something happens. You've got to get comfortable with it and it's better to get comfortable when you have help and when it's not time- sensitive and do-or-die, like when the floodwaters are rising outside."