Why would you install VCB right now?

VMware Consolidated Backup (VCB) was a first attempt by VMware to address the backup challenges of backing up VMs.  However, it has significant limitations and has already been replaced by VMware.  If you’re already using it, fine.  But why would you move to it NOW?

VCB is short for VMware Consolidated Backup and the idea behind it was simple.  Solve the I/O problem of VM backup by moving the I/O out of the ESX server and into a proxy server that can see the ESX’s server’s storage.  However, a number of things happened along the way.

  1. If you perform the image-level backup (the only method that can be used to fully recover a VM), you have to copy the entire VMDK file from the ESX server’s storage to the proxy server’s staging disk every time — and then you have to copy it from the staging disk to your backup system.  That’s a two-step backup every time.
  2. If you perform an image-level restore, it has to be restored to the VCB proxy and then imported into the ESX server.  That’s a two step restore.
  3. If you try to perform an incremental backup of the image-level backup then you have to copy the entire VMDK from the ESX server to the staging disk and then do your incremental backup from there.

I ask in every TechTarget Backup & Dedupe School how many people have implemented VCB, and usually about 5% of the VMware users raise their hands.  Then I ask how many of them say it solved the problem they wanted it to solve, and very few of them ever raise their hands.

The good news is that VMware has acknowledged this and completely re-architected the backup infrastructure for vSphere.  VCB is still there, but only as a legacy way for backup software products that use VCB to connect to vSphere. But it is no longer how you backup vSphere. The new method does not have the limitations mentioned above.

But here’s the bad news.  None — and I mean none — of the usual suspects (NBU, NW, TSM, CV, AS, DP, etc.) have ported to the new backup API in vSphere yet. Only the point products (ESXpress & Veeam) have actually ported to it.  The bigger companies will be coming out with their versions in several months.

So here’s my question: Why would you bother installing VCB right now if you’re going to have to uninstall it and replace it in a few months?  I don’t think you should.  And I think you need to call your backup software representative every week and ask him or her when they’re going to fully port to vSphere’s backup API. Limp along until then as best as you can — or you can look at one of the point products that already fully support vSphere.

Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at Sullivan Strickler, which helps companies manage their legacy data

5 comments
  • Curtis,

    Sounds like VCB was solving a problem that no one needed to be solved, or that caused more problems than it fixed. With the nearly non-existent pickup rate for VCB, looks like the “big boys” are taking their time with supporting the new vSphere APIs.

    The third question you need to ask is “Will you use the new API in vSphere?” That’s the one the Backup Software Vendors will actually care about.

  • It is definitely a real challenge for many people. The more you’ve done VMware, the more of a challenge this is. But VCB definitely caused as many problems as it solved.

  • May I ask how everyone else is backing up virtual machine images? Is the other 95% using vranger pro, some other 3rd party app, or is everyone loading clients on their vm’s and backing them up the old fashioned way over the lan? Is everyone backing up the whole machine or just doing file level backups? I tried using vcb and I’m through with it.

    Thanks,

    Pat

  • Most people pretend they’re in the Matrix and put backup client software in their VMs. It’s not optimal but it works for many folks. I’d say 10% or so are doing Vranger, Veeam, or ESXpress.

  • Our shop still pretends we’re in the Matrix. We use TSM and each VM node gets a TSM client installed. This approach standardizes backup and recovery procedures and doesn’t present any performance issues.

    The newer hardware provides more horsepower and more vm nodes than we want to risk on one server. In fact, we moved away from large servers that can support 100 or more medium duty VMs to blade servers simply to reduce the impact of host failure.

    The 5570 dual socket quad core blades hum along at idle with 50 nodes. In addition to other heavy duty blade servers we have three VM hosts in each chassis (150 nodes) and still do not have performance issues.

    This approach combined with VMotion and SAN replication provides bullet proof business continuity.