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.
