As I teased in Using vCenter tags with PowerCLI, I want to explore how to use tags  in a practical application. To refresh our memory, we looked at creating an Ownership category with individual tags in it, and limited VMs to having just one of the tags. We created a little script that defines our schema, in case we need to re-create it. We are going to work on a new category today for our backups. Specifically, Veeam backups, based on SDDC6282-SPO, Using vSphere tags for advanced policy-driven data protection as presented at VMworld 2015.

Defining Policy and Tags

To create our backup jobs, we need to know a few things that will translate into our tag schema. Our backup policies are defined by a combination of ownership, recovery point objective (RPO), and the retention period. For example, our Development group is okay with a 24 hour RPO and backups that are retained for a week. Operations may require a 4 or 8 hour RPO and require 30 days of backups. Each of those combinations will require a separate backup job. We can combine these tuples of information into individual tags so that Veeam can make use of them. We also need one more tag for VMs that do not need any backup at all. We can put all of this in a tag category called VeeamPolicy. Here’s what that might look like, again in PowerShell:

New-TagCategory -Name VeeamPolicy -Description "Veeam Backup Policy" -Cardinality Single -EntityType VirtualMachine
New-Tag -Name "NoRPO" -Category VeeamPolicy -Description "This VM has no backups"
New-Tag -Name "Development24h7d" -Category VeeamPolicy -Description "Development VMs with 24 hour RPO, 7 days retention"
New-Tag -Name "Operations8h30d" -Category VeeamPolicy -Description "Operations VM with 8 hour RPO, 30 day retention"
New-Tag -Name "Sales48h30d" -Category VeeamPolicy -Description "Sales VM with 48 hour RPO, 30 day retention"

This creates the category for the VeeamPolicy tags, a single tag for VMs that explicitly do NOT require backups, and three group/RPO/retention tuples. Go ahead and place this in revision control, so that over time, you can track the tags you are using. Tags are part of vCenter, so if you migrate to another or recreate your vCenter, you’ll need this! It also makes it easy to see what you’ve defined vs what’s actually in vCenter.

Next, we want to tag some VMs. There’s a number of ways this can be done, depending on how your VMs are organized. If we assume a simple VM and Templates folder structure where VMs are grouped by the owning organization (Development, Operations, Sales, Marketing, etc), we can tag all the VMs with NoRPO, then tag VMs in the relevant folders with the relevant tag. That would look like this:

# Default policy is NoPRO
Get-VM | % {
  New-TagAssignment -Entity $_ -Tag "NoRPO"
}

# Find Development VMs by Location
@(Get-VM -Location "Development") +
@(Get-Template -Location "Development") | % {
  Remove-TagAssignment -TagAssignment (Get-TagAssignment -Entity $_ -Category VeeamPolicy) -Confirm:$false
  New-TagAssignment -Entity $_ -Tag Development24h7d
}

It’s important to look for VMs and templates. The @() structure creates arrays, which can be added together. We then have to remove the previous assignment before placing the new one, since our category is Single cardinality (Unfortunately you cannot overwrite the current tag assignment, boo!).

Note: The Location parameter takes a string, and it finds ALL folders that match the string. If you have a VM and Templates folder named Operations and a Datastore folder called Operations, All the VMs in BOTH will be discovered. I recommend adding ” DS” to the end of datastore folders, ” VDS” or ” VSS” to the end of Network folders, etc., to ensure there’s no conflict here.

You could also look for VMs by datastore folders:

# Find Development VMs by Datastore Location
$DevelopmentDatastores = Get-Datastore -Location "Development Datastores"
@(Get-Template -Datastore $DevelopmentDatastores) +
@(Get-VM -Datastore $DevelopmentDatastores) | % {
  Remove-TagAssignment -TagAssignment (Get-TagAssignment -Entity $_ -Category VeeamPolicy) -Confirm:$false
  New-TagAssignment -Entity $_ -Tag Development24h7d
}

You may also have a more complicated layout for groups, such as Operations, where you do not want all the VMs underneath a top level folder to receive the same tag. We can instead combine some individual folders underneath and list some VMs in them that we want to be left as NoRPO by adding some selection criteria and skip the individual VMs:

# Find Operations VMs
$OperationsExemptVMs = 'veeamproxy1', 'veeamproxy2'
@(Get-VM -Location "Domain Controllers", "Management", "vSphere", "Templates for patching", "Veeam") +
@(Get-Template | ? { (Get-TagAssignment -Entity $_) -eq $null } ) | % {
  # Skip these VMs which will not be backed up
  if ( $OperationsExemptVMs -contains $_.Name.ToString() ) {
    return
  }

  Remove-TagAssignment -TagAssignment (Get-TagAssignment -Entity $_ -Category VeeamPolicy) -Confirm:$false
  New-TagAssignment -Entity $_ -Tag Operations24h30d
}

