Recovering the CommServe Database Using the Recovery Assistant Tool

You can recover your CommServe database from a disaster recovery (DR) backup to the same or a different CommServe host using the CommServe Recovery Assistant tool. The tool is primarily used in the following scenarios:

  • To rebuild a CommServe host in the event of a disaster

  • To upgrade or move the CommServe database to a new hardware

  • To restore DR Backup to rollback the CommServe server to a previous version


Before You Begin

  • Review CommServe Recovery Using DR Backups.

  • Verify that the destination CommServe host installed with the same (or higher) service pack and hotfix pack as the database that is available in the DR backup that you plan to restore.


    If the service pack and hotfix pack are not the same (or higher), services may not restart after the restore.

  • Verify that the SQL Server on the destination CommServe host is on the same or higher version and CU pack as the database that is available in the DR backup that you plan to restore.

  • Make sure that you have the latest version of the DR backup (SET_XXX folder) in the destination CommServe host.

    • If you have the DR backup files in the network location, copy the files to the local disk on the CommServe host.

    • If the latest copy of the DR backup metadata does not exist in the export location, you must retrieve the metadata from the backup media. For more information on retrieving DR backups from media, See Retrieving Disaster Recovery (DR) Backups from Media.

  • Before restoring the databases on the CommServe, manually stop the IIS service on remote Web Servers using the IISreset command. IIS service can be restarted after successfully restoring the database on the CommServe.


  1. If possible, run a full backup of the CommServe databases to ensure that no current activity is lost.

    For more information on performing DR backups, see Performing Disaster Recovery (DR) Backups.

    For more information on performing a backup without losing current activity, see Performing a No Loss Recovery of the CommServe Host.

  2. Stop services on the original production CommServe host, if it is active. For more information on stopping services, see Stopping a Service.

  3. On the destination CommServe computer, go to the <software installation path>\Base folder and then double-click CSRecoveryAssistant.exe.

    The CommServe Recovery Assistant dialog box is displayed.

  4. Click Recovery and then click Next.

  5. If you have already restored the CommServe database on this computer, select the Database already restored on this computer check box and click Next.

  6. In the Enter the path to the database dump folder box, enter or browse the name of the Disaster Recovery folder where the dump files are located, and then click Next.

    Make sure that the dump files are available on the local disk of the CommServe host.

  7. In the Enter the path to extract the database files box, type the destination path where you want to restore the CommServe database files and then click Next.

    Alternatively, click Browse and select the restore path.

    By default, all the database files are restored to the CommServe database path located on the destination CommServe host.

    The Summary screen is displayed.

  8. Review the summary and then click Start Recovery.

    The tool now performs the following operations on the CommServe system:

    • Stops the services.

    • Restores the database to the specified restore path.

    • Verifies and upgrades the database if required.

      The tool can upgrade the database from a previous version or service pack. For example, if the database available in the DR backup that you plan to restore, has an older service pack and the destination CommServe host has the most recent service pack, then the database is upgraded to the service pack available in the destination CommServe host. Hence it is important to make sure that the destination CommServe host has the same service pack, or a higher service pack, as the database available in the DR backup as stated in the Before You Begin section.

    • Synchronizes the CommServe system with the restored database.

    • Runs post operations on the CommServe computer.

  9. When all the operations are complete, click Next.

    The host name and client name of the destination CommServe host and the restored database are displayed. If the names are different, the tool updates the CommServe host with the client name of the restored database and host name of the destination CommServe host.

  10. If you are migrating the database from a non-clustered to a clustered environment, complete the following steps:

    1. Select the Convert to cluster check box.

    2. In the Physical Node text boxes type the names of the physical CommServe nodes as they appear in the Microsoft Failover Cluster Manager.

      Do not copy and paste the physical node name from the registry, or add the characters "_node" to the node name. The characters "_node" are automatically added to the physical node name during the database restore operation.

    3. Send the update status to the CommServe database by configuring the bSendUpdateStatusToCS additional setting.

      On the CommServe computer, add the bSendUpdateStatusToCS additional setting with value1. For instructions on adding the additional setting from the CommCell Console, see Adding or Modifying Additional Settings from the CommCell Console.

      Refer to the following table for applicable values:










      Select one of the following values:

      1 - to send the update status information to the CommServe database during client service restarts

      0 - to disable the update status sync

  11. If you are migrating the database from a clustered to a non-clustered environment, select the Convert to non-cluster check box and click Next.

    A completion message is displayed.

  12. Click Finish.


After the DR restore, you will notice a considerable increase in the job ID for new jobs. This increase is added to avoid conflicts with job IDs referenced in the deduplication databases (DDBs) when the DDBs are resynchronized.

What To Do Next