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.
From the navigation pane, go to Protect > Big data.
The Apps page appears.
In the row for the cluster, click the action button , and then click Restore.
The Backup content page appears.
Select all the content, and then click Restore.
The Restore dialog box appears.
On the Out of place tab, do the following:
From the Destination cluster list, select a different cluster.
By default, the source cluster is selected as the destination.
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.
To provide 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.
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.
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 or as a service, stop the MongoDB server after completing the restore operation, and restart the MongoDB server.