Skip to main content
commvault.com commvault.com
Question

Guidance Required – Promoting LiveSync DR CommServe (Azure) to Production During On-prem Decommission

  • April 7, 2026
  • 1 reply
  • 19 views
S
Novice
Forum|alt.badge.img+1

Description:

We are currently planning a transition of our Commvault environment and need guidance and best practices for our scenario.

Current Setup:

  • Primary CommServe (Production) hosted in a colo  data center
  • LiveSync DR CommServe already configured and running in Azure (Cloud)
  • Media Agents and backups are currently aligned with the colo-based production CommServe

Planned Change:

  • The colo site is being decommissioned
  • All workloads and servers are being migrated to Azure
  • The existing DR CommServe in Azure will be promoted to Production
  • Post transition, backups will be fully aligned to Azure workloads and infrastructure

Objective:

We want to:

  1. Promote the Azure DR CommServe to act as the new Production CommServe
  2. Reconfigure clients, Media Agents, and storage policies to align with Azure
  3. Safely decommission the existing colo-based CommServe

Key Questions / Clarifications Required:

  1. LiveSync Failover:
    • What is the recommended approach to promote DR CommServe to active Production?

Client Connectivity:

  • Best practice for updating client communication:
    • Any tools/scripts for bulk client updates?
  1. Database Consistency:
    • Any specific checks recommended before promoting DR?
  2. Media Agents & Storage:
    • Considerations when switching storage from colo-based to Azure-based storage
    • Any impact on existing storage policies or deduplication databases?
  3. Licensing / Configuration:
    • Any licensing or configuration implications when moving fully to Azure?
  4. Best Practices:
    • Recommended sequence of steps for this migration

1 reply

P
Vaulter
Forum|alt.badge.img+17
  • PradeepVaulter
  • Vaulter
  • April 8, 2026

Hi ​@syedameerdxc ,

The CommServe Live Sync process will handle client communication as well as communication with the respective Media Agent after the failover process.
 

Before performing a CommServe LiveSync failover, it is critical to verify several prerequisites and system health checks to ensure a smooth and successful transition. Below are the recommended checks:

1. Replication Status

  • Ensure that LiveSync replication jobs are completing successfully and the standby CommServe is up-to-date.
  • Wait for any running backup or replication jobs to complete before initiating failover.

2. Version and Patch Level

  • Confirm that Instance001 and Instance002 on both active and standby CommServe hosts are at the same update/maintenance level.

3. Communication

  • Verify that the SQL Clients (Instance002) on both production and standby CommServe hosts can communicate with each other and with the CommServe.
  • Ensure all clients in the CommCell can reach the standby CommServe host (directly or via proxy).
  • There is no additional license required after failover

    Steps to be considered for Media agents & Storage.

When switching storage from colo-based (on-premises) to Azure-based storage in Commvault, there are several important considerations regarding existing storage policies and deduplication databases (DDBs):

1. Storage Policy Impact
Primary Copy Change: If you change the primary copy of a storage policy from on-premises to Azure, ensure that all new backups are directed to the Azure library. Update the storage policy to set the Azure copy as primary and uncheck the previous on-premises copy.
Retention Settings: Retention settings must be reviewed and matched on the new Azure storage to avoid unintentional data aging or retention gaps.
No Data Movement by Default: Simply changing the primary copy does not move existing backup data from on-premises to Azure. Old data remains on the original storage unless you perform an Auxiliary Copy or similar migration.

2. Deduplication Database (DDB) Impact


DDB Association: If the new Azure storage is associated with the same DDB as the on-premises storage, deduplication savings can be maintained for new backups, as signatures are compared against existing data.
DDB Location: The DDB itself should remain on a high-performance, local disk (preferably SSD) on the MediaAgent. Do not move the DDB to Azure or any archive/cloud tier.
DDB Partitioning: If you are using horizontal scaling or multiple DDBs, ensure the correct DDB is associated with the Azure storage policy copy.
No DDB Conversion: You cannot convert a non-global DDB to a global DDB. If you need a global DDB for Azure, you must create a new one and associate it with the relevant storage policies.
 

3. Migration and Data Management


Auxiliary Copy: To migrate existing backup data to Azure, use Auxiliary Copy to copy data from the on-premises library to the Azure library.
Deduplication Savings: Deduplication savings are preserved if the same DDB is used and the data signatures match. If you create a new DDB, initial backups may not deduplicate as efficiently.
Testing: Run test backups to verify deduplication savings and performance before switching production workloads.

4. Additional Considerations


Performance: Azure storage may have different performance characteristics (latency, throughput) compared to on-premises storage. Monitor backup and restore times.

    Terms & ConditionsAccessibility statement