Server virtualization has been a boon for many data centers. Far too many applications required a "dedicated server,"...
when all they truly needed was to think they had a dedicated server. Their CPU and I/O requirements were easily met by sharing resources with the aid of a server virtualization product. But then there was backup to consider.
While most applications could be easily virtualized, backup would "not go gentle into that good night." Virtual server backup wasn't easy. It wanted -- needed -- the full resources of both a beefy CPU and beefy storage capable of heavy throughput. It's been said that backups are a great way to test your storage and network systems because they have to move everything from point A to point B every night. Despite potential I/O issues, most users back up their virtual machines (VMs) by simply pretending they aren't virtual. They load the backup client into the virtual machine and back it up just like a standalone server.
VMware Inc. introduced VMware Consolidated Backup (VCB) to help ease the pain of virtual machine backup and to remove the I/O issues from the ESX server, but it also increased the complexity of VM backups. It required two-step backups and two-step restores for image backups, as well as the use of a separate disk-staging area. Not surprisingly, few users implemented VCB. Users of other virtual server apps, like Microsoft Corp.'s Hyper-V, also tended to back up their VMs by pretending they were physical servers.
The backup outlook is a lot brighter for both products: VMware introduced vSphere and Microsoft rolled out Hyper-V's backup architecture (which doesn't have an "official" brand name). VMware vStorage APIs for Data Protection (VADP) replaced VCB, offering everything that VCB promised and introducing the concept of block-level incremental backups. Now users can perform an image backup without having to copy the data to a staging disk first, and they can perform an incremental backup by simply having the backup application ask the vStorage APIs what blocks have changed since the last backup. The APIs promise to make things much better for those attempting to back up VMware virtual servers. The first major backup product to fully support vStorage APIs was EMC's Avamar, followed shortly by Symantec's NetBackup. As of this writing, CommVault, EMC NetWorker and IBM TSM are all working on their integration with vStorage APIs.
Microsoft Hyper-V users simply need to make sure that their backup product knows that it's talking to a Hyper-V server. Although not quite as advanced in some ways as vStorage APIs, it does a very similar job, allowing you to back up Hyper-V virtual machines without performing guest-level backup inside the virtual machine.
Hyper-V does have one advantage over VMware because it offers full Microsoft Volume Shadow Copy Service (VSS) support and VMware doesn't. Hyper-V uses VSS to quiesce its applications and notify them that the backup was successful. This allows Hyper-V users to get an application-consistent backup of any application inside a Windows VM without having to load an agent on that virtual machine. In addition, the application will know that it has been backed up and can clear its transaction logs.
VMware can quiesce applications in Windows 2003, but the actual operation it performs (VSS_COPY) doesn't notify the application that it has been backed up; therefore, you must manage the transaction logs yourself. In addition, it currently has no application support for Windows 2008. As of this writing, VMware is working on this limitation, but the company offered no comment on the timing of the roadmap. This limitation has created an opportunity for backup products to differentiate themselves and, so far, FalconStor Software, NetApp, PHD Virtual Technologies (esXpress), Symantec (BackupExec) and Veeam Software all offer workarounds to address this limitation of VMware.
This story was originally published in Storage magazine.