3rd Party VADP Backup selection criteria
As a Backup Administrator, I try to look for ways to more efficiently manage my time and resources, as well as automating what I can. In our environment we have 3 big name backup solutions that we support due to various reasons, and many of our clients use dedicated backup agents on the boxes.
VMware based backups that were done used manual VM selection criteria due to various reasons. To me, this seemed a bit wasteful. When my VMware Admin approached me informing me of a plan to migrate some hosts and upgrade VMware I figured this was a good time to approach the idea of automating the VM selection method.
We sat down and looked at our 3 backup software solutions to find what we could use. Names, Tags, Datastores, Folders. As we looked we realized that while all our solutions supported VADP to some extent, some support some methods, some would have to be upgraded to support methods and some wouldn't support other methods. As a spoiler, Tags, while nice, was the least supported method both for versions and backup solution selection methods.
After studying what we had, discussing who's responsible for what, as well as capabilities it came down to two choices in the end: Manual selection with the backup team responsible for managing everything, or VM Folders where the VMware Team managed the backup selection via VM Placement.
We opted to go with VMware VMs and Templates folders as it would be the cleanest with the least amount of unnecessary management. It also provided the VMware Admins a simple method to see what would be backed up (a common question) as well as was supported by all of our backup solutions. It also provided the benefit of being portable. Folder structure could be exported and imported to new vCenters, greatly simplifying upgrades and vCenter migrations.
Our query was based on the following criteria:
vDataCenter + Backup Solution Folder + Not powered off + does not contain "restore"
We used this criteria so that in case a folder was created with the wrong solution in a remote datacenter we didn't attempt to back it up over WAN, the machine wasn't off (common for decom prep) and does not contain "restore" in the name so that we didn't backup anything that may have been orphaned due to testing or other processes.
This has greatly simplified our methods and we had an unexpected benefit. Recently there was an issue where hosts had to be migrated from one vCenter to another quickly. Using this method, our VMware Admins simply added the Backup Service Account, imported the folder structure, and cleaned up the old data on the previous vCenter. All I had to do was add the new vCenter to my backup solution. Time to migrate backups, approximately 15min. This process would have required many hours using the previous method, and Tags are not as easily transfered from one vCenter to another (need powershell or some migration tools).
Hope this helps in your Admining tasks
Charles
@whitehattechs
VMware based backups that were done used manual VM selection criteria due to various reasons. To me, this seemed a bit wasteful. When my VMware Admin approached me informing me of a plan to migrate some hosts and upgrade VMware I figured this was a good time to approach the idea of automating the VM selection method.
We sat down and looked at our 3 backup software solutions to find what we could use. Names, Tags, Datastores, Folders. As we looked we realized that while all our solutions supported VADP to some extent, some support some methods, some would have to be upgraded to support methods and some wouldn't support other methods. As a spoiler, Tags, while nice, was the least supported method both for versions and backup solution selection methods.
After studying what we had, discussing who's responsible for what, as well as capabilities it came down to two choices in the end: Manual selection with the backup team responsible for managing everything, or VM Folders where the VMware Team managed the backup selection via VM Placement.
We opted to go with VMware VMs and Templates folders as it would be the cleanest with the least amount of unnecessary management. It also provided the VMware Admins a simple method to see what would be backed up (a common question) as well as was supported by all of our backup solutions. It also provided the benefit of being portable. Folder structure could be exported and imported to new vCenters, greatly simplifying upgrades and vCenter migrations.
Our query was based on the following criteria:
vDataCenter + Backup Solution Folder + Not powered off + does not contain "restore"
We used this criteria so that in case a folder was created with the wrong solution in a remote datacenter we didn't attempt to back it up over WAN, the machine wasn't off (common for decom prep) and does not contain "restore" in the name so that we didn't backup anything that may have been orphaned due to testing or other processes.
This has greatly simplified our methods and we had an unexpected benefit. Recently there was an issue where hosts had to be migrated from one vCenter to another quickly. Using this method, our VMware Admins simply added the Backup Service Account, imported the folder structure, and cleaned up the old data on the previous vCenter. All I had to do was add the new vCenter to my backup solution. Time to migrate backups, approximately 15min. This process would have required many hours using the previous method, and Tags are not as easily transfered from one vCenter to another (need powershell or some migration tools).
Hope this helps in your Admining tasks
Charles
@whitehattechs
Comments
Post a Comment