Skip to main content
commvault.com commvault.com

Hello Commvault Community,

 

We had a scenario where one of the (properly) backed up VMs was migrated to another DataCenter using the Zerto tool, then migrated again to the original DataCenter and stopped working properly.
 

The VM named XYZ has been moved from the production DataCenter2 (ABC2) to the second (failover/backup) DataCenter1 (ABC1).
 

The Zerto tool was used for this type of switching. The machine disappears from DC2 and appears in DC1 - the backup should be done, because we have everything prepared on the tags (Tags are configured at the subclient level), and the Zerto tool transfers all  tags.
 

In both DCs we have separate MediaAgents (DDBs, Indexes on them) and other repositories (other arrays)
 

The problem is that the virtual machine cXYZ] in DC1 during about a week of stay did not perform a backup according to the schedule until it had Full configured (started according to schedule).
 

Like we switched the VM again from DC1 to DC2 - same problem. Backup according to schedule was not performed until Full was scheduled. Incremental does not execute.
 

According to the correct process of Commvault systems, should there be any conversion of Incremental to Full backup - or does it always have to be invoked manually?
 

When the vm went back to the original DC2 there was a problem starting the backup where we saw the error:
 

"Failed to get the index information from previous backup"
 

In the logs I found information that there should be a conversion to Full, but it was not automatically triggered, and only manual Full helped.

 

Thanks,
Kamil

 

The software does not automatically convert to a full backup upon indexing failure - there are scenarios where it will automatically will, but not this one. Is it possible to allow the Media Agents and Virtual Server Agents in both DC’s to communicate with each other freely?

This way the index for the previous backups can flow between. If not, there is likely a setting that allows conversion to full upon this type of indexing failure - but you’d have to open a support case and check with them and see if there is another workaround.

 

@wgrande may have an opinion on this

Hi,

Thanks @Damian Andre for your help.

 

What should be done in this case to maintain backup continuity and not lose any data?

Because we will have a similar situation when switching the SAP HANA database between nodes that are located in different DataCenters.

Currently, we have that during the switch, we manually change the node in the commvault environment, but we do not change the storage polices. So the backup goes crosswise, not to the same DC.

 

Thanks,
Kamil

If the VM was discovered within an Incremental backup of a subclient (VM Group), and a Full was required, it should have been actioned automatically… but as Damian stated just because there was an indexing error doesn't mean it will require a Full. However, anytime you transition between Storage Polices, I would always perform a Full because there is now a dependency across multiple storage devices for recovery.

  • The problem is that the virtual machine nXYZ] in DC1 during about a week of stay did not perform a backup according to the schedule until it had Full configured (started according to schedule).

If you don’t mind the extra load on the Commserve, you can always set it as the proxy between MAs on DC1 and DC2… This would avoid any indexing communication restrictions when IndexeDBs/ActionLogs need to be shared between components. I say through the CS as it wouldn’t require Environmental Firewall changes to see if this helps your site-to-site issues around Indexing.

Hello @wgrande 
 

Thanks for suggestions from you.
 

You mean to add CommServe module as one Access Node in VMware instance properties for vCenter pseudoclient configuration? Or maybe in another place?

 

Thanks,
Kamil

The suggestion wouldn’t be to add the Commserve to the Access Node list, but to place a Network Topology between the two sites. You’d want to add DC1’s MAs into a network gateway setup, with the Commserve as the proxy, and to open communication to the DC2 MAs.  (DC1 MAs <=> Commserve <=> DC2 MAs). This permits the MAs to communicate through the Commserve, if needed, compared to requiring a direct connection to each out to be able to pull over an Index or Index files. This is to simply avoid having direct channels opened over the networks, as the CS already has connectivity to both networks.

Reply


Terms & ConditionsCookie settings