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.

  • For sharded cluster environmanets, the destination mongos (routing service) is started automatically.

• You can build a new MongoDB cluster:

  • You must create a Test instance in the Commvault software without having the nodes discovered. Use this Test instance as the destination cluster.

  • Provide the Dest. Client, Dest. dbPath, and Dest. Port number to restore the data.

  • The data is restored to the selected clients, the replica sets/shards are initiated, and the secondary nodes are added to the replica sets/shards 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 update the MongoDB credentials of the source cluster in the instance properties of the destination cluster so that the restore operation completes successfully.

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

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

  • For replica sets, the number of nodes in the source and destination clusters does not need to match.

  • 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 Command Center navigation pane, go to Protect > Big data.

   The Big data page appears.

2. Click MongoDB.

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

   The Backup content page appears.

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

   The Restore options dialog box appears.

5. 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:

      • From the Destination cluster dropdown list, select the cluster.

      • Using the discovered cluster topology, the Dest. Client, Dest. dbPath, and Dest. port for the restore clients and mongos (routing service if present) are automatically listed under the Replica set options section.

   2. Restore to a new destination cluster:

      • From the Destination cluster dropdown list, select the Test instance that you created.

      • You can provide inputs for the primary and secondary members of the destination replica sets under the Replica set options section:

        • To add the primary member, click the Add primary button.

          The Provide inputs for primary member dialog box appears.

        • Specify the Source Replica set, Dest. Replica set, Dest. Client, Dest. dbPath and Dest. Port number values for the primary member, and then click Save.

        • To add a secondary member, click More options, and then click Add secondary button.

          The Provide inputs for secondary member dialog box appears.

        • Specify the Source Replica set, Dest. Replica set, Dest. Client, Dest. dbPath and Dest. Port number values for the primary member, and then click Save.

        • To add a mongos (routing service) for sharded cluster, click the Add primary button

6. In the Apply oplog until field, select the time until when the Oplog dumps will be applied.

7. 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.

   • If the Oplog dump restore fails with the error 'oplog: applyOps: (Unauthorized) not authorized on admin to execute command', even though the MongoDB authentication user account has both the restore and clusterAdmin roles assigned, you can temporarily assign the following role to the user account to perform the restore operation. This role can be revoked once the restore completes.

     db.grantRolesToUser("$[user_name]", [{ role: "anyActionAnyResource", db: "$[admin]" }])

8. By default, the Automatic Restore check box is selected, to automatically shut down the destination MongoDB servers (mongod, mongos) and clean up the data directories as part of the restore operation. 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.

9. By default, the Recover Database check box is automatically selected. Once the data on the selected destination clients is restored, the MongoDB cluster is initialized, the oplog dumps are restored and applied on the databases, and the mongos (routing service) is started automatically.

   Note:

   If the Recover Database checkbox is not selected, you must verify that the restored data files have the required permissions for the database user in the destination cluster before proceeding to initialize the replica sets.

10. Click Restore.