Ok, so I have had a detailed chat with TAC and reviewing some of their documentation, I wanted to provide further clarity around why issues crop up when we use multiple subclients for the same VM.
Core Issue with Multiple Subclients for the Same VM
The real problem isn’t snapshots clashing or running at the same time — Commvault can handle that fine with staggering schedules. The actual issue is with how the backup chain gets tracked across subclients.
Here’s what happens behind the scenes:
- VMware CBT tracks changed blocks on a VM’s disk since the last snapshot.
- Commvault queries the CBT data during each backup job to identify what blocks need to be saved and writes that data to the index.
- The CommVault index tracks a continuous chain of backups (fulls and incrementals) for each VM.
Now, if you’re running two subclients (e.g., Subclient A and Subclient B) for the same VM, but with different storage policies and retention periods, things get messy.
Here’s what I confirmed with Commvault TAC:
- Subclient A runs an incremental backup, and the change block details (CBD) are saved to the index.
- Then Subclient B runs its backup, and Commvault treats the VM as a single entity, meaning the index gets updated again with the latest backup job from Subclient B.
- If Subclient B has a shorter retention policy (say 2 days), and it deletes those incrementals, critical blocks that were part of the restore chain for Subclient A could be lost.
In simple terms:
Even if both subclients look like they’ve completed their jobs, the index won’t have a complete chain for restores. This can cause:
- Restore failures because the backup chain is incomplete.
- Test failover issues, like the one we experienced where the VM booted into BIOS instead of spinning up correctly.
Makes sense??
