What if I....?

[unsichtbarre]

I am managing VBR across 16 vSphere clusters and the local admin's are adding and removing VMs often without notice. This leaves me with the rather tedious task of going through each job and adding/removing VMs manually. The mandate is to protect all powered-on VMs.

When the jobs were set-up initially, the VMs were added individually. In subsequent cluster additions, I have set the entire cluster as the item to be protected and configured exclusions where appropriate.

My questions is what if I replace all of the individual VMs in each job with the cluster? Would it do a full backup on a new chain or would it continue the incremental chain from before?

Thanks,
-JB

[tm67]

As soon as a job starts, it will generate a list of all VMs that has to be processed. ("Building list of objects to process")

Since the VM itself does not change, I assume it will reuse the old chain and does not create an active full.

[petesteven]

The backup chain should be maintained if these VMs were previously included in the backup job.
If the VM was part of a different job and is subsequently backed up by a new job, a new chain begins.

Tag-based backup jobs are particularly recommended for such environments.
Tags on the VMs or tag combinations (clusters + VMs).
Then, when the VM admin deploys a new VM, they can assign the appropriate tag to it, and as soon as the VM has the tag, Veeam backs it up, since the tag is selected in the job.
Additionally, it is recommended to create a garbage collector job that backs up all VMs without tags (here, you select the cluster and exclude all Veeam tags or the Veeam tag category).
For bulk tagging of existing VMs, Falko from the Veeam Vanguard program, for example, has published a tool on his blog.

[david.domask]

It will be fine.

As Timo and Pete mentioned, when you use containers (tags, hosts, resource pools, etc), Veeam polls the hypervisor for those containers and retrieves a list of the VMs within the container.

Veeam tracks VMware workloads with equation Backup Object = Host ID + MoRef ID, where Host ID is internal identifier for the vCenter or ESXi host, depending on how you added the vSphere environment to Veeam. As long as that right-side of the equation doesn't change, Veeam will be able to match the workload to the backups regardless of whether you add the workload explicitly or through a container.

FWIW, ran a quick test on 13.0.2 starting with explicitly listing two small VMs, did full backup, then edited job to use Resource Pool as source and next run was incremental as expected. (I didn't test cluster as I didn't want to click through and exclude a few hundred VMs)

[unsichtbarre]

Thanks for the replies. Admin has rejected tagging for the time being, so I am stuck with clusters as the primary object.

-JB

[tm67]

There is a section in the documentation about this: https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13

If you change the backup scope of an existing job, for example, switch from individual VMs to a cluster, datastore or tag, Veeam Backup & Replication preserves and continues the existing backup chain for VMs that have already been processed.

[jasonede]

What about getting the admins to drop the vm's in to folders? Your backup jobs could then target the folders?
If they won't do that what about a power cli script that assigns VM's not in folders to a folder?

[tm67]

This is an option
https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13
At the Virtual Machines step of the wizard, select VMs and VM containers (hosts, clusters, folders, resource pools, VirtualApps, datastores or tags) that you want to back up:

[John.Akemann]

It would re-use the chain if the VM is still being processed by the same job.

At my organization, we default to include via a broad target object and then tag to exclude and each job is set to exclude the same general tag, we call it "No Backups - see VM note" and then the person tagging to exclude replaces the Veeam backup success line in the VM note with the reason the VM is excluded from backups.
Including the cluster works fine until the clusters get really large and you have many VM networks - Too many VMs for one job to run reliably and too many networks to test with one SureBackup job. In those scenarios I switch to including groups of related VM networks with the same exclusion policy. Usually the "Shared Services" where the domain controllers and DNS servers reside gets its own job and then other groups of related VLANs each get their own job. That way each SureBackup validation job includes the backup job with shared services in addition to the job being tested - that way core services needed for testing are always there.