There’s no doubt that I’ve been a big fan of Veeam Backup and Replication.  For the most part in my day job this has been a set and forget type of application that just works (and even through the use of SureBackup it let’s me know that it works!).  That said, there are times when my jobs will fail.  Usually due to causes such as vCenter disconnecting or other environmental concerns.  When this happens, a lot of times I find that Veeam will have hot added a replica disk to the proxy in order to do it’s thing, yet since the disruption it hasn’t removed it.  This will cause all subsequent backups to fail, normally with errors around opening vddk disks and/or invalid snapshot configurations. 

Easy way – just remove them – but where are they?

waldo No problem right – just right-click on our proxy VM and remove those stray replica disks – that’ll fix it.  This seems like an easy fix for maybe a couple of replica disks on a couple of Veeam proxies…but what if you are using Veeam at scale?  We by no means are huge when it comes to Veeam but honestly, even with 6 Veeam proxies and 200 VMs it can get a little hectic and almost feel like you are playing a game of Where’s Waldo when you are trying to determine which proxy has hot-added which failed replica.  And I find it monotonous with 6, for those larger the Where’s Waldo book could be a few hundred pages πŸ™‚

Enter PowerCLI Man!!!

PowerCLI-Man_HeadshotNow before I get into explaining how to do this with PowerCLI we need to go over a few assumptions.  A few things that I’m assuming about the environment that Veeam is installed in.

  1. You have used a standard naming convention for your VMs that contains at least a few characters that can uniquely identify your Veeam VMs from the ones you are backing up.
  2. You haven’t done any crazy with adding existing disks or renaming them at all.  Meaning you don’t have a VM called VM1 with a mounted disk called VM2.vmdk.  All disks attached to your proxies are consistent in their naming as the VM is.
  3. Veeam isn’t running any current jobs.  If Veeam is running this little command might just unmount a disk that Veeam is currently trying to replicate/backup.  Not good – so be sure your jobs are all stopped.

Phew!  Now that’s out of the way let’s have a look at a one-liner that will accomplish the task of removing all foreign disks from our Veeam proxies – essentially, this will mimic the person that has selfishly flipped through the book and circled all of the Waldos πŸ™‚

Get-VM | Where-Object {$_.Name –like “*VBR*”} | Get-HardDisk | Where-Object {$_.Filename –notlike “*VBR*”} | Remove-HardDisk

There you are, you can see the line will first grab all VMs that contain the string ‘VBR’ – a unique string inside of all my Veeam proxies.  Then, it retrieves all the disks mounted to those VMs that do not contain the ‘VBR’ string, meaning they are foreign or from my replicas.  It then, simply removes them – with a prompt πŸ™‚  To remove the prompt just add a –confirm:$false right at the end of the line.

With that let’s call this post done.  Although not a very technical post this is a simple one-liner that has saved me a ton of time over the years.  It also has given me a good excuse to post some pictures of Waldo and complain about that third-grader that always seemed to get those library books before me and circle Waldo on EVERY PAGE!  Thanks for the challenge Billy!!!!