Recovery Using SQL Server Database Mirroring: Building the Standby CommServe Host

To enable CommServe disaster recovery using SQL Server database mirroring, you need to first build and configure database mirroring on the standby CommServe host.

In a database mirroring setup, CommCell services do not run at the same time on both the production CommServe host and standby CommServe host. If services are running on both, mirroring will be interrupted and the two CommServe databases try to communicate with the clients simultaneously.

Before selecting a database mirroring mode review the following:

Mode Requires Comments
High Safety with Automatic Failover (synchronous)
  • A witness server
  • Dual IP license
The witness server instance can run on the same computer as the principal or mirror server instance, but this substantially reduces the robustness of automatic failover.
High Safety without Automatic Failover (synchronous)
  • Manual force of service with possible data loss on the standby CommServe host if the production CommServe host fails.
  • Dual IP license
Database will be consistent with the last committed transaction.
High performance (asynchronous)
  • Manual force of service with possible data loss on the standby CommServe host if the production CommServe host fails.
  • Dual IP license
  • Mirror database lags a small gap behind the principal database.
  • Mirroring has minimal impact on the production CommServe performance.

You can obtain the dual IP license from your software provider.

High-Level Process Flow

The process flow for building the standby CommServe host involves the following tasks in the order list:

  1. Install the CommServe software on the production and standby CommServe host. See Install CommServe.

    You can also use an existing production CommServe host for the configuration.

    Apply the dual IP license on the production CommServe database. See Applying a License.

  2. Install latest software updates on the CommServe hosts.

    Make sure all the latest software updates that are installed on the production CommServe host are installed on the standby CommServe host. See Installing Updates on the Standby CommServe Host.

  3. Disable the disaster recovery backup job schedules on the production and standby CommServe host. See Enabling or Disabling a Job Schedule.
  4. Configure an administrative user account to run SQL (CommVault) service on the production and standby CommServe host. Consult Microsoft manual for instructions.
  5. Stop SnapProtect services on the standby CommServe host. See Stopping a Service.
  6. Replicate the CommServe database and configure mirroring using the SQL Management Studio software. Consult Microsoft manual to perform the following tasks:
    1. Set the production CommServe database to Full Recovery mode.

      By default, a database in SQL Server is set to Simple Recovery Mode. In this mode, records of transaction log are kept as long as transactions are running. You must backup and restore all the transaction logs on the production CommServe. Therefore, set the CommServe database to Full Recovery mode to get full record of the transaction logs.

    2. Backup the production CommServe database.
    3. Backup the transaction logs of the production CommServe database.
    4. Copy the backup dump file(s) to the standby CommServe host using a physical media or a network drive that is accessible from both the servers.
    5. Restore the production CommServe database and transaction logs in NORECOVERY state to the standby CommServe host.
    6. Configure database mirroring on the production CommServe host.
    7. Schedule transaction log backups of the production CommServe database.

      To prevent database log growth, we recommend you to schedule transaction log backups of the production CommServe database every 15 minutes to an hour or more, depending on the frequency of activities on the CommServe.

      As an alternative, you can install the Microsoft SQL Server iDataAgent on the production and standby CommServe hosts, and schedule transaction log backups with truncation.

    Similarly, replicate other existing CommServe hosted databases (WFEngine, DM2, CvCloud) using the same procedure.

  7. Enable the disaster recovery backup job schedule on the production CommServe host.
  8. Disable auto start services for the standby CommServe host. From the Process Manager window, clear the Auto-start services when OS starts checkbox.

Related Topics

Standby CommServe Host Preparations

CommServe Recovery Using SQL Server Database Mirroring