However, that's not all there's to it. Depending on your SAN platform, your SAN may replicate data in larger blocks than VMware's snapshot files allocate. Thus, a single change of a 1KB file within a VM may be seen as a change to a 16MB block on your SAN -- essentially magnifying the amount of data that needs to move by 16,000 times. This magnitude difference would be a fairly rare occurrence, but it shows that you can't easily predict actual data volumes based on snapshots.
To combat this problem and generally increase the amount of data your WAN can carry, using some form of WAN accelerator that includes deduplication technology is a wise move. Examples of such products include Cisco's WAAS and Riverbed's Steelhead. Both platforms have their own strengths and weaknesses, but they operate in much the same way. They optimize the WAN data flow through intelligent re-windowing and other TCP enhancements, but they also retain a remote cache of what has previously been sent over the WAN link.
In the event that they get a cache hit (a packet that has the same data payload as one seen previously), that packet is not re-sent. Instead, just a pointer to that packets payload is sent to the device on the other end of the circuit. In the example of a 1KB change requiring 16MB of data transmission, a WAN accelerator could essentially nullify the problem.
Step 4: Consider your hypervisor licensing needs
The last thing to think about is what additional hypervisor licensing you may need to acquire for your warm site. You could configure new ESX hosts and run them unlicensed, only moving the production licenses to them in the event of a production site failure, but this will make it impossible to test anything while the production site is active without breaking your license agreement.
Another option is to purchase licensing for VMware vSphere Essentials, which will operate with a much more limited feature set than on your production site, but still be able to start and run your VMs.
Another issue to consider is whether you want to implement VMware's Site Recovery Manager (SRM). SRM requires that you do SAN-to-SAN replication with SANs support it (most do), and it is somewhat expensive. However, if being able to test your recovery plan frequently and having a completely automated failover process is important to you, implementing SRM is certainly worth a close look. It's also worth noting that vSphere 4.0 support for SRM likely won't be available until later this year.
If you do it right, reusing retired hardware is a great idea
Taking advantage of retired hardware to build a warm-standby datacenter is a fantastic use of resources and builds in backup computational capacity you'll be happy to have if you ever need it. However, blindly building a warm site without a plan -- regardless of how much extra hardware you have kicking around -- isn't likely to work out well in the long run.
Failing to do any of several things -- set goals properly, consider storage resources, keep WAN bandwidth in mind, or take into account software licensing limitations -- will almost certainly make the exercise more expensive and less effective than it could be.
Notwithstanding all of these challenges, today's virtualization technology, coupled with modern storage and networking technology, makes it far easier to build always-on standby failover capacity than it ever has been in the past. If your organization places a high value on uptime, now is the time to put your toe in the water and give it a try.
Read more about virtualization in InfoWorld's Virtualization Channel.