To make it short : is it possible to migrate a VM backup chain between two jobs related to two different Prism Central?
The target repository is the same for both job but we have space constraints and would like to avoid having two backup chains for the same VMs for the retention time.
Let us elaborate now!
Site 1 :
- Prism Central 1
- Cluster 1 (AHV 6.5)
- 2 Strorages container :
- Cluster 1 VM prod
- Cluster 2 VM DRP
Site 2 :
- Prism Central 2
- Cluster 2 (AHV 6.
- 2 Storage containers :
- Cluster 2 VM prod
- Cluster 1 VM DRP
Right now all VMS are running on Cluster 1 but are separated on the storage containers depending on there final target situation.
Veeam setup (12.1):
- 2 Prism central deployement added
- PC cluster 1 with backup jobs already set (categories used) running since a few weeks, currently protecting all VMs
- PC cluster 2 with backup jobs already set (categories used) but still hosting no VMs yet.
The plan is to make a planned failover of all vms residing on Cluster 1 ("Cluster 2 VM DRP" storage container) to start those VMs on Cluster 1 ("Cluster 2 VM prod" storage container).
We have few spare space on the backup repository and would like to avoid to remake backup chains from scratch (having twice the data volume used for weeks).
On vsphere moving vm between vcenters would change the vm id; moving a vm from one backup to another between vsphere in this context would have no meaning.
But how is it on Nutanix?
Can i even move a vm between jobs related to 2 different Prism central?
If i were to do so after the planned failover of the VM would the existing backup chain would be resumed or would another one be created?
NB : in parallel we should add the job related category to the VM on Cluster 2.
Sorry for the lengh of the post and thank you in advance!
. Unfortunately in this case the VM ID behavior is similar to VMware in that a new ID is created for the VM in a failover scenario which precipitates a new backup chain. Similarly if the VM is failed back to the original location its ID is changed yet again which of course creates another new full and backup chain. We are definitely aware of the issues here and intend to address it but it will be a longer term effort.