In Part 1 of my series on demystifying VMware data protection, I discussed the three primary methods by which one can backup and restore VMware Virtual Infrastructure
- A local backup agent within each virtual machine (VM)
- A backup agent in ESX Service Console
- VMware Consolidated Backup (VCB-Proxy)
In Part 2, I'm going to elaborate on the how the following data backup and restore applications approach VMware backup and restore:
- IBM Corp. Tivoli Storage Manager (TSM)
- EMC Corp. NetWorker
- CommVault Galaxy
- Symantec Corp. Veritas NetBackup
- Vizioncore Inc. vRanger Pro
Except for vRanger Pro, all of these backup and restore applications support backups of VMs using methods 1 and 2: a local backup agent within each VM, and backups of virtual machine disk format (VMDK) files through the ESX Service Console using standard Red Hat Enterprise Linux agents.
However, integration with VMware's Consolidated Backup (VCB) feature varies between backup and restore applications. Some utilize VMware's free VCB Integration Modules, while others have developed their own integration with enhanced capabilities.
IBM TSM: Non-VCB backups
Versions of TSM 5.3 and up can undertake traditional VMware backups without VCB. Method 1 is to run a TSM Backup/Archive Client from within the individual machines itself; and Method 2 is to run the TSM Backup/Archive Client on Linux within the ESX Server and backup VMDK files. However, with method 2, note that the same disadvantages I outlined in part 1 still apply.
TSM 5.4 VCB integration
With TSM 5.4, the VCB integration offered is pretty basic. It requires the installation of VMware's free VCB Integration Module. Data restoration is centered on the VCB-Proxy, which means that the node name characteristics of the backup will be that of VCB-Proxy rather than the VM's actual node name. And lastly, some manual scripting might be required in order to provide file-level backups.
TSM 5.5 VCB integration
VCB integration is more seamless with TSM 5.5. No manual scripting is required for file-level backups and it no longer relies on the free integration module from VMware. The most substantial and welcome change is that the backup node name is no longer associated with the VCB-Proxy. This allows for direct restores to the originating VM using the VM's node name. The administrator is removed from the fact that the backup was performed from a VCB backup host and the VM's backup data can be managed as if it had been backed up by a TSM client running inside the VM.
EMC NetWorker 7.x: Non-VCB backups
There's very little mystery around NetWorker's VMware backup/restore capability. Standard agent-based backups within VMs is supported as is backup of VMDK files through the ESX console using a Red Hat Enterprise Linux agent.
Of note, NetWorker has also recently added data deduplication capability. I won't delve into this capability at this time because it doesn't change the method by which the backups are obtained other than backing up a significantly reduced amount of data by weeding out duplicate segments.
VCB Proxy file- and image-level backups are supported. It requires the NetWorker Client and the freely available VCB Integration Module from VMware. The process is the standard VCB process as described in my last article, and restore is the same as well, requiring either a backup agent within the VM or a two-step restore by utilizing a temporary location that acts the restore location until the files can be moved manually.
If both file- and image-level backups are required, then two backup jobs are required, one for the file-level backup and one for the image-level backup.
CommVault Galaxy 7.x: Non-VCB backups
CommVault Galaxy's non-VCB backups behave pretty much like EMC NetWorker's backups. Standard agent-based backups within VMs is supported as is the backup of VMDK files through the ESX console using a Red Hat Enterprise Linux agent.
Also like NetWorker, VCB-Proxy file- and image-level backups are both supported with backups and restores following the same standard process. However, the similarity ends here, because Galaxy has its own custom VMware Integration Module and doesn't rely on VMware's free downloadable module. Galaxy has a special Proxy iDataAgent that installs onto the VCB Proxy, which also requires its SAN Media Agent to be installed on the VCB Proxy.
Symantec Veritas NetBackup 6.x: Non-VCB backups
Following suit with TSM, NetWorker and Galaxy, Veritas NetBackup doesn't break any new ground with its non-VCB backups. Like the other products, standard agent-based backups within VMs is supported as is backup of VMDK files through the ESX console using a Red Hat Enterprise Linux agent.
Veritas NetBackup 6.5 VCB integration
The only VCB Proxy capability that Veritas NetBackup 6.5.0 has is to undertake file-level backups of VMs. Because this can't be complemented with an image-level backup capability, NetBackup 6.5.0 currently doesn't capture the following:
- VMware system files
- Windows System State
- Windows system files (C:\WINDOWS\system or C:\WINDOWS\system32)
- Windows system database files (such as RSM Database and Terminal Services Database)
However, Symantec has rectified this with a far more compelling VCB integration capability with Veritas NetBackup 6.5.1.
Veritas NetBackup 6.5.1 VCB integration
This is the where Veritas NetBackup really differentiates itself from the other products. Now bear in mind that, as of this writing, the capability I'm about to describe has just barely been released by Symantec.
How NetBackup 6.5.1 undertakes VCB Proxy-based backups is different in that it allows the ability to restore at the image level and the file level from one image-level backup. For all other products, this is only possible by using two backup jobs, one for an image-level backup and another to backup at the file level. In summary, Symantec NetBackup 6.5.1 is promising the capability to:
- Back up all files and folders
- Back up Windows operating system files
- Back up VMware system files
- Support a restore of the entire VM and of the guest OS
- Support individual file restore from full VM backup (VMware Granular Recovery)
How Symantec accomplishes this is through the use of its FlashBackup Technology. Essentially, the backup is a VCB Proxy image-level backup, however, rather than simply backing up the exported image files, Veritas NetBackup uses FlashBackup to map the VM image. Both OS-level files as well as image file are cataloged during the backup process. This is what provides NetBackup 6.5.1 the ability to obtain file-level detail as well as the entire VM image-level detail from one backup pass.
This is a very promising and exciting feature to be sure, but be aware that it's new. So if you have a problem being an early adopter, consider waiting for more widespread adoption before redesigning your VMware backups around this feature.
Vizioncore vRanger Pro
vRanger Pro is largely a full VM image-level backup/restore application. When it backs up it does so to a disk-based Ranger Archive. The product can do full and block-level differential (non-VCB) backup/restore on VM image files, all of which is automatically scheduled through a policy-based backup/restore GUI.
Amongst myself and my colleagues, there's some debate on whether vRanger should be considered a full outright backup/restore application or simply a restore utility. Rather than take sides, I choose to simply indicate the fact that vRanger does allow for backup and restore of VMware VMs, which qualifies enough for me to discuss this product's capabilities in the context of VMware data protection.
The other thing with vRanger is that it has some unique features that are custom-tailored toward VMware backup and restore. So, to truly understand it requires some more detail than I will provide. The most I'd say is that vRanger complements these other backup/restore applications. Rarely do I encounter vRanger all by its lonesome and doing the job of a more holistic backup/restore application.
Non-VCB backups vRanger doesn't do backups from within VMs. In other words, it doesn't have a backup agent that resides within the VM. For non-VCB backups, it's a backup/restore application that's deployed as an agentless ESX console-level backup.
How it's able to be agentless is though communication directly with the ESX Console API that is also used by VirtualCenter. Here are the steps it undertakes for a backup and restore.
- The vRanger Pro Server communicates with VirtualCenter Server to initiate the backup job.
- vRanger Pro then creates a snapshot of the desired VM.
- The VM snapshot is exported, sent over the LAN and optionally compressed on the fly to the desired disk destination, which is known as the vRanger Archive.
- After the backup, the VM is taken out of snapshot mode.
- In the event of a restore, the image can be restored directly to the VMFS and a specific VMDK location, decompressing on the fly. No ESX console agent is required.
- The newly restored VM is then registered with VirtualCenter and available for use.
Note that Virtual Center, vRanger Pro and vRanger Disk Archive can reside on the same physical server if desired.
vRanger's VCB backup capabilities are implemented via a plug-in. It doesn't require the free VCB Integration Module from VMware. Its own VCB plug-in provides the necessary functionality that VMware's Integration Module provides, plus the following:
- vRanger Pro calls the VCB Framework to snapshot and export the VM to the VCB-Proxy.
- However, rather than saving the exported image onto disk as is the usual behavior, vRanger's VCB plug-in intercepts the exported image using vRanger's I/O Intercept Engine and is redirected to the disk-based destination. The data stream is optionally compressed on the fly.
- Once the backup is complete, vRanger Pro calls the VCB Framework to take the VM out of snapshot mode.
- In the event of restoration, the image can be restored directly to the VMFS and a specific VMDK location, decompressing on the fly. No ESX console agent is required.
The advantages here is that vRanger does all the heavy lifting to get a VM back into an fully operational and bootable state without requiring any temporary space in the process. One important note, however, is that vRanger Pro currently can not do block-level incremental backups of VCB-Proxy based backups.
As I stated earlier, vRanger Pro is largely an image-level backup/restore application. However, it can also do file-level restore in a pinch. vRanger Pro's file-level restore capability is enabled via a plug-in freely available for download from VizionCore's Web site. It works by uncompressing a backed-up image within the Ranger Archive (if compression was selected during backup), mounting the image and making files available for a copy operation via its own Ranger File Explorer or Windows Explorer. This is why vRanger Pro is usually a complementary product to an already existing backup/restore application rather than a replacement for it. Trying to do file-level recovery of this nature on a frequent basis is simply not realistic.
Next up: Data replication for VMware
Up to this point, the methods and applications I've presented have really been focused around restoration of local files or VMs. In the event of large-scale ESX server(s) failure or data center disaster events, local restore capabilities, especially those utilizing tape, are simply insufficient if application recovery time and recovery point objectives are on the order of minutes to hours (which is typical of mission-critical applications).
Such stringent recovery objectives require a more real-time way of protecting data. Data replication is one approach that provides the ability for certain applications to move from the realm of restore (the copying back of data) and into the realm of recovery (access to an alternate copy).
In my next article, I'll explore some data replication technologies that can be employed as data protection mechanisms for VMware and provide more immediate recovery capabilities for applications residing with VMware VMs.
About the author: Ashley D'Costa architects and designs advanced computer solutions and has technical experience with a broad spectrum of IT infrastructures.
This was first published in May 2008