"You have to prioritize there," Olds says. "It would be silly and needlessly expensive to have your entire infrastructure mirrored so that you could instantly recover every application. The vast majority of businesses don't need that kind of availability."

One way to do this is to make a list of the applications and data that your business needs to have first in an emergency, followed by the apps and data that would be nice to have at that point. The remaining apps and data can return later, when the disaster is over.

Meanwhile, don't forget to get other input inside your company when making these kinds of decisions. "IT leaders need to be sure that they are bringing in the business side on this stuff," he says. "You want to make sure that what IT thinks should be brought back in first gets agreement from the people on the business side, too."

By testing your emergency plans regularly, you can ensure that no critical steps are left out, such as network topography details and your company's IP addresses. "These are all things that you won't necessarily think about in an emergency," Olds says. "You need to be able to move this all over and mirror it so it is all available outside your company infrastructure if it is out of service. If your data center is under water for a while, you need to have a long range plan."

Once you start this kind of testing, you need to remember to keep it up, especially when you make new changes to applications and to your hardware infrastructure, he says. The reason is simple - you have to be sure that the system changes you make on a regular basis don't interfere with your existing disaster recovery systems and cause them to fail at the worst possible moment.