> Expert > CommCell Recovery > CommServe Recovery > Disaster Recovery Backups

CommServe Recovery Using Disaster Recovery (DR) Backups

In the event of a disaster, when the production CommServe host becomes unusable or inaccessible, or if the CommServe host is moved to a new hardware, the latest Disaster Recovery (DR) backups can be used to rebuild the CommServe host. Once the database is restored, additional CommCell related tasks must be performed to resume the CommCell operations from the new CommServe host.

Important

Once restored, the database reflects the state of the production CommCell group when the DR backup was performed. Based on the frequency of the DR backup, you may lose some data such as information about backup operations, entity creation or configuration changes, when you move the CommCell operations to the standby CommServe host.

To restore data using DR backups, see Restoring DR Backups.

Procedure

  1. Install the CommServe software on the new host. For more information on installing the CommServe software, see CommServe Installation.

    Note

    • If possible, make sure that the computer name of the new host is same as that of the old CommServe host. For more information on how to change the computer host name on a Windows Server, see Microsoft documentation.

    • Also make sure that all the latest software updates installed on the production CommServe host are installed on the new CommServe host.

  2. A copy of the latest full and the latest differential DR backup is needed to build the standby 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.

  3. Use the CommServe Recovery Assistant Tool to restore the most recent Disaster Recovery (DR) backup from the production CommServe database to a standby or new CommServe host to resume the CommCell operations. For more information on recovering the CommServe database, see Recovering the CommServe Database Using the Recovery Assistant Tool.

    Important

    Once restored, the database reflects the state of the production CommCell group when the DR backup was performed. Based on the frequency of the DR backup, you may lose some data such as information about backup and other operations performed after the DR backup was performed, entity creation or configuration changes, when you move the CommCell operations to the standby CommServe host.

  4. Start CommCell services on the standby CommServe host. For more information on starting services, see Restarting a Service.

  5. If the new CommServe host has the same name as the old CommServe host, configure the name to point to the backups. new IP address using DNS or a similar networking service.

    Important

    Verify that all client computers point to the host name of the old CommServe computer, and not to the IP address. For instructions on changing the CommServe host name on clients, see Changing the Client Computer Name.

    Alternatively, if the new CommServe host has a different name, the clients must be informed to use the new standby CommServe host. For more information on changing the CommServe host name on clients, see Changing the CommServe Name for Clients After Restoring the Database.

    In large CommCell environments, renaming the CommServe host name on all the clients is a time consuming task. In such cases, you can avoid renaming the CommServe host name by using a dedicated proxy for disaster recovery. The proxy is used to route requests and responses between the CommServe host and the proxy-enabled clients. For instructions on configuring a proxy for disaster recovery, see CommServe LiveSync For High Availability Disaster Recovery.

  6. Resynchronize the Deduplication Databases (DDB).

    After restoring the CommServe database, any DDBs that are inconsistent with the CommServe database are put into maintenance mode automatically. Therefore, you must synchronize the inconsistent DDBs to a reusable state. For information on synchronizing the DDB, see Resynchronizing the Deduplication Database.

    The resynchronization is allowed only for DR backups that are up to 5 days older.

  7. If you have a Silo Archive job running, use the Kill option to commit the Silo job. For more information on committing the Silo job, See Committing Silo Backup Jobs by Using the Kill Option.

  8. Schedule DR backups on the new CommServe host. For more information on performing DR backups, see Performing Disaster Recovery (DR) Backups.

    Note

    In a CommCell group with File Archiver agents, if the archived file was stubbed or deleted before the last backup was included in the DR backup, then recalls that use the stub may fail after the DR restore. However, for OnePass clients, stubbing is delayed by default to ensure that the last backup is included in the DR backup.

  9. If you are performing a cross-platform restore, (Windows to Linux CommServe, or vice versa) configure the export destination for DR backups. For more information on configuring the export destination. see Configuration of the Export Destination for Disaster Recovery.

Loading...