Why are backup agents a problem?

[ScotH]

I am evaluating Veeam Backup and Recovery, and read about how it does not use agents.  What problem do agents introduce?  Our current backups with Backup Exec seem to run fine with them. 

[DSTAVERT]

Nothing necessarily wrong with agents and especially application (Exchange, SQL etc) aware agents are quite useful. Most new applications and you can include BE take advantage of the VMware APIs and things like change block tracking.

[idle-jam]

backup via vstorage api for data protection is like a better and newer way compared to agent. also with agent you can't schedule your backup at the same time as the backup job will maximum cpu and memory of each VM making the host to crawl.

[ScotH]

I did notice that I can't successfully run a backup job that backs up two VMs located on the same host.  There seems to be some overlap that prevents the second backup from running properly.  Anyone know if that could be agent-related?

[chriswahl]

I've used both Veeam B&R and Backup Exec. The lack of agents was something I really enjoyed, as it's one less piece of software to deploy onto the servers (along with the associated management, patching, and upgrades). It's also nice from a licensing perspective; instead of paying per agent, you pay based on the sockets of the host (which theoretically means infinite guests can be backed up).

Veeam does utilize the VMware Tools to pass along quiessence requests (via VSS), which makes transactionally consistent backups for applications like Exchange.

In my opinion, agents are generally a method of backup from the past, and with virtualization comes the need to re-evaluate the way things are done. It's much more efficient to handle backups from a host/datastore perspective, where you can leverage the resources with a wholistic approach.

[AndreTheGiant]

VM Agents have several limitation: bigger footprint (one for each VM mean a lot of MB wasted), only backup to LAN, no way to handle the vmdk backup to have a VM disaster recovery backup.

But they may handle better (in some cases) the backup or applications or the granular restore of single objects.

For example BE, also with the VMware "agent" (that is not an agent in the literal way) require the VM agent to do granular restore in place.

Andre

[ScotH]

What do mean that there is no way to handle a VMDK backup to have a VM disaster recovery backup?

[AndreTheGiant]

With an agent level backup you can backup only files or block.

But for example you cannot make a backup of VM files (like the .vmx).

For this reason I say that you cannot handle (in a simple way) a VM disaster recovery plan.

Andre

[bulletprooffool]

I personally favor agentless on nearly everything I do.

the simple reason is that we support several thousand servers, owned by about 35 different teams.

Drop any software on any host and the minute something goes wrong with one of their servers, the problem is your piece of software (until you prove otherwise)

Of course, the other reasons (performance / compatibility issues / port conflicts and so on add to the advantages of agentless)