I'm hoping i'm wrong here, but my understanding is:
Veeam Availability for Nutanix appliance required for each cluster. Each appliance is unaware of the other and act independently.
This is presenting some issues for me in terms of management.
As a VM moves from one cluster to another:
The VM will have to be removed from the job on Appliance 1 and added to Appliance 2
As it has come from a different appliance, it will be stored as a new instance in the repository.
- Two separate backup chains for the one VM
- Two locations to look in (depending on which cluster the VM was running on which date
Using the built in Nutanix "Protection Domains" features.
As required. We intend to use this to balance loads between the clusters and also use it to troubleshoot / isolate parts of the network.
Yes, currently the only thing holding us back from achieving this is the backup solution. Having the two clusters backed up independently means manual intervention & re-work every time a VM is moved. Also means each VM that moves has 2 seperate backup chains.
Another option is to use Veeam Agents for now in lieu of the AHV-integrated solution. With instance licensing you should be able to use either method without having to purchase different Veeam solutions or swap license files. This would allow a VM to be backed up regardless of it moving around from one cluster to another.
Hello,
what exactly to you mean if you use protection groups? Usually they are quite handy with hundreds of physical systems so they should also be fine for VMs.
This is something we will likely be looking at too and perhaps also AHV metro-availability if/when that arrives.
Is the ability to determine vm cluster location and therefore backup placement going to be on the road map for Veeam AHV?
What level of protection could we expect in future i.e. if vm is originally at site A with on-site and off-site backup at site A and B respectively and vm restarts on site B then the on-site and off-site backups will need to swap around?
The use of agents would not be an option really for us and seems to be a bit of a backwards step from utilising the AOS snapshots which I believe could be used?
This is something we monitor with Nutanix. There are several different possible use cases
a) DR
b) workload migration (not really a use case AHV does today)
And related questions to what are the capabilities for CBT as workloads migrate across different clusters.
As mentioned by Hannes, today you can define backup jobs via PDs, but this alone does not address the requests.
Hello all!
i would like to reopen this subjects. Last post was 8 years ago and Veeam backup for AHV evolved in the meantime, however i fear this particular point is still the same, am i right?
Right now we are planning to migrate production VMs between an old cluster to an new one (under same Prism Central). For this we will use dataprotection and protection policy features on Nutanix side (like a DR plan).
Is there still no other way but to recreate a new Veeam Backup for AHV appliance and all the jobs associated to VM migrated throught DR, creating new chains?
just to make sure lol!
@Sam31Tls we have good news and bad news. The bad news is that yes this is still the case. When a VM is relocated to a new cluster by whatever means it is allocated a new VM ID which means new backup chain. The good news is that we haven't given up pursuing a solution and have had an ongoing conversation with Nutanix on this topic over time. In fact we did discuss this very recently with them again and they have a couple proposed means by which we might be able to track VM lifecycle and support backup continuity. Nothing that we can put a timeline on yet but both parties recognize a more elegant solution is needed.
