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

Updated

You can restore an entire MongoDB cluster to a different cluster (out of place).

The data is restored to the selected servers in each replica set in the destination cluster, the destination replica sets are initiated, and then 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.

Before You Begin

  • Verify that the MongoDB system meets the following requirements for out-of-place restores:

    • In sharded clusters, the number of shards in source and destination clusters must be 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.

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

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, and then do the following:

    1. From the Destination cluster list, select a different cluster.

      The destination nodes are auto-populated from the destination cluster.

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

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

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

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

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

      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.

      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.

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

    7. Click Restore.

What to Do Next

  • For sharded clusters, start the mongo routing service (mongos) on the required nodes:

    mongos --config <path-to-config>
  • After the restore operation is complete, MongoDB server is started as a process using the config file that the Commvault software has created during the restore process. To start the MongoDB server using another config file, stop the MongoDB server after completing the restore operation, and restart the MongoDB server.