# Restoring a MongoDB Cluster to Its Current Location (In Place)

You can restore an entire MongoDB cluster to its current location (in place).

After the data is restored to all the servers in the source cluster, replica sets are initiated, and then all the secondary nodes are added to the corresponding replica set automatically.

Note

- If authentication is disabled on the destination MongoDB server, the loopback IP (127.0.0.1/localhost) must be a part of the bind_ip list to automatically shut down the server. Otherwise, you will need to manually shut down the server.

- If authentication is enabled, the MongoDB user must have a root role to initialize replica sets.

## Before You Begin

- If you scheduled oplog dump backups, disable them.

- Review the in-place restore considerations.

- 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 the content that you want to restore, and then click Restore.

   The Restore options dialog box appears.

5. In the Restore mode type list, verify that the in place restore type is selected.

   By default, the Automatic Restore check box is selected to automatically shut down the MongoDB servers and clean up the data directories as part of the restore.

   If you are using OpsManager to manage a MongoDB cluster, the OpsManager services shut down automatically. After the restore is complete, the services automatically start again. On Unix clusters, by default, the systemctl commands are used to start and stop OpsManager. However, you can set the sOpsManagerServiceScript additional setting to override the systemctl commands.

   Note

   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. In addition, on Linux, if there are any symbolic links to dbPath or under dbPath, they must not be removed.

6. To perform a point-in-time restore between the duration of incremental backups, beside Apply oplog until, enter the backup time.

7. To restore the oplogs, in the Staging path for Oplog dumps box, enter the path to restore the Oplogs to.

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

   Note

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

   The Confirm restore dialog box appears.

9. Click Yes.

## What to Do Next

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

×

Loading...