- Back Up and Restore Deployments >
- Restore MongoDB Deployments >
- Restore a Sharded Cluster from a Backup
Restore a Sharded Cluster from a Backup¶
On this page
Overview¶
You can restore a sharded cluster onto new hardware from the artifacts captured by Backup.
You can restore from a snapshot or checkpoint. You must enable checkpoints to use them. When you restore from a checkpoint, Ops Manager takes the snapshot previous to the checkpoint and applies the oplog to create a custom snapshot. Checkpoint recovery takes longer than recovery from a stored snapshot.
Ops Manager provides restore files as downloadable archives. You receive a
separate .tar.gz
file for each shard and one .tar.gz
file
for the config servers.
Sequence¶
The sequence to restore a snapshot is to:
- select and download the restore files,
- distribute the restore files to their new locations,
- start the mongod instances,
- configure each shard’s replica set, and
- configure and start the cluster.
Considerations¶
Client Requests During Restoration¶
You must ensure that the MongoDB deployment does not receive client requests during restoration. You must either:
- restore to new systems with new hostnames and reconfigure your application code once the new deployment is running, or
- ensure that the MongoDB deployment will not receive client requests while you restore data.
Snapshots when Agent Cannot Stop Balancer¶
Ops Manager displays a warning next to cluster snapshots taken while the balancer is enabled. If you restore from such a snapshot, you run the risk of lost or orphaned data. For more information, see Snapshots when Agent Cannot Stop Balancer.
Procedures¶
Select and Download the Snapshot Files¶
Select the Backup tab and then Overview page.¶
On the line listing the process, click the ellipsis icon and select Restore.¶
Select the restore point.¶
Select the restore point, enter information as needed, and then click Next:
Snapshot | Restores from a scheduled snapshot. Select the snapshot from which to restore. |
Point In Time | Creates a custom snapshot based on a checkpoint. Select a Date and Time and click Next. |
Select how to receive the restore files.¶
Select the restore method, format, and destination. Enter information as needed, and then click Finalize Request:
Pull Via Secure HTTP | Create a one-time direct download link. If you select this, click Finalize Request and skip the rest of this procedure. |
Push Via Secure Copy | Direct Ops Manager to copy the restore files to your server via Windows machines do not come with |
Format | Sets the format of the restore files:
|
SCP Host | The hostname of the server to receive the files. |
SCP Port | The port of the server to receive the files. |
SCP User | The username used to access to the server. |
Auth Method | Select whether to use a username and password or an SSH certificate to authenticate to the server. |
Password | The user password used to access to the server. |
Passphrase | The SSH passphrase used to access to the server. |
Target Directory | The absolute path to the directory on the server to which to copy the restore files. |
Retrieve the snapshot.¶
If you selected Pull Via Secure HTTP, Ops Manager creates links to the snapshot that by default are available for an hour and can be used just once. To download the snapshot files, select the Backup tab and then Restore History page. When the restore job completes, a download link appears for each shard and for one of the config servers. Click each link to download the files and copy each to its server. For a shard, copy the file to every member of the shard’s replica set.
If you selected Push Via Secure Copy, Ops Manager copies the files to the server directory you specfied. To verify that the files are complete, see the section on how to validate an SCP restore. For each shard, copy its restore file to every member of the shard’s replica set.
Restore Each Shard’s Primary¶
For all shards, restore the primary. You must have a copy of the snapshot on the server that provides the primary:
Shut down the entire replica set.¶
Shut down the replica set’s mongod processes using one of the following methods, depending on your configuration:
Automated Deployment:
If you use Ops Manager Automation to manage the replica set, you must shut down through the Ops Manager console. See Shut Down a MongoDB Process.
Non-Automated Deployment on MongoDB 2.6 or Later:
Connect to each member of the set and issue the following:
Non-Automated Deployment on MongoDB 2.4 or earlier:
Connect to each member of the set and issue the following:
Restore the snapshot data files to the primary.¶
Extract the data files to the location where the mongod
instance will access them through the dbpath
setting. If you
are restoring to existing hardware, use a different data directory than
used previously. The following are example commands:
Start the primary with the new dbpath
.¶
For example:
Connect to the primary and initiate the replica set.¶
For example, first issue the following to connect:
And then issue rs.initiate()
:
Restart the primary as a standalone, without the --replSet
option.¶
Use the following sequence:
Shut down the process using one of the following methods:
Automated Deployment:
Shut down through the Ops Manager console. See Shut Down a MongoDB Process.
Non-Automated Deployment on MongoDB 2.6 or Later:
Non-Automated Deployment on MongoDB 2.4 or earlier:
Restart the process as a standalone:
Run the seedSecondary.sh
script on the primary.¶
The seedSecondary.sh script re-creates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This will allow the secondary to come back up to time without requiring a full initial sync. This script is customized by Ops Manager for this particular snapshot and is included in the backup restore file.
Use the appropriate script for your operating system:
UNIX-based | seedSecondary.sh |
Windows | seedSecondary.bat |
This script recreates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This allows the secondary to come back up to time without requiring a full initial sync. Ops Manager customizes this script for this particular snapshot and is included in the backup restore file.
To run the script, issue the following command, where:
<mongodPort> |
The port of the mongod process |
<oplogSizeInGigabytes> |
The size of the replica set’s oplog |
<replicaSetName> |
The name of the replica set |
<primaryHost:primaryPort> |
The hostname:port combination for the replica set’s primary |
For UNIX-based systems:
For Windows-based systems:
Restart the primary as part of a replica set.¶
Use the following sequence:
Shut down the process using one of the following methods:
Automated Deployment:
Shut down through the Ops Manager console. See Shut Down a MongoDB Process.
Non-Automated Deployment on MongoDB 2.6 or Later:
Non-Automated Deployment on MongoDB 2.4 or earlier:
Restart the process as part of a replica set:
Restore All Secondaries¶
After you have restored the primary for a shard you can restore all secondaries. You must have a copy of the snapshot on all servers that provide the secondaries:
Connect to the server where you will create the new secondary.¶
Restore the snapshot data files to the secondary.¶
Extract the data files to the location where the mongod
instance will access them through the dbpath
setting. If you
are restoring to existing hardware, use a different data directory than
used previously. The following are example commands:
Start the secondary as a standalone, without the --replSet
option.¶
Use the following sequence:
Shut down the process using one of the following methods:
Automated Deployment:
Shut down through the Ops Manager console. See Shut Down a MongoDB Process.
Non-Automated Deployment on MongoDB 2.6 or Later:
Non-Automated Deployment on MongoDB 2.4 or earlier:
Restart the process as a standalone:
Run the seedSecondary.sh
script on the secondary.¶
The seedSecondary.sh script re-creates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This will allow the secondary to come back up to time without requiring a full initial sync. This script is customized by Ops Manager for this particular snapshot and is included in the backup restore file.
Use the appropriate script for your operating system:
UNIX-based | seedSecondary.sh |
Windows | seedSecondary.bat |
This script recreates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This allows the secondary to come back up to time without requiring a full initial sync. Ops Manager customizes this script for this particular snapshot and is included in the backup restore file.
To run the script, issue the following command, where:
<mongodPort> |
The port of the mongod process |
<oplogSizeInGigabytes> |
The size of the replica set’s oplog |
<replicaSetName> |
The name of the replica set |
<primaryHost:primaryPort> |
The hostname:port combination for the replica set’s primary |
For UNIX-based systems:
For Windows-based systems:
Restart the secondary as part of the replica set.¶
Use the following sequence:
Shut down the process using one of the following methods:
Automated Deployment:
Shut down through the Ops Manager console. See Shut Down a MongoDB Process.
Non-Automated Deployment on MongoDB 2.6 or Later:
Non-Automated Deployment on MongoDB 2.4 or earlier:
Restart the process as part of a replica set:
Connect to the primary and add the secondary to the replica set.¶
Connect to the primary and use rs.add()
to add the secondary
to the replica set.
Repeat this operation for each member of the set.
Restore Each Config Server¶
Perform this procedure separately for each config server. Each config server must have a copy of the tar file with the config server data.
Restore the snapshot to the config server.¶
Extract the data files to the location where the config server’s
mongod instance will access them. This is the location you
will specify as the storage.dbPath
when running mongod for
the config server.
Start the config server.¶
The following example starts the config server using the new data:
Update the sharded cluster metadata.¶
If the new shards do not have the same hostnames and ports as the original cluster, you must update the shard metadata. To do this, connect to each config server and update the data.
First connect to the config server with the mongo shell. For example:
Then access the shards
collection in the config database. For example:
The find()
method returns the documents in the shards
collection. The collection contains a document for each shard in the
cluster. The host
field for a shard displays the name of the
shard’s replica set and then the hostname and port of the shard. For
example:
To change a shard’s hostname and port, use the MongoDB
update()
command to modify the
documents in the shards
collection.
Start the mongos
¶
Start the cluster’s mongos bound to your new config servers.