Tags are a great way to manage and organise resources across a vSphere environment, with tags we can sort and group VMs together based on any criteria we wish. Veeam can even leverage these “groups of VMs” in many different ways.
For example, Veeam Disaster Recovery Orchestrator leverages tags for orchestration plans and to make sure VMs are restored to the right place with tag-based recovery locations.
Veeam ONE Business View can automatically create and assign tags to VMs based on any desired criteria with its categorization engine, this is on top of VeeamONEs capability to run reports based on tags. I’ve previously written about Veeam ONE Business View which can be found here.
Veeam Backup & Replication (VBR) also can utilise tags for any job. By simply adding tags as the source object to the job, VBR will protect any VMs with that same tag, this can be especially time-saving if VMs are frequently being provisioned. Another benefit of tags is that, unlike folders and resource pools, VMs can be assigned multiple tags.
Let’s take a look at how we could group a selection of 8 VMs into various different backup jobs using tags.
By grouping VMs in gold, silver and bronze tags, we can easily add each tag to a backup job that has been created to meet the needs of each tag. The beauty is, that we could have any number of VMs with our ‘DC1-Gold’ tag and they would be automatically protected by Veeam. The question becomes how should we handle VMs that have slightly different requirements within the same tag.
Application-aware processing or guest OS indexing comes to mind in this scenario, perhaps the file servers in the ‘DC-Silver’ tag require guest OS indexing and the domain controller requires application-aware processing. Now both of these requirements could be handled by defining inclusions and exclusions within the job. By doing so, we can minimise the total number of jobs and tags required while still ensuring each workload is protected according to its particular needs but this approach does erode some of the ‘set and forget’ benefits of tagging and doesn’t scale typically well. The best approach here is to leverage tags to differentiate guest OS indexing and application-aware processing within that same job.
The challenge arises when we consider that some settings simply can’t be customised per VM within a job. For example, proxy selection, storage level corruption guard, encryption and storage integration, these settings apply to all objects within the same job. This necessitates separating VMs into their own jobs configured for those particular requirements. This often means we need to group VMs into more and more tags which can be cumbersome given the high number of job permutations possible, this is especially evident in large and complex environments. Another consideration is the naming convention required to ensure each tag name is unique yet descriptive enough for administrators to understand what purpose the tag serves.
Prior to v11, the recommended approach for tagging in large and complex environments would be to follow the 80/20 rule. Where tags handle at least 80% of VMs with similar requirements enabling them to be easily added to a backup job, while the remaining 20% of VMs with more unique requirements are simply managed manually at the VM object level in jobs. This approach can help avoid tag sprawl in large complex environments.
Now with Veeam Backup & Replication v11, in addition to specifying multiple individual vSphere Tags as a job scope, we can use a combination of vSphere Tags — in which case only VMs with every selected tag assigned will be processed (AND operator behaviour).
This simple feature greatly reduces the total number of unique tags required to be created in complex environments since we can now rely on generic tags to identify which VMs should be protected and which VMs shouldn’t be.
For instance, if we added all four of the above tags as a ‘tag combination’ to a job, only the VM tagged with all four tags will be protected, that being ‘VM-sql31’. If a VM is missing any of the four tags, it will not be protected. So while this won’t necessarily reduce the number of backup jobs required, it can reduce the number of tags required in large and complex environments.
When using this approach, take greater care monitoring unprotected VMs, for example with Veeam ONE — as such setup makes it much easier to unintentionally lose VMs from the protection scope and end up with no recent backups for them.
For additional reading I recommend checking out the following;