Has Commvault addressed how to handle backups for VM’s that have been failed over Via SRM to a Recovery site?
I know Commvault has livesync and that may be 1. answer but if the business wants to standardize on SRM someone needs to address backups at the DR site.
+9
Hey Scott,
SRM VMs are VMs that have snapshot operation disbaled on them so there is no way to backup them. They are stubbed VMs.
Could u please give more context as what is the configuration and what is needed?
Ali
+23
When the VMs failover, then the VMDKs become visible and we can protect those VMs, before then as Ali stated, the VM disks are invisible to the VM and to us. The clumsy way to protect them automatically is to create a separate subclient and allow the job to run every night. It will fail, but when the failover occurs it will succeed. You can disable the subclient from SLA to avoid it impacting your reporting - but its not the best solution.
Since SRM is all about recovery automation, the proper solution would be to have SRM enable the schedule to backup the failover site as part of its recovery plan. You could script this using our command line tools. Here are some examples on how to enable/disable a schedule:
+3
Thank you both, the other fun part to this is having to deal with multiple backup histories for these machines. 1 set in the source VCenter and 1 set in the destination. Not a huge issue other than commvault handing out a new license for the destination copy of that machine?
Thanks,
Scott.
+23
I can’t remember if the replica VM is a different UUID…. I think it may be which is why it is seen as a different VM. License workaround could be to disable the subclient rather than disable schedule. I believe is the subclient is disabled then the VMs protected within it are excluded from license counts.
+18
See this new feature available in 11.25:
Excluding VMware Placeholder VMs From Backups
https://documentation.commvault.com/11.25/essential/143781_excluding_vmware_placeholder_vms_from_backups.html
“You can exclude placeholder VMs that are created by the VMware Site Recovery Manager (SRM) from backups.”
Thanks,
Scott
+3
I was just saying Ideally there would be a way to tie the 2 same name clients together so there was one backup history independent of what site its at. Again thanks for the help all!
+23
You received some solid answers from some CV legends!
+1
This thread is a bit old but here is hoping I could get some details: we can configure SRM to maintain UUID after a failover to the Secondary site (secondary vCentre), so the licensing issue seems fine. We also use DELL EMC Power MAX storage with SRDF Metro replication to keep the sites in sync, so from a VMware perspective, both sites ‘see’ the same disk IDs. Additionally, the secondary site holds AUX copies of all backups from the Primary site. We backup VM snapshot images (so Agent-less). My question is about finding a way to configure Commvault to recognize the AUX copies as Primary, AND, more importantly, continue to leverage the same CBT info from the Primary site. This should be possible given SRDF Metro maintains bit level duplication of all disks/blocks.
Without CBT continuation across sites, after failing 500-ish VMs over to the Secondary site, we’re looking at at full re-seeding of all VMs - so tens of TB of data that needs to be read from PMAX. Not only this will take days to complete (breaking our RPO), it will also severely impact runtime performance for the Production environment (due to high IOps inflicted on storage by Commvault reads).
Any ideas we could try would be much appreciated. Thank you
Hello @Adrian M.,
I hope you are doing well. I am reaching out to you from the engineering team.
Could you please let me know a good time to discuss this issue?
You can also reach me via email at asancheti@commvault.com.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
