Manage Learn to apply best practices and optimize your operations.

A backup strategy for Microsoft Virtual Server virtual machines: Suspend, snap, resume

No piece of data is protected unless you have a proper backup strategy for it. That's why the .VHD files used in Microsoft Virtual Server 2005 R2 pose a problem; their size and peculiar properties make backup difficult. In fact, using some standard backup methods for these .VHD files is risky business.

No piece of data is protected unless you have a proper backup strategy for it. That's why the .VHD files used in...

Microsoft Virtual Server 2005 R2 pose a problem; their size and peculiar properties make backup difficult. In fact, using some standard backup methods for these .VHD files is risky business.

It is possible to run backup software within a given virtual machine and back up any data stored on it that way. This is, in fact, what many people do, even though it requires the additional hassle of having to install and maintain backup software on each virtual machine (VM), as well as the expense of buying additional licenses for third-party backup software, if you go that route.

Backing up the .VHD files themselves, from the outside, is another story. If you make a backup copy of a virtual computer while it's running -- even if you use the Volume Shadow Copy service, which can be used to make snapshot copies of any open files -- it will generally work if you restore it and reboot it, but there's no guarantee that it will work as intended. When you take a snapshot image of a .VHD while the system is still running, you're preserving the virtual computer's data in an inconsistent state. Writes may not have been committed to disk, program settings may be in flux, and so on.

The folks at the blog tried to take the snapshot route. They were using Backup Exec, which supports shadow volumes), and experienced that exact problem: the backup process doesn't deal with what's in the virtual machine's memory at all. This is not really a failure on the part of any third-party backup program because most any backup application written for Windows today -- especially server-level backup solutions -- supports shadow copying. It's simply that the shadow copying subsystem is not aware of what might be in a given virtual server's memory.

This creates a real problem for people who are trying to develop a consistent backup strategy for machines running Virtual Server. It seems like the only way to work around this issue is to shut down all the virtual machines (VMs), run the backup, and then turn the VMs back on again. If the VMs have to be available more or less continuously, this is not a viable solution.

For the time being, there's only one really safe way to work around this: Suspend the virtual machine rather than shut it down completely, make a shadow copy, then resume the system and back up both the shadowed .VHD and suspend information. This way the contents of the system's memory are also backed up along with a copy of the hard drive. If you restore these files out of a backup, the system can be powered on as if nothing had happened (and then shut down cleanly).

This process can be used as a way to back up virtual machines, although it has one obvious stipulation: the VMs being backed up have to be suspended before they can be copied out. That said, the time involved to suspend and resume a production VM is nowhere nearly as onerous as the time needed to shut a VM off completely. In a production environment, if you have a time window you can devote to suspending and resuming virtual machines without incurring major problems, this can be a useful way to back everything up without having to invest in separate software.

Now comes a tougher question: Can the process be automated? The short answer is yes, and there are a few extant examples for how to do this. Jeff Trumbull has written a VBScript which suspends each of the virtual servers running on a given computer, makes a shadow copy (using the VSHADOW.EXE utility from the Volume Shadow Services SDK, and then backs up the file somewhere. The variable DestBackupDir should be set to the destination backup directory (as the name implies) before putting the script into action, but this destination directory can be pretty much anything: a SAN drive, a network-attached drive, another local hard drive, etc. This technique seems to incur the least downtime for backing up a given machine; it's essentially the amount of time required to suspend and then resume the machine in question.

This obviously isn't the best possible solution: the ultimate Virtual Server backup solution would be able to shadow-copy the contents of a given VM's memory as well. But for now, there is no known way to do this, and so the best interim strategy is to plan a regular window of downtime, during off-peak usage, to allow the shadow copies for each virtual server to be rendered.

More on storage and virtualization

Want more information on storage and virtualization? Learn about architecture, operations, managing backups and more in our storage and virtualization all-in-one guide. Hear Barb Goldworm speak at one of our virtualization seminars.

About the author: Serdar Yegulalp wrote for Windows Magazine from 1994 through 2001, covering a wide range of technology topics. He now plies his expertise in Windows NT, Windows 2000 and Windows XP as publisher of The Windows 2000 Power Users Newsletter and writes technology columns for TechTarget.

This was last published in April 2007

Dig Deeper on Microsoft Hyper-V and Virtual Server

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.