There are two general ways a backup application interacts with VMware Consolidated Backup. The first method only works for Windows-based virtual machines (VMs). With this method, the backup application tells VMware via the VCB interface that it wants to do a backup. VMware performs a Virtual Shadow Copy Service (VSS) snapshot on Windows virtual machines and then performs a VMware-level snapshot that's exported via VCB to the proxy server as a virtual drive letter. (The "C:" drive on the VM becomes the "H:" drive on the proxy server.) Your backup software can then perform standard full and incremental backups of that virtual drive.
The main advantage to this method is the ability to perform incremental backups. The disadvantages are that it's Windows only, there's no official support for applications (including VSS-aware apps) and no ability to recover the virtual machine itself, only the files within the virtual machine.
Alternatively, you can use the full-volume method. VMware performs VSS snapshots as before, but can also perform syncs for non-Windows VMs. However, with this method, the raw volumes the VMDKs represent are physically copied (i.e., staged) from the VMFS storage to storage on the proxy server. Although there's no I/O load on the ESX server itself, this approach places an I/O load on the VMFS storage that's the same as a full backup.
With standard backup products, this staged copy of the raw volume is then "backed up" to tape or disk before it's considered an actual backup. This means that each full backup actually has the I/O load of two full backups. And unless the backup software does a lot of extra work, there are no such things as incremental backups. That means VMware Consolidated Backup -- with a few exceptions -- creates the I/O load equivalent of two full backups every day.
Symantec Corp. and CommVault have figured out ways to do incremental backups. Symantec uses the full-volume method for the full backup and the file-level method for the incremental backup, and then uses the FlashBackup technology borrowed from Veritas NetBackup to associate the two. Symantec's method significantly reduces the I/O load on the data store by doing the incremental backup this way; however, it requires a multi-step restore of first laying down the full volume and then restoring each incremental backup against that volume. This restore method is cumbersome, to say the least. CommVault's method is to perform a block-level incremental backup against the raw volume, which is a "truer" incremental backup that offers an easier (and possibly faster) restore than Symantec's approach. However, it must be understood that CommVault's method still requires copying the entire volume from the data store to the proxy server. Therefore, their incremental backup places the equivalent of the I/O load of a full backup on the data store every day.
Restoring a virtual machine
Restoring a virtual machine also requires two steps. Your backup software restores the appropriate data to the proxy server and then uses VMware vCenter Converter to restore that to the ESX server. If the backup software supports it, it can do individual file restores by putting an agent on the virtual machine and restoring directly to it; however, restoring the entire VM must be done via the two-step method.
What about vSphere?
All of these issues contribute to the relatively limited adoption of VCB as a backup solution for VMs. While VMware said VCB has been licensed fairly extensively, my experience indicates that a good number of those license holders have yet to implement it. There's some hope for a better backup process, however, with VMware's vSphere.
VMware Inc. vSphere is the next-gen architecture that's going to add some new features and resolve some backup issues. In particular, it's going to remove the "two copies" problem with VMware Consolidated Backup (which will no longer be called VCB), and it will allow true incremental backups of the VMDK files. VMware vSphere is here and available, but it will be a while (probably six months to a year) before we see these features adopted in backup software.This article was previously published in Storage magazine.
About this author: W. Curtis Preston (a.k.a. "Mr. Backup"), Executive Editor and Independent Backup Expert, has been singularly focused on data backup and recovery for more than 15 years. From starting as a backup admin at a $35 billion dollar credit card company to being one of the most sought-after consultants, writers and speakers in this space, it's hard to find someone more focused on recovering lost data. He is the webmaster of BackupCentral.com, the author of hundreds of articles, and the books "Backup and Recovery" and "Using SANs and NAS."
This was first published in October 2009