On this page

• A. (Optional) Review Replica Set Configurations
• B. Prepare the Target Host for Restoration
• C. Restore Config Server Replica Set
• D. Restore Each Shard Replica Set
• E. Restart Each mongos
• F. Validate Cluster Accessibility

Note

The following procedure applies to 3.6 sharded clusters. For earlier versions of MongoDB, refer to the corresponding version of the MongoDB Manual.

MongoDB Cloud Backups

MongoDB Cloud Services provides built-in backup and restoration features for automatically restore sharded cluster backups.

For more information, see MongoDB Atlas , MongoDB Cloud Manager , and MongoDB Ops Manager .

A. (Optional) Review Replica Set Configurations

This procedure initiates a new replica set for the Config Server Replica Set (CSRS) and each shard replica set using the default configuration. To use a different replica set configuration for your restored CSRS and shards, you must reconfigure the replica set(s).

If your source cluster is healthy and accessible, connect a mongo shell to the primary replica set member in each replica set and run rs.conf() to view the replica configuration document.

If you cannot access one or more components of the source sharded cluster, please reference any existing internal documentation to reconstruct the configuration requirements for each shard replica set and the config server replica set.

B. Prepare the Target Host for Restoration

Storage Space Requirements

Ensure the target host hardware has sufficient open storage space for the restored data. If the target host contains existing sharded cluster data that you want to keep, ensure that you have enough storage space for both the existing data and the restored data.

LVM Requirements

For LVM snapshots, you must have at least one LVM managed volume group and an a logical volume with enough free space for the extracted snapshot data.

MongoDB Version Requirements

Ensure the target host and source host have the same MongoDB Server version. To check the version of MongoDB available on a host machine, run mongod --version from the terminal or shell.

For complete documentation on installation, see Install MongoDB.

Shut Down Running MongoDB Processes

If restoring to an existing cluster, shut down the mongod or mongos process on the target host.

For hosts running mongos, connect a mongo shell to the mongos and run db.shutdownServer() from the admin database:

copy

use admin
db.shutdownServer()

For hosts running a mongod, connect a mongo shell to the mongod and run db.isMaster():

• If ismaster is false, the mongod is a secondary member of a replica set. You can shut it down by running db.shutdownServer() from the admin database.

• If ismaster is true, the mongod is the primary member of a replica set. Shut down the secondary members of the replica set first. Use rs.status() to identify the other members of the replica set.

  The primary automatically steps down after it detects a majority of members are offline. After it steps down (db.isMaster returns ismaster: false), you can safely shut down the mongod

Prepare Data Directory

Create a directory on the target host for the restored database files. Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:

copy

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

Substitute /path/to/mongodb with the path to the data directory you created. On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Prepare Log Directory

Create a directory on the target host for the mongod log files. Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:

copy

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

Substitute /path/to/mongodb/logs with the path to the log directory you created. On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Create Configuration File

This procedure assumes starting a mongod with a configuration file.

Create the configuration file in your preferred location. Ensure that the user that runs the mongod has read and write permissions on the configuration file:

copy

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.

Open the configuration file in your preferred text editor and modify at it as required by your deployment. Alternatively, if you have access to the original configuration file for the mongod, copy it to your preferred location on the target host.

Important

Validate that your configuration file includes the following settings:

• storage.dbPath must be set to the path to your preferred data directory.
• systemLog.path must be set to the path to your preferred log directory
• net.bindIp must include the IP address of the host machine.
• replication.replSetName has the same value across each member in any given replica set.
• sharding.clusterRole has the same value across each member in any given replica set.

C. Restore Config Server Replica Set