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

    • 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:

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

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

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

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

  8. 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, and the oplog dumps are restored and applied on the databases.

    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.

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