VMware Consolidated Backup (VCB) was one of the most anticipated features of VMware Virtual Infrastructure 3 (VI3). VCB provides image-level backup of virtual machines (VMs) and file-level backups of Windows VMs by hooking into existing backup solutions like Veritas BackupExec.
But the scripts that Veritas BackupExec uses to interact with VCB lack some key functionality. In this article, we'll review some changes you can make to these stock scripts that will render the scripts more flexible and more useful for your backup needs – giving you the ability to have usernames and passwords with spaces in them, to easily select multiple VMs for backup and to prevent a single VM backup failure from ruining the entire backup job.
For many others and myself, VCB was a huge letdown when we finally got our hands on it. VCB was marketed as a one-stop shop for virtual machine backups. But what it turned out to be was a framework that could be utilized by various, existing backup solutions to back up virtual machines.
Although VCB may not be what we were expecting, what it is is not necessarily a bad thing. The VCB framework has two parts -- the backend technology used to directly access virtual machines on a SAN and the scripts used by the existing backup solutions. These scripts could use some improvement.
Because the scripts are written in the ever-so-common and useful language of JavaScript, they are easy to modify. VMware provides a basic script framework, but it leaves a lot to the specific backup software vendors; hence, one script that I am reviewing is not generic and is only useful with Veritas BackupExec.
The first change allows for spaces in the username and password used to back up VMs. The script is called glue.js and it is located in %ProgramFiles%\VMware\VMware Consolidated Backup Framework\generic. This script is exactly what the name implies -- it contains useful functions that help glue the VCB scripts together.
The m...
To continue reading for free, register below or login
To read more you must become a member of SearchVMware.com
odification is around line 39:
As you can see, I have edited the script so that quotes are placed properly around the username and password. This particular section of code returns a string of text that will be executed in a shell, and if the username or password has a space, the command and the script will fail.
In the next change, we will implement the ability to select multiple VMs for backup. The stock Veritas BackupExec scripts do not allow for more than VM to be backed up easily, per the documentation included with the scripts at %ProgramFiles%\VMware\VMware Consolidated Backup Framework\backupexec\README-backupexec.html. What you will end up with is an unreadable command if you try to string more than one VM backup together.
In our next script, veritas.js, I aim to fix that. As you might imagine, this is the script that Veritas designed to be used with BackupExec. This script is located in %ProgramFiles%\VMware\VMware Consolidated Backup Framework\backupexec.
We will be paying attention to a function called GetVMFromArgs. Because I have made so many modifications to this function, I will include it in its entirety.
With the changes we have implemented, it will be easier to back up multiple VMs. For example, suppose we want to perform full backups on vm01.foo.com, vm02.foo.com and vm03.foo.com. With the stock scripts, we would have to write a back up command similar to:
Wow, that is long. After modifying the above function, we can rewrite this command as:
Ahhh, much better.
We still need to edit two other parts of veritas.js, or an individual VM that fails to back up properly will still cause the entire backup job to fail.
The first function we need to look at is DoPreJobCommand. This is the function that Veritas BackupExec calls prior to backing up data -- it quiesces running VMs and takes snapshots of them onto the backup proxy. We need to edit that function so that it will continue gracefully if a VM backup fails:
We also need to comment out a section of code in the DoPostJobCommand function so that, if there is a problem with removing a single VM snapshot after the backup job completes, the entire post job command won't fail.
After you upload those files to your VCB proxy, your VCB backups will be much easier to manage.
If you are having trouble with VCB scripts, you can always run them manually from the command line. The debug output gets logged to a file in your user's temp directory, usually at c:\documents and settings\%USERNAME%\Local Settings\Temp, in a file named like "pre_ESX-FullVMs92200673315.log" or "post_ESX-FullVMs92200673315.log". Replace the numbers with your own timestamp, obviously. When BackupExec runs the scripts, the logs are most likely in the temp directory inside of the Windows directory.
Andrew Kutz is deeply embedded in the dark, dangerous world of virtualization. Andrew is an avid fan of .NET, open source, Terminal Services, coding and comics. He is a Microsoft Certified Solutions Developer (MCSD), a SANS/GIAC Certified Windows Security Administrator (GCWN, and a VMware Certified Professional (VCP) in VI3. Andrew graduated from the University of Texas at Austin with a BA in Ancient History and Classical Civilization and currently lives in Austin with his wife Mandy and their two puppies, Lucy and CJ.
