Agent Use on Virtual Machines

[Demi]

Hello,

I searched around for a while but couldn't find the information I was looking for. What would be the benefits of utilizing agent-based backups on a virtual machine, instead of just using a "normal" backup job? I recently took over responsibility of a veeam deployment, both vmware and hyper-v, and saw some VMS that have agent-based backups configured.

Thanks for the help!

[PetrM]

Hi Kevin,

Agent-based backup is typically used due to some host-based processing limitations on hypervisor side, for example RDM virtual disks in physical mode, independent disks on VMware or pass-through disks on Hyper-V.

Thanks!

[Demi]

Thanks! I will take a look and see if any of those exist. Appreciate the quick assistance.

[Mildur]

Another reason, application backup on Linux VMs
PostgreSQL or MySQL databases are our reason.

[Moopere]

The main reason I use agents is that the VM's move about, hosted on this host on one day and another host on a different day. I'm interested in backing up the VM, not the host, so I simply target the VM network name and don't need to care much where exactly its currently living.

[peterb]

if you have VMs which share disk for clustering purposes is another reason to go with an agent

[mcz]

Another reason, application backup on Linux VMs
PostgreSQL or MySQL databases are our reason.

@veeam-PM's: When will the MySQL-Integration (VSS) be "ported" to B&R?

[Herbert Sz]

The main reason I use agents is that the VM's move about, hosted on this host on one day and another host on a different day. I'm interested in backing up the VM, not the host, so I simply target the VM network name and don't need to care much where exactly its currently living.

Maybe I misunderstand something here, but why do you need an agent for this ?
Veeam doesn't care where the VM runs, it is just backed up, regardless on which ESX or HyperV server it's currently running.

[sps-tech]

Another reason: we have a single VM hosted by a separate entity as part of their VMWare hypervisor. Obviously we don't have privs (or need!) to back up their entire server, just our one single VM. (This is about to bite us licensing-wise when we finally upgrade to v11, as we have socket licenses...)

[Mildur]

bite us licensing-wise when we finally upgrade to v11, as we have socket licenses

Since Veeam V10, you have one complimentary license per each socket (max 6 per vbr server). If you don‘t have added the vsphere environment to the veeam server, this free gifted license can be used for the agent.

[Moopere]

Maybe I misunderstand something here, but why do you need an agent for this ?
Veeam doesn't care where the VM runs, it is just backed up, regardless on which ESX or HyperV server it's currently running.

With unlimited licenses and unlimited storage space the above would be a valid path, and one I'd take. As things are however, backing up copies of offline VM's consumes licenses and storage and I don't care about these offline VM's in any case.

The added advantage I've had to use a few times for no additional effort is the ability to restore these agent backups to hardware (as in V2P) - doesn't happen very often certainly, but when a case arises its quite convenient.

[Mildur]

With unlimited licenses and unlimited storage space the above would be a valid path, and one I'd take. As things are however, backing up copies of offline VM's consumes licenses and storage and I don't care about these offline VM's in any case.

I do not understand that. If you do vm backups, you don‘t have to backup everything.
You have the free will to choose which vms you want to backup. You don‘t have to backup each vm, online or offline.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Moopere]

@Mildur,

But why would anyone want to do it that way? Unless I'm missing something really basic:

- VM's found consume licenses unless specifically excluded
- Fiddling around with excluding VM's on individual hosts is surely powers of magnitude more time consuming than simply installing the managed agent onto a VM directly and from that point not caring about which host is running it.

I don't actually see an advantage to doing it in the recommended way (all VM's on all protected hosts) unless one were running massive VM farms and needed to back up all VM's no matter their state. I also get the advantage of being able to V2P easily which is seldom but sometimes required.

Ultimately, if one owns the VM's in question, and assuming no interoperability problems in having an additional agent service running on the VM it seems like there is no measurable downside. Backup Exec among others, has an option to not back up 'unpowered' VM's which works in the same way. The question has been asked on the forums before to include this functionality but the response, to my knowledge, has always been to run the agent.

