The article in CIO magazine, How Microsoft Hyper-V Helped My IT Shop Revamp Disaster Recovery, details my efforts to reorganize network and recovery operations around storage and server virtualization. It also mentions the year-long virtualization study that I did in 2007/2008.

My data center has been recognized by IDG'S Computerworld for our use of server and storage virtualization. Computerworld awarded my team the "Best Practices in Infrastructure Management" award in the Data Center Management, IT Operations and Business Continuity category.

Using virtualization as a disaster recovery strategy can in one of two scenarios:

First scenario is vm to vm. Put a hypervisor at the production site and another at the recovery site. Run the production server in a vm. Replicate the vm drives to the recovery site. During a disaster, boot the vm up on the recovery hypervisor.

The second scenario is bare metal to vm. Put a physical server running on bare metal at the production site. Stage the physical server with the necessary vm drivers (in Hyper-V, this is called the Integration Components.) Put a hypervisor at the recovery site. Replicate the disks. During a disaster, boot the server up as a vm on the recovery hypervisor. The second scenario requires block level replication and the ability for the hypervisor to read native disks. If both of these requirements are not possible, an alternative solution exists. This is to restore the production server into a vm using software that supports VM P2V DR. Examples of this software include Acronis, Arcserve, and Backup Exec. The downside is that this option takes significantly longer.

Some quick thoughts on using server virtualization for disaster recovery. The key metrics in using VMs for DR is RTO and RPO. These are defined during the BIA process. One question that I wrestled with was how to get a near time RTO (within minutes before the disaster) and a rapid RPO (within 1hours after the disaster).

Traditional P2V techniques rely on a live system or a nightly backup, so RTO is up to 24 hours. Traditional P2V also relies upon writing the data back out into virtual disks, so the RPO for our average server was up to 7 hours. We addressed these challenges by keeping the storage on a backend SAN and pointing the disk into the VM in the event of a disaster. The RTO is then near time and the RPO is an hour or less.

The DR strategy requires native NTFS disk access and SAN support. Both VMware ESX and Hyper-V support this type of DR. Linux based hypervisors such as Xen do not.

Business continuity and disaster recovery have been on my mind a lot lately. The SNW conference is fast approaching and I am putting the final touches on my slide deck. One question is when and where a company should open a backup data center.

First, and I cannot stress this enough, do an impact analysis. Do you really need another data center? The text book example is the company, in an earthquake zone, which determines that bolting server racks down and buying additional insurance provides the same level of protection at significantly less cost. Your organization does not operate in a textbook, of course, and you may very well need another data center.

Having made the business case and established the budget, the next question is where to locate the facility. The following should be researched and considered:

• Access – road, rail, and air, telecommunications
• Proximity to current data center (under 30 miles makes real-time fail-over possible)
• Local crime rates (history of protests, strikes, or riots)
• Municipal services (police, fire, ambulance, power)
• Wind patterns (is this downwind from nuclear power plants or military targets?
• Weather patterns (hurricanes, tornadoes, et cetera)
• Geophysical conditions (fault lines and earth quakes)

Gather all of this information and begin looking possible sites. Look for sites that are within budget and near high speed Internet backbone links. Narrow these down to those with redundant power distribution points. Then consider such things as wind and weather. This should narrow the possible sites down quite a bit. Then begin considering how your organization will transport people to this location. Airlines are best, but flights may be grounded in a widespread disaster, so also look for wide accessible highways.

In the end, come up with the punch list of three to five ideal sites. Go out for a site visit and confirm your assumptions. Some sites might not make the cut upon visiting, as your information may be out of date. At the end of this process, you will have done the homework and due diligence to make the recommendation to senior management.

The BlackBerry network went down today. The outage lasted about three hours. Roughly speaking, that’s about three hundred messages, blog posts, and feed updates. I got nothing. Nothing at all. Nothing to read, nothing to learn, nothing to think about. The silence was deafening.

Yet silence did give me time to think. In our cybercentric society, connectivity is our lifeblood. Being disconnected brings a weird bloodless feeling. It reminded me of some stories I had read about the dystopian future, where mankind becomes overly dependent upon technology. What would I do if the BlackBerry network stayed disconnected?

Just as I had this thought, the connectivity picked back up. Feeds poured into my device. A hundred voices asked: have you had any ideas lately?

Back to the machine.

I will be out at the Storage Networking World Conference on April 7 thru 10. On Tuesday, I am holding a session in the Business Continuity/Data Protection track. The topic is Simplifying Business Continuity Planning using OS and Storage Virtualization. Hope to see you there.