Exploring Disaster Recovery Options

Now that my disaster recovery budget for 2009 has been wiped out, I'm trying to find some kind of replacement that won't cost any money upfront. I can't in good conscience sit idly by while we roll out critical services without the safety net of DR -- that's like watching a friend drive without a seat belt. Maybe there's a very good chance that nothing bad will happen, but if something does go wrong, the consequences can be so severe that the overall risk is beyond acceptance.

Our existing applications already have cold standby systems set up in our alternate data center, so I'm focusing on systems that will be deployed this year. (Heaven forbid if someone gets the bright idea of repurposing any existing DR servers. I'm afraid it will sound like a no-brainer for saving money; I certainly won't be bringing it up to anyone.)

I found a great article on Computerworld 's Web site ( "How to Build Realistic Disaster Recovery Options" ) on overcoming budget objections to get buy-in for DR. It emphasizes setting realistic expectations and educating upper management. Good advice, but my managers still decided that this isn't the time to spend money on DR, even though they claim to understand its value.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Now that my disaster recovery budget for 2009 has been wiped out, I'm trying to find some kind of replacement that won't cost any money upfront. I can't in good conscience sit idly by while we roll out critical services without the safety net of DR -- that's like watching a friend drive without a seat belt. Maybe there's a very good chance that nothing bad will happen, but if something does go wrong, the consequences can be so severe that the overall risk is beyond acceptance.

Our existing applications already have cold standby systems set up in our alternate data center, so I'm focusing on systems that will be deployed this year. (Heaven forbid if someone gets the bright idea of repurposing any existing DR servers. I'm afraid it will sound like a no-brainer for saving money; I certainly won't be bringing it up to anyone.)

I found a great article on Computerworld 's Web site ( "How to Build Realistic Disaster Recovery Options" ) on overcoming budget objections to get buy-in for DR. It emphasizes setting realistic expectations and educating upper management. Good advice, but my managers still decided that this isn't the time to spend money on DR, even though they claim to understand its value.

So, I'm looking for low-cost alternatives. So far, I've thought of using development and test systems as fallbacks, leveraging virtual server products to take snapshots of production systems that can later be installed on virtual servers in the event of an incident, and turning to cloud computing .

Using development and test systems for recovery would essentially be free. It's a time-honored approach, but it comes with challenges. We'd have to move those systems to our off-site data center, which could lead to hassles for our developers. In addition, our nonproduction hardware usually has much less capacity than our production systems and can't be expected to perform well under a full load. And because the test hardware is often different from our production hardware, we'd have difficulties during the restore process. My experience has been that such recoveries usually fail. But the option might still be better than nothing.

Virtual machines are a potentially more reliable alternative. Regular snapshots of production servers would give us high confidence that we could re-create them in a virtual environment. I'm not sure this is going to be easy to do with nonvirtualized systems, though.

Most of our servers run on dedicated hardware, so we would need to put them through a migration to a virtual environment and keep those images safe in our alternate data center. And, of course, we would need to have hardware available at our DR site to be able to install our virtual machines, and we don't have that today. And we don't have the money to buy any hardware enclosures. While this may not be a perfect solution, we may be able to design around some of these challenges.

Cloud (or grid) computing, which seems to be emerging as a realistic choice for on-demand computing capacity, is the third possibility. The idea of being able to bring up a complete virtual data center when needed, simply by purchasing compute time, sounds like a cost-effective alternative for DR. Hey, why pay for an expensive computing infrastructure that you don't need until you do need it? Of course, that's harder than it sounds, and it's also potentially insecure. A lot of analysis is being done on the security of cloud and grid environments, with the outcome looking a bit -- well, cloudy. But I have to wonder how important the security considerations are, since we would be doing this only if a serious disaster were in progress. I'll need to take a closer look before I decide.

For more enterprise computing news, visit Computerworld. Story copyright Computerworld, Inc.