Those were the types of DR steps we took a few years ago and we've fairly aggressively moved to replication technologies; whether this is via storage arrays or host-based agents. We moved first into replicating data, via a storage array or a host-based tool for a remote site, supporting that at the standby server. But when we started doing that, sticky issues remained in managing physical servers across sites.
First, physical machines have lots of hardware dependencies and create many opportunities for hardware dissimilarities across sites. You get a couple of machines out of sync in your DR site -- maybe because you replaced them during the last cycle replacement. There's a good chance that your replicated drives won't even come up on these remote machines. Moreover, often, there's no clean way to address replicating boot volumes. A few organizations have turned to boot from storage area network (SAN), allowing the use of sophisticated replication technologies. Many organizations are stuck with replicating local server boot volumes with local agents. This is hard to manage when you start distributing thousands of agents across your environment. There's lots of I/O impact, but some solutions offer opportunities for reducing the size of replicated data streams across sites, saving valuable bandwidth.
Now more organizations are looking at server virtualization at primary and remote sites to ease server configuration issues and optimize the use of DR site resources as well. More organizations do this with DR in mind because of TCO-lowering DR management tools like VMware Inc. Site Recovery Manager. This allows easier management testing if you're using virtualization at both sites and can increase flexibility and the amount of use of the remote site when you're not using it to support a disaster.
So, when you move into a server virtualization environment at your primary site, server images become much more portable because they're not tied to specific hardware any longer, they're now encapsulated in this server virtualization environment. That server virtualization environment becomes the same at the remote site, regardless of the dissimilarities in underlying hardware.
As long as you have your host environment, your VMware ESX Server or your Microsoft Corp. Hyper-V Server set up right, that hardware is going to appear the same as the virtual image. I also think part of this is behavioral because server virtualization encourages us to separate data from virtual server boot volumes and encourages us to SAN-attach our virtualization environment in order to make more use of server virtualization features like moving host images back and forth across hardware.
When virtual images are stored on a SAN, it's easier to move them across hardware to get a load-balanced environment. Then, when they're on a SAN, it's easier to make better use of data protection and replication tools like snapshots. These can be array-based from a storage vendor like IBM Corp., Hewlett-Packard (HP) Co., Compellent, 3PAR Inc., EqualLogic, LeftHand Networks Inc. Or, these tools could even be from a heterogeneous storage virtualization vendor like DataCore Software Corp., IBM or FalconStor Software.
Some of these tools even offer broader reaching features, including their own functionality such as snapshots and replication, or they can be single point management. One example is DataCore. That product can even port virtual images from one format to another and allow you to protect your ESX environment with Hyper-V at another location. That might be cost-optimal for you.
That's an extreme example and you're likely to face some compatibility issues, but there are other features to be had on top of these snapshot and replication tools. Regardless, in moving to server virtualization, you can harness all the capabilities of your storage environment, replication tools and snapshot tools. You can also ease the copy of data to your DR site to get closer to the moment before your disaster happens and make sure your data and remote site has more integrity.