> Essential > Big Data > MongoDB > Restores

Restoring a MongoDB Cluster to a Different Cluster (Out of Place)

There are two types of out of place restores:

  • You can restore an entire MongoDB cluster to a different cluster:

    • Before launching the restore operation, you must perform the Discover operation on the destination cluster.

    • The data is restored to all the clients in each replica set in the destination cluster.

    • The destination replica sets are initiated with the configuration that was discovered before the restore operation was initiated.

    • The secondary nodes are added to the replica sets automatically.

  • You can build a new MongoDB cluster:

    • You must create the instance for the new MongoDB cluster and provide the clients, data path, and ports to restore the data.

    • The data is restored to the selected clients, the replica sets are initiated, and the secondary nodes are added to the replica sets automatically

Before You Begin

You must complete the following processes before initializing the restore operation:

  • In Linux environments, verify that the user ID and group ID of the OS user that is used for starting the MongoDB server are the same on the source and destination clusters across all nodes.

    Note

    • If the OS user id and group id are different from source cluster, then the restored servers will fail to start.

    • If the destination cluster has client authentication enabled, then you must use database user credentials that have the privileges to perform the restore operations, like shutting down the servers or restoring the Oplog dumps

  • For the MongoDB cluster, verify that the cluster meets the following requirements for Out of place restores:

    • In sharded clusters, the number of shards in the source and destination clusters must be the same.

    • The destination servers must have the same or higher version of MongoDB than the source.

    • If you have oplog dump backups enabled on the destination cluster, disable them.

  • Configure the nMongoDbRecoveryConnectionAttemptInterval additional setting to set the wait time between each connection attempt to the MongoDB server during the recovery operation. For information on how to configure an additional setting, see Adding a Setting for Servers and Server Groups.

Procedure

  1. From the navigation pane, go to Protect > Big data.

    The Big data page appears.

  2. In the row for the cluster, click the action button (...) and then click Restore.

    The Backup content page appears.

  3. Select all the content, and then click Restore.

    The Restore options dialog box appears.

  4. From the Restore mode type list, select Out of place.

    There are two different processes to restore a cluster:

    1. Restore to a discovered destination cluster:

      • Using the discovered cluster topology, the restore clients, data paths, and ports are automatically listed under the Replica set options.

    2. Restore to a new destination cluster:

      • You can provide inputs for the primary and secondary member in each replica set under Replica set options:

        • To edit inputs for the primary member in each replica set, under Replica set options, click the Edit button.

          The Provide inputs for primary member dialog box appears.

        • Enter the new values for the primary member, and then click Save.

        • To add a secondary member for each replica set, under Replica set options, click the Add button.

          The Provide inputs for secondary member dialog box appears.

        • Enter the values for the secondary member, and then click Save.

  5. To restore the Oplog dumps, in the Staging path for oplog dumps box, enter the path to restore the dumps.

    Note

    By default, the Oplog backups are restored to the Job Results directory on each node.

  6. By default, the Automatic Restore check box is selected, to automatically shut down the destination MongoDB servers and clean up the data directories as part of the restore. If the Automatic Restore check box is cleared, then before you submit the restore, you must manually shut down the servers and clean up the dbPath.

  7. By default, the Recover Database check box is automatically selected. MongoDB cluster will be initialized after restoring the data on the selected destination clients. Oplog dumps will be applied until the selected time.

  8. Click Restore.

What to Do Next

  • Optionally, for sharded clusters, start the mongo routing service manually if internal authentication is enabled. By default, the mongos service is started as part of the restore operation without authentication.

  • Optionally, after the restore operation is complete, you can restart the MongoDB server using a different config file. By default, the MongoDB server is started using the config file that the Commvault software has created during the restore process.

Loading...