Skip to main content

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 tCommServ] on SQL server instance razur1-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 tEXEC 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

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.


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.


Reply