Introduction

There’s currently three distinct and still-supported mechanisms for backing up virtual machines in NetWorker. These are:

• Traditional (in-guest agent)
• VADP (image level, previous generation of backup technology)
• VBA (image level, current generation of backup technology)

Each have their own advantages and disadvantages, and the purpose of this article is to outline a few of those. (In the end which direction you go for your environment will be a business decision for your own company.)

The Methods

Traditional, in-guest agent

This method currently offers the most compatibility because it leverages the traditional operating system agents in NetWorker which have been mature for years and get the job done. The pros and cons of this are:

Pros	Cons
Maximum control over backup granularity, down to the individual file level.	Each in-guest backup is unaware of other backups that may be happening on other virtual machines on the same server. Thus, the backups have the potential to actively compete for CPU, RAM, Network Bandwidth and Storage IOs. An aggressive or ill-considered approach to in-guest backup configuration can bring an entire virtual environment to its knees.
Coupled with NetWorker modules, allows for comprehensive application-consistent backups of enterprise products such as Oracle, Exchange Server, Sybase, Microsoft SQL Server, SAP, etc.	Suffers same problems as conventional per-host agent backup solutions, most notably in consideration of potential performance inhibitors such as dense filesystems. Can result in the longest backups of all options.
Very strong support for granular recovery options.	Bare Metal Recovery options are often more problematic or involved.
Least affected by changes to underlying virtual machine backup options.

VADP

This method was introduced in the NetWorker 7.x series to replace the old VCB method which we don’t speak of any more. VADP integrated with the NetWorker Storage Node functionality to offer considerably tighter virtual machine backup functionality than the previous VCB option. The pros and cons of this are:

Pros	Cons
Provides image level backup functionality for virtual machines, allowing for considerably faster backup options, unconstrained by traditional performance limitations, particularly of dense filesystems.	Only supported File Level Recovery (FLR) for Windows virtual machines.
A variety of backup connection methods, including HotAdd, NBD and SAN connect means that most environment scenarios are catered for.	Earlier versions of VADP backup did experience some issues where snapshots might not be successfully released.
A VADP proxy could support the backup of virtual machines from multiple vCenter servers.	Even for maximally configured VADP environments, a maximum of 8 virtual machine disk files could be backed up simultaneously. While this is mitigated by the speed of block level backups, it does result in higher numbers of VADP proxies being deployed in large environments.
When configured correctly, supports both file (Windows-only) and image level recovery from just the image level backup.	Not all virtual disk types are supported for backup, which can lead to a non-holistic approach.
Supports VM image level backup to tape (virtual or physical) as well as advanced file type devices and Data Domain systems.	Databases and other applications running within virtual machines (e.g., Oracle, Exchange, etc.) still require in-guest module backups, which in turn require the presence of in-guest filesystem agent software, even if it wasn't used.
	In order to facilitate FLR back into the virtual machine, the NetWorker filesystem agent still needs to be installed on the client.

VBA

Introduced in NetWorker 8.1, VBA is the new consolidated backup methodology that comes from a very tight integration between VMware and Avamar technologies. Its pros and cons are:

Pros	Cons
Provides image level backup functionality for virtual machines, allowing for considerably faster backup options, unconstrained by traditional performance limitations, particularly of dense filesystems.	Facilitation of FLR requires Flash.
Supports FLR for both Linux and Windows hosts.	Not all OS disk formats or filesystem are supported.
Deduplicated virtual machine backups can result in considerable target space savings.	[EDIT: removed, see below]
Supports both file and image level recovery from a single backup point.	Databases and other applications running within virtual machines (e.g., Oracle, Exchange, etc.) still require in-guest module backups, which in turn require the presence of in-guest filesystem agent software, even if it wasn't used.
Considerably higher backup stream counts than VADP - the VBA appliance itself supports 8 simultaneous virtual machine backups, and up to 5 VBA proxies can be deployed for a maximum stream count of 48 simultaneous virtual machine backups.	Each VBA instance can only backup virtual machines belonging to a single vCenter server. You can deploy more than one VBA per vCenter server but cumulative load limits must be manually controlled.
VBA proxy CPU and RAM requirements are considerably lower than those of the previous technology, VADP.	Password requirements for the VBA appliance root/admin account are undesirable. (Exactly 9 characters, no special characters.)
Very tight integration between vCenter and NetWorker. This allows the NetWorker administrator to define protection policies which the vCenter administrators can then apply to individual hosts.	Logging integration with NetWorker for recoveries is currently undesirable.
Ad-hoc backups as well as image level recoveries can be facilitated within the vSphere Web Client.
Virtual machine protection policies created in NetWorker are inarguably simpler and more straight forward than the process of creating policies for in-guest/traditional backups.

EDIT: Correction – I’d originally said that cloning VBA backups between Data Domains rehydrates the virtual machine. That was incorrect. Rather, due to the way in which the backups are stored, each clone operation is a clone of the full virtual machine, but only unique data between the two Data Domains is exchanged. Considerably different!

In Summary

There’s been a lot of changes to virtual machine backups over the last few years, and I believe there’ll be more to come over the next few years. The most logical scenario to me will be greater integration between image level backups and consistent database backups – the sort of scenario where you’re currently going to have to fall back to in-host backup methods outlined above.

Ultimately, the method you choose for your site will be dependent on the individual requirements at your site. For many sites though it’s likely at least two of the above methods will end up being used, at least for the foreseeable future.