Virtualizing your physical servers automatically provides substantial benefits. Virtualization's added mobility...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
means that servers can run from any host. Disk consolidation enables a server's thousands of files to be encapsulated into a single virtual disk file. Block-level backups allow for the crash-consistent archival of that single file in alternate storage or remote locations. Yet all of these benefits are directly attributable to virtualizing a server. But what if you have a physical server that's a poor candidate for virtualization? You're forced to use a local-client backup that can miss files and result in an unsuccessful restore.
Lately, though, a new concept for physical server backups has gained traction, in which virtualization administrators schedule regular physical-to-virtual (P2V) conversions of physical servers and create P2V backup files in the event of a disaster. In this tip, I'll explain the concept of a P2V disaster recovery strategy, outline the tools to execute the process and explain why you should consider this backup option.
Disaster recovery for physical servers: The old way
Physical servers must still be backed up "the old way," with a local backup client that carefully copies every file to alternate storage. With the old method, even a single file that is locked for reading or missed by the backup client can result in an unsuccessful restore. That's why many organizations don't trust the disaster recovery capabilities of their traditional backup systems.
While traditional backup processes are great for restoring single files that a user has accidentally lost or deleted, their ability to bring back entire computers after a disaster isn't 100% ensured. The problem is that not all physical servers make good candidates for virtualization. Some machines with high resource use or bad combinations of applications just don't make sense in the virtual world. As these bad apples can't be virtualized, they will never receive the benefits of their virtual brethren. Or will they?
Physical-to-virtual disaster recovery
In virtualization circles, P2V disaster recovery has made progress toward resolving this problem. This concept uses tools already present in your virtual environment normally used for P2V conversions. Essentially, you'd execute a regular P2V conversion for servers that you never intend to run as virtual servers. The resulting disk file through the P2V process might never be used in production, but it might just save the day in the case of a disaster situation.
To understand this concept, consider the following situation. Let's assume that you have 10 servers in your environment. Of those 10 servers, seven have been virtualized on top of a virtualization platform. The remaining three servers are high-utilization "problem children" that aren't virtualization candidates. Perhaps one is your company's production SQL server, or a high-use Exchange server. Maybe you have internal political issues that preclude them from being virtualized. Whatever the reason, you keep these servers as physical instances.
To protect virtual servers, you have implemented block-level backups using a virtual backup technology. The backups of those servers' Virtual Hard Disk (VHD) or Virtual Machine Disk Format (VMDK) files are regularly archived to an alternate location -- either through regular backups or a continuous data protection technology. But the three remaining physical servers are protected only through the use of traditional backup client software.
With P2V disaster recovery, you create an additional mechanism to protect these servers by scheduling a regular P2V "conversion" of them. In this situation, your P2V software examines physical servers to encapsulate their files and folders into a single VHD (for Hyper-V or XenServer) or VMDK (for VMware) disk file. The caveat here is that instead of using this disk file to virtualize the machine and eliminate its physical instance, you simply keep these files for archival purposes. With this added step, you create a process that captures a physical server's configuration much like that of a traditional backup, but with all the benefits of virtualization's block-level backups. The single-file backup for these physical servers gets stored onto a tape drive or other archival device for off-site rotation.
The major difference between P2V disaster recovery and traditional backup client software is the restore process. When a disaster occurs, you can simply restore the server's virtual disk file and power it on inside your disaster site's virtualization platform instead of working with the shortcomings of traditional backups. The result is an immediate restoration of that server. If you're lucky and never experience that critical disaster, you never have to make use of the backed-up P2V disk files.
Tools needed for P2V disaster recovery
So which tools do you need for backup and recovery of physical servers? For small environments with minimal needs, you probably already have the necessary tools: Smaller environments that have moved to virtualization are likely to have P2V software available within their virtual platform. VMware, for example, comes equipped with its VMware Consolidated Backup tool for light needs, and Microsoft's System Center Virtual Machine Manager (MSCVMM) arrives with P2V capabilities built in. Most other virtualization platforms include P2V as a part of their software as well.
These tools enable P2V, but they don't have the management capabilities needed for enterprise environments. Few platforms include the ability to regularly schedule the P2V process so that it completes without administrator involvement. But higher-end software from Vizioncore and PlateSpin include P2V scheduling, which is essential for this process, as well as other management capabilities that are necessary for environments that desire a large-scale P2V disaster recovery implementation.
One important caveat is to remember the result. With the P2V disaster recovery strategy, a restore is intended only for use after a real disaster. The reason should be clear: Once you've initiated a restore, you've effectively virtualized a server that you didn't want to virtualize before the disaster occurred. A P2V disaster recovery restoration option should include failback steps that enable you to "physicalize" any server once the disaster is over and you return to normal operations.
ABOUT THE AUTHOR: Greg Shields, MVP, is a co-founder and IT guru at Concentrated Technology (www.concentratedtechnology.com) with nearly 15 years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent book Windows Server 2008: What's New/What's Changed is available from SAPIEN Press.
Dig Deeper on P2V, V2V and V2P migration