Search Backup Central
Twitter Updates
Disclaimer
The opinions contained within this website, it's blog(s), forums, and Wikis, are those of the original poster and do not represent the position of my (or any other) employer.
|
|
Why are the major backup products slow to fully support vSphere? |
|
|
|
|
Written by W. Curtis Preston
|
|
Friday, 04 September 2009 |
Reading announcements from companies like EMC, Symantec, CommVault, and CA, you'd think they were in the forefront of "proper" support for EMC's vSphere. When you read things like "NetBackup & Backup Exec certified for vSphere 4.0," you would think that means that it supports vSphere's new backup features. You would be incorrect on both counts, and the same is true for EMC, CommVault, CA, and (oddly enough) VizionCore!
The problem with backing up VMware has always been I/O. You can back up the VMs as if they were PMs, and you'll run into the laws of physics pretty quickly -- although this is what something like 90% of people do. It limites many people's use of VMware by limiting the number of VMs they can put in one ESX server.
Along came VCB, which I think stands for Very Complicated Backup. It attempted to solve the problem by installing a physical proxy server that could see the ESX server's storage, and having the proxy server move the data. Although there were two modes, the proper mode that allows for recovery of files AND the VM (what I call the image method) requires copying the entire VMDK file to the proxy server, and then copying it to your backup system. It also requires a two-step copy during restores as well. Some products would use the image method for the full, and then use the virtual copy method (which isn't a two-step copy process) for the incremental. That's not too bad. But some vendors actually copy and/or read the entire VMDK file every night to figure out which blocks have changed. That's the I/O equivalent of a full every night! Now that's what I call bad design.
Enter vSphere and its change-block-tracking API. (VCB is officially gone, although the framework is still there for now for legacy apps.) Backup applications that fully support vSphere can ask VMware what blocks have changed for a given VMDK and copy just those blocks. There's no need to read the whole file to figure that out; just ask VMware. (For the Oracle folks among us, this is exactly equivalent to what Oracle did with RMAN in 10g. Prior to 10g, doing an incremental was actually worse than doing the full because of all the I/O going on to figure out which blocks had changed!) And the new vSphere API doesn't require a two-step backup or a two-step restore!
Sounds great, right? But guess what? None of the "biggies" (EMC, Symantec, CA, CommVault, Vizioncore) are actually using all of the new API. When they say they support vSphere, what they're usually saying is that they support it the way they supported ESX 3.5, which was usually VCB. They all say that full support is "coming soon," usually "next quarter." But I think it's important to point out who actually supports it now.
I can find only four products that support vSphere's new backup API.
- VMware's VMware Data Recovery
- PHDVIrtual's ESXpress
- Veeam Backup & Replication
If you want full VMware vSphere support, with incremental backups that don't take forever, and one-step backups and restores, these are the products to look at today. I'm not saying the other products are garbage. (In fact, I hear a lot of good things about other areas of those other products. But in this area they are behind -- and I think this area is really important.)
Update: CA's ARCserve supports the single step backup and restore, but they do not support the change-block tracking feature.
I'm just surprised. Aren't these companies partners? Don't they get the software early? Can't they see the value of supporting new stuff as soon as it comes out? Why is it only the lesser-known products are the ones stepping out front here?
|
|
|
