Designing Commvault Backup with AVS and SRM

Hi again,

I am sharing feedback from Commvault support (probably from Arlie) based on my query:

 

1. Maintaining Separate Backup Schedules and MediaAgents at Each Site

• Recommended by Commvault:
  This is the standard approach for DR scenarios. Each site operates its own MediaAgents and backup storage, ensuring that backup metadata, deduplication databases (DDBs), and indexes remain consistent and isolated.
• Failover/Failback:
  After a failover, you manually (or via automation/scripts) switch backup jobs to the DR site’s MediaAgents and storage. This avoids the risk of DDB or index corruption.
• Pros:
  • Data integrity is maintained.
  • No risk of DDB or index mismatches.
  • Supported and documented by Commvault.
• Cons:
  • Requires manual or scripted coordination for switching jobs after failover/failback.

2. Replicating MediaAgents and Backup Disks via SRM

• Not Recommended by Commvault:
  Block-level replication of MediaAgent servers and backup disks (including DDBs and indexes) via SRM is not supported.
  • DDBs and indexes are sensitive to changes in disk state and server identity. Replicating these at the block level can cause metadata mismatches, corruption, or require a full DDB resync, leading to backup failures.
  • Commvault does not support or recommend using SRM to replicate backup infrastructure components.
• Risks:
  • Backup jobs may fail after failover.
  • DDBs may require a full resync, impacting performance and data integrity.
  • Indexes may become inconsistent, affecting restore operations.

3. Automation Strategies and Best Practices

• Automation:
  If you want to minimize manual intervention, consider scripting the failover/failback process:
  • Use Commvault’s REST API or CLI to reassign backup jobs, update storage policies, and switch MediaAgent targets after failover.
  • Automate the registration of VMs and update subclient content as needed.
• Recommended Practice:
  • Deploy dedicated MediaAgents and storage at each site.
  • Do not replicate DDBs, indexes, or MediaAgent disks via SRM.
  • Use Commvault’s built-in DR and high availability features (e.g., CommServe LiveSync) for protecting the CommServe database, not for MediaAgent or DDB replication.

4. Commvault Auto Recovery

• Auto Recovery:
  Commvault Auto Recovery is designed for orchestrated DR and replication of VMs and data, with built-in failover and failback automation.
  • If you require automated DR and minimal manual intervention, Auto Recovery is the preferred solution.
  • However, you stated that Auto Recovery is not an option in your environment.
• If possible:
  Consider evaluating Auto Recovery for future deployments, as it provides robust automation and avoids the pitfalls of block-level replication of backup infrastructure.

5. Summary and Recommendation

• Do NOT use SRM to replicate MediaAgent servers, DDBs, or backup disks.
• Maintain separate backup infrastructure at each site.
  • After failover, manually or via automation, switch backup jobs to the DR site’s MediaAgents and storage.
• Automate failover/failback using Commvault APIs or CLI if needed.
• Consider Auto Recovery for future deployments if automation and seamless DR are required.

Documentation Links

• Azure VMware Solution Deployment Guide
• CommServe LiveSync for High Availability Disaster Recovery
• Auto Recovery Architecture
• IntelliSnap Protection for VMs on VSAN Datastores

I hope this will also help others in the future!

Best regards,
Nikos