Backing Up Live Virtual Server VMs

One of my favorite Virtual Server 2005 R2 SP1 features is the included VS Writer, which leverages the Volume Shadow Copy Service (VSS) to back up running virtual machines.

In order to take advantage of VS Writer, you have two options:

Use backup software that supports VS Writer (note that support for shadow copies does not guarantee support for VS Writer).

Write a script that creates the shadow copy of the virtual machine files and then backs them up.

VS Writer does some great things when it is called. For instance, if the guest OS, such as Windows Server 2003, supports VSS, then VS Writer can talk to VSS inside a VM guest OS to properly prepare its applications for a shadow copy. Guest operating systems that do not support shadow copies, such as Linux guests, will be automatically suspended prior to the shadow copy, and then resumed once the shadow copy completes.

In the past, administrators had to manually suspend and resume all VMs to successfully create a reliable shadow copy. This approach is used in Jeff Trumbull's excellent script. Note that for shadow copy backups of virtual machines to work successfully, they all must have the latest edition of the Virtual Server VM additions installed inside their guest OS. For Linux VMs, please see Ben Armstrong's blog on the subject.

Backup software that supports VS Writer can back up running virtual server VMs by creating a volume shadow copy that contains each of the VMs' open files and then backing up the VM files associated with the shadow copy.

If your backup software does not support VSS and VS Writer, then you can still reliably back up Virtual Server VMs from the physical host using a vbscript. To back up running virtual machines, the script needs to perform the following tasks:

Create a snapshot of server's volume that stores the virtual machines.

Mount the snapshot to a temporary drive letter.

Copy the virtual machine files to your preferred backup location -- either a locally mounted drive or a UNC path.

With that in mind, let's look at implementing a scripted solution. Steps 1 and 2 are the toughest, and rely on vshadow.exe to create and manage the shadow copy. Vshadow.exe is included in the VSS Software Development Kit (SDK). So, to script a live backup solution, you will first need to download the VSS SDK.

Once the download completes, the VSS SDK can be installed by following these steps:

Run Setup.exe to install the VSS SDK.

When the InstallShield Wizard opens, click Next.

Click the "I accept the terms in the license agreement" radio button and click Next.

Modify the software installation location, if desired, and click Next to continue.

Click Install to start the installation.

When the installation completes, click Finish.

You now need to create a folder on the virtual server system to store the script and its dependent vshadow.exe file. For example, in my lab I created a folder on the C drive named "scripts." Once the C:\scripts folder is created, copy the vshadow.exe and vshadow.pdb files from the "C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps \vshadow\bin\release-server" folder to the "C:\scripts" folder. Note that I deployed the VSS SDK on an x64 server. If your Virtual Server system is 32-bit, then the required vshadow files will be in the "C:\Program Files\Microsoft\VSSSDK72\TestApps \vshadow\bin\release-server" folder by default.

Next, you need to download and copy the vsbackup.vbs script to the C:\scripts folder. The vsbackup.vbs script is shown in the code here:

Note that the script uses the shadow copy logic from Jeff Trumbull's backup script. Jeff's vshadow.exe scripting logic was spot-on, so I decided not to reinvent the wheel.

To use the script in your environment, you will need to modify the following variables:

strBackupDir

strVMdrive

strVMfolder

strTempDrive

strBackupDir should be set to the target location for the backup files. This could be a local mount such as "E:\Backup\VS" or a UNC path such as "\\fs1.redmondmag.com\vs1\backup." Note that you should only replace the first path defined by the variable, as the remaining portion of the variable definition is used to append a backup folder to the folder path that is named after the current date and time.

strVMdrive is the drive letter of the drive that stores the VM files. Since shadow copies occur at the volume level, it's most economical to back up all Virtual Server VMs on a given drive at the same time. If your virtual server system stores VMs on several drives, then you will need to maintain unique versions of the script for each volume that you need to back up.

strVMfolder should represent the complete folder path to the VM files. For example, on my lab system, the following folder structure is used:

The date/time naming of the folder allows the backup files to be automatically organized by the backup date and time.

The script will back up all files in the VM folders to the designated backup target folder. You could restore a VM to the time of the previous backup by copying the files in the VM's associated backup folder to their original source folder. Alternatively, you could mount a VM's virtual hard disk (VHD) file using VHD Mount in order to recover a single file.

Data Protection Manager is a great tool for backing up Virtual Server VMs and provides an excellent alternative to my scripted solution. However, if you're looking to integrate a scripted backup with your existing backup software or do not require the complete functionality of Data Protection Manager, then this script should provide just what you need.

While I wrote this script to solve a specific virtual server backup challenge, it can be used to back up any application that supports VSS. Hopefully it will help you to meet your virtual backup challenges.