No Problem in vRanger Pro 4.5 with the VMware CBT Defect

Concerned about the CBT problem in VMware, and the implications for vRanger Pro 4.5 which includes CBT support? No need to be. vRanger Pro is implemented to avoid the problem.

vRanger Pro 4.5 avoids problems with the edge conditions described in the article. If vRanger Pro finds that a snapshot is open for a given VMDK working with vStorage API, then vRanger Pro performs a full backup. This avoids the problem of potentially having a VMDK revert to an earlier point in time after the backup is taken -- a condition which would invalidate CBT-based incremental backups. With vRanger Pro, the full is taken instead. Once all open snapshots are closed, a new full is taken and all subsequent backups can still be incrementals or differentials. All of the backup copies, including all subsequent incrementals, are coherent, recoverable and usable.

Here are the log messages in vRanger Pro 4.5 which report on this condition:

With open snap shot

[2010-05-20 15:13:08.954]: Skipping change block because virtual machine has a snapshot.

Without open snap shot

[2010-05-20 15:17:41.298]: Using filter type(s) change block.

It's of interest to note that this functionality is not new in vRanger Pro with its CBT implementation. vRanger Pro has always taken a full backup in the event that the VMDK had a snapshot open.

In the way that VMware implements its snapshot, it opens a new file for each point-in-time snapshot created for the VMDK. These files continue to get created for each snapshot, with a total of up to 32 snapshot files for each VMDK. By taking a full, vRanger Pro captures everything to ensure all points-in-time of recovery for that VMDK.

I describe the CBT problem as an edge condition, because in practice most administrators don't revert back to an earlier point in time after doing a backup. However, this can occur -- and is even likely to occur at least once in a while in dev or test environments. In case it's more likely to occur in your environment, you may want to keep reading to learn how our new Active Block Mapping (ABM) makes the full efficient.

How Vizioncore ABM Makes the Full Efficient

As it turns out, ABM helps solve a little-known problem for image-based backup. This is a problem which goes mostly unnoticed, simply because not that many people know how the image-based backup process actually works.

The fact is that the capabilities out there which purport to remove white space or empty blocks still must read and process those blocks which contain zeros. This makes the process of creating a full backup longer and less efficient than it needs to be.

This secret doesn't matter much in terms of transmitting and storing the image after it has been read, because compression processing removes the zeros which reduce to almost nothing. But, for the full read process, the difference here matters a lot.

vStorage API allows unallocated blocks to be identified, but does nothing to find and remove blocks populated with zeros from the list of those to be read. ABM is the only known technology which removes these zero blocks from the read and avoids the need to process them.

Why waste time reading and processing say, 100GB of zeros, for a full backup when you don't have to?

ABM removes empty blocks from the read list for a full, to speed the backup process and reduce the I/O and CPU impact on the underlying server system.