How to Protect Data During a Virtual Migration

Now that Microsoft has officially entered the hypervisor market, it’s even easier for companies to make the jump from a physical to virtual environment. For every company that has already made the jump, there are dozens of others missing out on the convenience, flexibility and ROI of virtualization.

If you’re one of the laggards, the holdup might be because you’re wondering, “How can I ensure that my company’s data is protected, current and available if we convert to a virtual server?” or “Do I convert manually or use an automated P2V (Physical-to-Virtual) product that streamlines the setup and configuration process, and keeps my data current and readily available?” These are important questions. The good news is, with the technology available today, the answers might be easier than you think.

Selecting a hypervisor

The first step to consider is selecting a conversion process compatible with your selected virtualization product. Contact your virtualization vendor for recommendations and customer references. Whether it is VMware, Microsoft Hyper-V, XEN or Virtual Iron, most will provide you with direction on how to accomplish the process. And if native P2V tools are not available, the vendor likely has software partners that provide this functionality. Having a list of questions to ask about the process will help get you started. Seven important questions to ask are:

Question #1: Does the virtualization vendor have a native P2V process?

Question #2: Does it require downtime of my production server, and if so, how much?

Question #3: How long will the conversion process take?

Question #4: Will I have to reinstall the application on the virtual machine or will it do that for me?

Question #5: How will I keep data changes current once the conversion process starts?

Question #6: Will all my network and application settings remain?

Question #7: What happens if the process fails before it completes? Do I have to start over?

Considering backup and recovery

The next step is to back up every server you plan to convert and review your recovery plans. Some processes will require lengthy downtime of the production server and/or preparation of the applications on the virtual machine, which you should figure into your plan.

There should not be any additional risks to the production server during conversion. But, if the process fails, you should be able to bring that physical server back online and start over. However, if there is a more severe failure in the middle of the P2V process, execute any existing backup or high availability procedures you have in place. The length of the recovery process will depend on the severity of the failure. Below are three examples of types of failures you could face:

Failure type #1: Site failure

If there is a site failure due to a power outage, fire or a weather-related event, you have a bigger problem on your hands than just the fact that your P2V process failed. So you won’t exactly be concerned with recovering just one server as much as you will be with implementing your business continuity plans to get business-critical servers operating to a functional level as quickly as possible.

Failure type #2: Hardware failure

A hardware failure is less severe than a site failure, but it will still delay your virtual conversion process--unless you have a high-availability solution in place. As long as it isn’t a shared disk array in a clustered solution, you may be able to continue with your virtual migration from the remaining active node. If you have a high-availability solution in place with a redundant server, you should also be able to continue the process while you fix the failed server.

Failure type #3: Disk array failure and data loss

If you have a storage array failure with data loss, you will likely need to recover from whatever backups you have in place before proceeding with the P2V process.

You can’t avoid a disaster scenario, but you can have a recovery plan readily available if your P2V conversion process is interrupted. One solution that helps prevent data loss during a migration is high availability, in which a local redundant server with duplicate data helps keep the P2V process moving. This really is the best way to protect your data during the conversion.

Another option to consider is backing up the server. Whether or not you have an availability solution, always back up before you start any type of migration and/or maintenance of your servers.

Some disaster recovery solutions have the ability to convert physical to virtual machines. If you use one of those products, you may not have to start all over with the P2V process and just re-mirror from the last bit of converted data sent. Some of these products also provide real-time replication, minimizing bandwidth utilization and eliminating downtime requirements for the conversion. Then you aren’t limited to a scheduled outage on a weekend to complete the migration. Your challenge won’t be how to protect your data, as much as it will be how to keep users online and data current during the process.

Whatever method you choose, you should always have a recovery plan. That way, if something goes wrong with the process, you have the ability to recover from different scenarios.

Reaping the benefits

Once you have finalized the conversion, and the P2V process is successful, the last step is to make sure you include testing before you roll into production. Once testing is complete, you can immediately reap the benefits of your new virtual environment, including the most important one: reclaiming your weekends.

 Brace Rennels is a Professional Services Project Manager at Double-Take Software, and a Certified Business Continuity Professional (CBCP). He has been involved with over 1,600 disaster recovery installations at Double-Take Software. He is responsible for managing the message of the professional services organization, the partner channel/OEM-related services activities, and the implementation of new service programs to drive Double-Take Software's sales.

Previously, Brace was Manager of Technical Consulting Services at OpenPages, Inc. There he worked for one of the fastest-growing content management systems for multiple channel publishing. He trained staff on how to conduct and develop Risk and Business Impact Analysis for clients. Additionally, he was a Solution Architect for designing enterprise publishing, print and Web solutions based on customer business requirements. He created the business model, methodology and mission statement for the Technical Consulting Services.

Before OpenPages, Brace worked for General Data Services (acquired by EMC Corporation in 1999) as a Senior Systems Engineer. There he performed Business Impact Analysis to assist architects for enterprise-wide solutions involving hardware, software and business processes. He was awarded the Professional Services Contributor of the Quarter award for outstanding efforts in FY99. He can be reached at brennels@doubletake.com.