There’s a ton of other ways to select your VMs, this is just a sampling. If your organization could best be described as “Chaotic”, then you might have to assign Tags individually. However your tagging happens, when you’re done, you probably want a report so you can ensure everything was tagged properly. We can do that, too!

# Report on the current tag status
@(Get-VM) + @(Get-Template) | Get-TagAssignment -Category VeeamPolicy | Select Entity, Tag | Export-CSV -Path $env:USERPROFILE\Downloads\Tags.csv -NoTypeInformation

Open the resulting CSV file and we’ll have all our VMs and Templates and the Tag they were assigned. Print it out, red pen it, and tweak our categorizations. You can re-run the Find GROUP VMs sections, or if you want to start over, just delete the tag category and run the whole file again:

Remove-TagCategory VeeamPolicy

Tweak it till you get it right, and commit it to version control again. One last set of statements you may want to use is to find non-tagged VMs, either as part of your script (if you do not assign everything NoRPO) or on an intermittent basis to ensure every VM and Template is tagged:

@(Get-VM) + @(Get-Template) | ? { (Get-TagAssignment -Category "VeeamPolicy" -Entity $_) -eq $null }

Creating Veeam Backup Jobs

Now that we have our policy defined and tags applied, let’s create some jobs. We will be creating three jobs, one each for Development, Operations, and Sales. We will assume that automatic proxy selection will work and that there is only one repository, as those details aren’t important to the use of tags. This article was written using Veeam Backup & Replication v9, so if you’re reading this in the future, things may look different!

One last thing to note, and you may have figured this out already, is that when using Tags for our selection process, it’s an OR operation, not an AND operation. This means that if you select two tags, Veeam will find all VMs that match either tag, rather than VMs that much all the tags. That’s why we have three pieces of information in our tag! There’s a request to support logical AND – please comment in that thread if you think you’d find this interesting as well! If this is delivered in the future, it could really change how this is done!

Create a new backup job for Development:

On the next page, click Add, then click on the right-most icon (Tags) and expand and select the Development24h7d tag and hit Add then Next.

On the storage page, change the Retention Policy 7 days. This is also where we can hit Advanced and modify Quiesce settings, Notifications, and most other backup settings. Click Next when done.

Make any selections we need to on the Guest Processing screen (not shown) and click Next. Now set up our schedule (not shown). Since this is a 24h RPO, this should run at least once a day (more is okay, if we’d like). Click Create to finish the job setup. We should end up with something like this:

Now, every day at 10:00:00PM, the Development job runs. Veeam will contact the vCenter server and enumerate every VM with the Development24h7d tag, add them to the job, and then start backing them up. If the Development team deletes a VM, it’s automatically no longer part of the job. If they add a VM, and they tag it properly, it’s automatically part of the job. All we need to do is teach or coworkers how to tag their new VMs, hopefully with the assistance of automation, and use our PowerShell command from above to run a report every days to find any untagged VMs. It’s okay to tag a VM with NoRPO, because it’s explicit acknowledgement that a VM does not require backups, but the lack of a tag does not mean that backups are not needed.

We can also use combine the use of tags with exclusions. For example, if we have some “close” VMs and some “remote” VMs on a slower link, they probably do not use the same repository at HQ. In the “close” job, we exclude the remote site’s clusters or datastores, and on the “remote” job, we exclude HQ’s clusters or datastores. If we have two or three sites, this is probably pretty easy. If we have multiple sites, we may want to revisit our tag scheme and add a fourth item to the tags – Location – and re-align our jobs. Of course, if the “AND” selection criteria is added in the future, this will change, as individual tags won’t need to carry EVERY piece of information.

Summary

Today, we created a tag schema oriented around our backup policies. We also built some reports showing how VMs are tagged and which VMs are not tagged. This script was commited to version control for accurate tracking over time and re-creation of the schema if needed. We then created some simple but dynamic Veeam backup jobs based on the tags, and showed our coworkers how to leverage the tags. This is a great start for simplifying your Veeam backup jobs and to see the practical power of vCenter Tags. There’s a lot more you can do with Tags, and with your Veeam jobs. I’d love to hear how you’re using Tags in the real world in the comments or on twitter. Thanks!