I encountered a situation recently I hadn’t come across before where protection policies between two availability zones weren’t placing recovery points in a logical (to me) place on the target site.
Initially this was surprising because I could not see the ‘default’ container on the target site growing in usage from the replicated recovery points – but then happened upon seeing a storage container being used by Nutanix Files growing at a huge rate.
I hadn’t seen this before, but was soon informed by reading the docs…
It would be nice if we could select the target within the protection policy configuration as we may have different requirements of the target storage container depending upon which VMs were being protected.
In a ‘normal’ setup we’d have a storage container named ClusterName_Mgmt for example so it’d never match the same on the target end so random is dangerous. Rather than risk change on the production side (where VMs were largely in the default container) I created a storage container on the remote site with the same default container as the production side. Not ideal but better than a poke in the eye.
Now, I had to figure out how to recover my 20TiB of space I’d inadvertently sent into the Files Container.
I deleted my protection policies to stop the ongoing replications from happening (400 VMs)
And fortunately, our friend nuclei on Prism Central has a vm_recovery_point action that lets us list, and delete the ones we’re interested in.
The 20240510 above reflects the dates of the recovery points being taken – as we have ‘other’ recovery points we had to be selective.
I did however notice after doing this (on a Saturday evening) that my protection policy config was to hold 48 hourly recovery points on both local and remote sites so if I’d just had a few beers and looked on Monday it’d have probably fixed itself 🙂
Live and learn 🙂