A question came across my desk a few days ago around being able to automatically back up VMs that have been migrated by vCenter Site Recovery Manager (SRM). After a bit of thought, it seems this is fairly simple to solve. With SRM, I migrate VMs to a resource pool at my recovery site. Why you might ask? This resource pool is configured with shares set to “High”. This has no impact during normal operations, but when I migrate or fail over important workloads, I want to be sure these workloads have priority if there is contention for CPU and memory. However, this also creates a secondary benefit when it comes to backing up migrated VMs…
Many backup solutions include the ability to select vCenter Server “containers” such as a data center, cluster, or a resource pool for backup. In my lab, I use VMware vSphere Data Protection (VDP), which has this capability. I created a backup job in VDP and selected my SRM resource pool as the item that will be backed up. By virtue of doing that, any VMs that are in that resource pool when a backup job starts will be backed up.
At this point, I had not migrated any VMs using SRM. The backup job started at its scheduled time, but there were errors. This was no surprise since there were no VMs in the resource pool at the recovery site.
In SRM, I verified the resource mapping was set up properly so that any VMs in the protected site cluster would be migrated to the SRM resource pool at the recovery site.
Seeing that everything was in order, I migrated the VMs from the protected site to the recovery site using SRM (with vSphere Replication). After the migration was complete, I ran the VDP backup job that protects the SRM resource pool. The VMs in the resource pool were backed up.
One thing to be aware of is that VMs replicated by vSphere Replication with multiple point in time (MPIT) recovery enabled will be recovered with VM snapshots – one snapshot for each recovery point. This may cause issues when attempting to back up these VMs.
This is of course resolved by consolidating the snapshots – something that should be done right after recovery anyway as it is not a good practice to leave snapshots in place for an extended period of time.
I suspect there are other ways to accomplish this, but I at least wanted to document one possible approach to get the wheels turning.
At this point, I had not migrated any VMs using SRM. The backup job started at its scheduled time, but there were errors. This was no surprise since there were no VMs in the resource pool at the recovery site.
This is of course resolved by consolidating the snapshots – something that should be done right after recovery anyway as it is not a good practice to leave snapshots in place for an extended period of time.