Production VM's are always powered on and should always be backed up no matter where they are. They can be restored to a VM or to hardware as required and one can move them about in a server farm without any real thought.

If on the other hand one has more than enough licenses to cover all possibilities, and/or don't own the VM's that are being run (ie, providing a hosting platform) then sure, agentless is really the only (sane) way to do it.

[Mildur]

But why would anyone want to do it that way? Unless I'm missing something really basic:

- VM's found consume licenses unless specifically excluded
- Fiddling around with excluding VM's on individual hosts is surely powers of magnitude more time consuming than simply installing the managed agent onto a VM directly and from that point not caring about which host is running it.

You don't have to choose "everything".
Choose the one VM to backup and you don't need to exclude anything.
Never ever.

It takes 5 seconds to choose this vm. This is not time consuming.
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Moopere]

I thought I'd come back to this old thread as I recently had a site with some internal migration going on and the opportunity to do some test scenario's without interfering with production popped up.

I can see why using the Virtual Infrastructure backup type would be convenient, you install at the hypervisor level and all the VM's, or the chosen VM's from that specific hypervisor get backed up. No need to care about who owns what or how many there are. For shared infrastructure this is probably the only reasonable way to do backups.

However, the use-case I argued for in the body of this thread still seems to stand and for the site migration I was engaged with this time around I ended up going back to the agent-inside-vm model.

- There are three hosts and the VM's get moved arbitrarily between them. I don't want to have to fiddle with backups, or remember to fiddle with them, every time a VM moves
- There are Hyper-v replica's. There is no value that I can see in backing up an offline replica. Doing so just doubles the repository space required and also the backup window. Removing the replica's from the backup involves, as above, adjusting the backup job every time something changes ... the live or offline replica changing role for example.
- There are a bunch of VM's that are unimportant for DR purposes. There really is no need to waste licenses, storage or time backing these up. Whilst I realise you can exclude them, again, exclusion appears to be performed at the hypervisor level. So, 3 hypervisors, say 20 VM's (that need to be excluded), thats 60 VM's to manage and of course they are moving about between hypervisors and being deleted and added constantly. With the agent inside the VM model, you install an agent into those VM's that are critical for DR and ignore the rest.

If you could specify VM's at the VM name level, across the site, and/or exclude switched off VM's from backups (which would take care of Hyper-v replica's) then I'd probably have a different view.

[Mildur]

Hi Moopere

Thanks for your thoughts.

If you could specify VM's at the VM name level, across the site

What happens, if someone decides to give another VM the same name? What would happen to the backup chain?
Names are not optimal for tracking an object. A name can be changed by the administrator. To track an object, a unique, unchangeable value must be used.
With HyperV, we can track a vm only when you use a Cluster or SCVMM.

[Moopere]

I think it was mentioned in the main part of the thread, but for my SMB use cases having an option to not backup VM's that are turned off would probably help the scenario I'm explaining. I realise there are caveats with that model also, but there are with any direction one chooses to take.

I also understand the danger of multiple VM's with the same name - in large environments this would be a potential problem. Again, not saying we shouldn't have hypervisor level backups available, they are eminently useful for any number of use cases and certainly if backup window, license cost and repository storage is not an issue at a site then great, backup everything all the time.

I work in the SMB space though and I haven't ever been to a site in 20 years where license cost and storage limitations (for everything, not only backup) aren't a 'hard barrier' to what I might like to do, IT wise, in a perfect world.

Having said all that. During the migration I'm speaking of in the last post I have actually hit 1x Windows Server 2012R2 legacy VM and 1x SBS2011 VM that absolutely refuse to backup using the agent. Both these VM's were previously backed up with Backup Exec agents and I think this has left some residual problem inside the VM's even though those agents are uninstalled now. So ... hypervisor level backups for those ... along with the management effort that entails.

[whiteit]

Yeah we use it on our ESX servers with PCI card pass through thats been turned. veeam doesnt like it.