Exclude VMs with a certain name pattern in all backups (e.g. to suppress Azure-Local control-plane VMs)

Challenge

With Hyper-V as well as other hypervisors getting more resonance in the last months for unspoken reasons, we faced several infrastructures running the Azure Local implementation of it.

These can easily be backed up by Veeam Backup and Replication. Just like regular Hyper-V clusters. Though, some peculiarities might arise.

One of those for us was, that some auto-generated VMs might appear with names like:

In one environment, we found >10 of those VMs in the stack.

Roles of These VMs

1. API Server - Handles all Kubernetes API requests - Acts as the main entry point for cluster management
2. etcd Database - Stores the cluster state and configuration - Highly available across multiple control-plane nodes
3. Controller Manager - Ensures desired state (e.g., deployments, replicas) matches actual state 
4. Scheduler - Decides which node runs which pod based on resource availability

Why So Many VMs?

High Availability: Control plane is usually spread across multiple VMs for redundancy.
Arc/Local Deployment: Azure Arc-enabled Kubernetes or Azure Stack HCI uses these VMs to run the managed control plane outside Azure while still integrating with Azure services.

Do we need to backup those?

These VMs are not for workloads; they are infrastructure components.
You typically should not modify or delete them - Azure manages them.
If you see names like control-plane-0, control-plane-2, etc., that indicates multiple replicas for HA.

Additionally, these names change every once in a while as the long numbers get re-generated. The only thing that stays the same ist the “-control-plan” part in it.

We therefore do not want to backup them. We would have to manually add, remove and re-add the newly generated ones to the cluster every single day.

Solution

So, we decided to setup a script that finds the VMs by a common name pattern and adds them to Veeam’s global VM exclusion list within VBR. Currently, it only works with Hyper-V, but it should be easy to adapt it to VMware if needed in another context here.

You can download the script on our GitHub.

Just adjust your mail server, name pattern and logging preferences in the first block:

# Pattern & note
$NameContains        = '-control-plan'         # for the Azure-Local control-plane VMs - replace as needed
$MinNameLength       = 21                      # "longer than 20" -> >=21 - for the control-plane VMs - change as needed
$ExclusionNotePrefix = 'Auto-excluded by script'

# SMTP settings (edit to your environment)
$EnableEmail         = $true
$SmtpServer          = 'mail.mydomain.com'
$SmtpPort            = 25
$SmtpUseSsl          = $false
$MailFrom            = 'veeam@mydomain.com'
$MailTo              = 'admins@mydomain.com'
$MailSubject         = '[VBR] Global VM Exclusions updated'
# Optional: credentials for authenticated SMTP
$SmtpCredential      = $null   # e.g. (Get-Credential) or leave $null for anonymous

# Optional: basic logging
$LogFolder           = 'C:\Logs\VBR-GlobalExclusions' # change as needed
$EnableTranscript    = $true

Step-by-Step Breakdown

1. Configuration - You define the VM name pattern (e.g., -control-plan) and minimum name length (e.g., 21 characters) - Email notification settings and logging options are set

2. Inventory Collection - The script connects to all Hyper-V sources registered in Veeam (hosts, clusters, optionally SCVMM). It checks if each source is reachable using a fast TCP probe. Only reachable sources are queried for their VM inventory, making the script resilient to outages.

3. Candidate VM Selection - From the discovered VMs, it selects those whose names: Are at least the minimum length and contain the specified pattern. This typically matches control-plane VMs from Azure Arc or Azure Local deployments.

4. Global Exclusion Management - Additions: If a matching VM is not already excluded, it’s added to the Global VM Exclusions list in Veeam. Removals: If a previously excluded VM (matching the pattern and length) no longer exists in the inventory, it’s removed from the exclusions. Safety: Removals are only performed if at least one inventory source was successfully queried, to avoid accidental removals during outages.

5. Notification - If any exclusions were added or removed, an email is sent to the configured recipients, summarizing the changes and listing any unreachable sources.

6. Logging - All actions and changes are logged to a file for auditing and troubleshooting.

We included as many error handling we could think. E.g. a non-available Hyper-V host was giving us a headache. But this is evaded now. There might of cause be more issues in your stack. Let me know.

It’s developed for and tested with V12.3. As V13 is available now, we will test it soon. For the time being most customers still run V12, so it was needed here.

Hope it helps! 😃