Skip to main content
Question

Issues Restoring CommServe Database on a New Host (v11.28)

  • January 17, 2025
  • 3 replies
  • 153 views

Forum|alt.badge.img+3

Hello everyone,

I am currently facing challenges while attempting to restore the CommServe database on a new host following the Disaster Recovery procedures outlined in Commvault's documentation. Below are the details of my setup, the steps I followed, and the errors encountered during the process.

Context:

  • Commvault Version: 11.28
  • Operating System: Windows Server 2012 R2
  • Source Server: Original CommServe is no longer functional.
  • Target Server: New host configured to take over as the production CommServe. 
  • Target Operation Systeme : Windows Server 2019
  • SQL Instance: azur1-mybackupservertarget\Commvault
  • DR Backup Files Path: D:\Migration Commvault lab\DR\SET_14395

I am using the CSRecoveryAssistant.exe tool in "Recovery" mode to restore the database. While most steps appear to complete successfully, I encounter critical errors during post-recovery operations that prevent the restoration from finalizing.

Steps Followed:

  1. Configured the new server as the production CommServe.
  2. Stopped all Commvault services before initiating the recovery.
  3. Specified the DR backup file location (*.dmp) in CSRecoveryAssistant.exe.
  4. Successfully restored all databases (e.g., AppStudioDBCacheDBCommServCVCloud, etc.).
  5. Successfully upgraded databases using DatabaseUpgrade.exe.
  6. Performed synchronization of configurations between CommServe and restored databases.

Errors Encountered:

  1. SQL Authentication Issues:

    Error: Failed to connect to database [CommServ] on SQL server instance [azur1-mybackupservertarget\Commvault]
    Error: Login failed for user 'sqladmin_cv'.
    
  2. Invalid SQL Access Key:

    Error: Invalid SQL access key
    System.NullReferenceException: Object reference not set to an instance of an object.
    
  3. Failed SQL Query Execution:

    Error: There was an exception running the sql query [EXEC UpdateSQLLoginCredentials ...]
    
  4. CommServe GUID Retrieval Failure:

    Error: Failed to fetch CommServe GUID from database
    
  5. Software Cache Synchronization Issues:

    Error: SoftwareCache user is not set. Object reference not set to an instance of an object.
    

Actions Taken So Far:

  1. Verified that the SQL user sqladmin_cv has the necessary permissions (sysadmin) on the SQL instance.
  2. Attempted manual login to SQL Server Management Studio (SSMS) using sqladmin_cv, but it fails with a login error.
  3. Confirmed that, per Commvault documentation, the default administrator password for CommServe should be reset to admin. However, this does not seem to resolve the issue.
  4. Restarted all Commvault services and re-ran CSRecoveryAssistant.exe, but errors persist.

Questions for the Community:

  1. How can I reset or regenerate the SQL Access Key (SQLCredentialsForCSDB) that appears to be invalid or corrupted?
  2. Is there a manual way to update or synchronize SQL credentials used by Commvault?
  3. How can I resolve issues related to fetching or replacing the CommServe GUID in the database?
  4. Are there any additional steps required after restoring a Disaster Recovery backup on a new host?

Thank you in advance for your assistance! Any guidance or suggestions would be greatly appreciated.

Best regards,

Andry
Admin TI

3 replies

Forum|alt.badge.img+11
  • Vaulter
  • 235 replies
  • January 20, 2025

Hi ​@Andry97 
 

We appreciate the detailed analysis and the information shared. All the above errors are caused by the SQLadmin_cv and SQLexec_cv user credentials not being in sync between the application and the database.

We recommend logging a support case to get assistance with decrypting the credentials. Once the registry value is decrypted, the password can be updated in SQL Server Management Studio (SSMS). After this, re-run the DR restore process, which should resolve the reported errors.


Forum|alt.badge.img+3
  • Author
  • Byte
  • 6 replies
  • February 7, 2025

Hello,

After following the documentation for migrating CommVault to a Hardware Refresh and receiving help from CommVault support for decrypting and encrypting the password of “sqladmin_cv” and the other user, we unfortunately arrive at the same result. An error message mentioning the same errors. See screenshot.

I'd like to raise a question. We're currently migrating our lab environment from an On-Premise virtual machine to a new Windows Server 2029 virtual machine in the Azure cloud. Is it normal that restoring the DR on another machine with the same version of CommVault v11.28 is so complex, despite the fact that we have strictly followed the migration procedure here? We're waiting to hear back from CommVault customer service. They've done a great job getting us to the point where we can restore the DR using CSRecoveryAssistant. But we have a failure at the last step “Performing post recovery/staging operation”.

Could you tell us if other users have had a similar experience when restoring the Disaster Recovery file on a new machine equipped with a recent installation of the same CommVault version?

Thank you in advance for your help.


Forum|alt.badge.img+5

 Is it normal that restoring the DR on another machine with the same version of CommVault v11.28 is so complex?

Absolutely not - We have a cloud failover commcell that I livesync my DR too every hour. At any point I can bring down my PROD CS and be up in less than a minute with a working commcell that is in Azure and has access to my Azure aux copied data.

I also do CommVault service pack testing on a completely separate Azure buildout that i bring online. I install an evaluation version of CommVault, recover my DB using the tool or sometimes I'll just recover using SQL if I'm testing multiple patch levels. I consider this essentially a PROD site down test as well. We have a 4 hour SLA to meet our ‘restore ready’ requirement. Meaning I have to build a server, get it online, install CV, configure the storage etc. Recovering the database MAY take 10min at the most….


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings