- 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¶
When you restore a cluster from a backup, Ops Manager provides you with a restore files for the selected restore point. For an overview of the restore process, please see Restore Overview.
Considerations¶
BinData
¶
The BSON specification changed the
default subtype for the BSON binary datatype (BinData
) from 2
to 0
. Some binary data stored in a snapshot may be BinData
subtype 2. The Backup Agent automatically detects and converts snapshot
data in BinData
subtype 2 to BinData
subtype 0. If your
application code expects BinData
subtype 2, you must update your
application code to work with BinData
subtype 0.
See also
The notes on the BSON specification explain the particular specifics of this change.
The backup restore file includes a metadata file, restoreInfo.txt
.
This file captures the options the database used when the snapshot was
taken. The database must be run with the listed options after it has
been restored.
restoreInfo.txt
¶
This file contains:
Group name
Replica Set name
Cluster Id (if applicable)
Snapshot timestamp (as Timestamp at UTC)
Last Oplog applied (as a BSON Timestamp at UTC)
MongoDB version
Storage engine type
mongod
startup options used on the database when the snapshot was takenEncryption (Only appears if encryption is enabled on the snapshot)
Master Key UUID (Only appears if encryption is enabled on the snapshot)
If restoring from an encrypted backup, you must have a certificate provisioned for this Master Key.
Prerequisites¶
Restoring from Encrypted Backup¶
To restore from an encrypted backup, you need the same master key used to encrypt the backup and either the same certificate as is on the Backup Daemon server or a new certificate provisioned with that key from the KMIP server.
If the snapshot is encrypted, the restore panel displays the KMIP
master key id and the KMIP server information. You can also find
the information when you view the snapshot itself as well as in
the restoreInfo.txt
file.
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.
Secure Copy (SCP
) Delivery¶
Important
SCP
requires you to
generate a key pair
before attempting to transfer files. SCP
provides faster file
delivery than HTTP
.
Note
Microsoft Windows computers do not include SCP
and require
additional setup outside the scope of this manual.
When copying files individually, the MaxStartups
value in
sshd_config
should be increased to:
(4 × (number of shards + number of config servers)) + 10
SCP
is performed in parallel and, by default, Secure Shell Daemon
(sshd
) installations use a small number of concurrent connections.
Changing this setting in sshd_config
allows SCP
to support
sufficient connections to complete the restore.
Example
For a sharded cluster with 7 shards and 3 config servers, change
MaxStartups
to 50
:
MaxStartups 50
Automatic Restore¶
To have Ops Manager automatically restore the backup, perform the select the snapshot procedure.
Manual Restore¶
To restore the backup manually, perform the following:
- Select and Retrieve the Snapshot.
- Unmanage the Sharded Cluster.
- Restore the Sharded Cluster Manually.
- Reimport the Sharded Cluster.
Select and Retrieve the Snapshot¶
Click Backup, then the Overview tab.¶
Click the deployment’s ellipsis icon and select Restore.¶
Select the restore point.¶
Choose the point from which you want to restore your backup.
Restore Type | Description | Action |
---|---|---|
Snapshot | Allows you to choose one stored snapshot. | Select an existing snapshot to restore. |
Point In Time | Creates a custom snapshot that includes all operations up to but not including the selected time. Example If you select |
Select a Date and Time. |
Click Next.
Select whether to have Ops Manager restore the snapshot.¶
Yes | Ops Manager restores the snapshot for you. If you select this option, Ops Manager prompts to choose the cluster to which to restore. You can select an existing cluster or create a new one. Follow the prompts in the wizard. Important You can skip the remainder of this page. |
No, I’ll do it myself | Ops Manager provides you with the restore files for you to perform the restore manually. |
Choose how to receive the restore files.¶
Select the restore method, format and destination.
Pull Via Secure HTTP |
Important You can skip the remainder of this procedure. |
Push Via Secure Copy | Direct Ops Manager to copy the restore files to your server via
Important
Note Microsoft Windows computers do not include |
Format | Select the format in which you want to receive the restore files:
|
SCP Host | Type the hostname of the server to receive the files. |
SCP Port | Type the port of the server to receive the files. |
SCP User | Type 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 | Type the user password used to access to the server. |
Passphrase | Type the SSH passphrase used to access to the server. |
Target Directory | Type the absolute path to the directory on the server to which to copy the restore files. |
If the snapshot is encrypted, the restore panel displays the KMIP
master key id and the KMIP server information. You can also find
the information when you view the snapshot itself as well as in
the restoreInfo.txt
file.
Click Finalize Request.
Retrieve the snapshot.¶
- If you selected Pull Via Secure HTTP:
Ops Manager creates links to the snapshot. By default, these links are available for an hour and can be used just once. To download the snapshot:
- Click Backup, then the Restore History tab.
- 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 restore archives.
- For the config server, copy its config restore archive to each of its replica set members.
- For each shard, copy its restore archive to each of its replica set members.
- Extract the shard restore archive to the shard’s working database path.
- If you selected Push Via Secure Copy:
Ops Manager copies the files to the server directory you specified. After the files transfer, you should:
- Verify that the files are complete, see how to validate a secure copy restore.
- Copy the config server restore archive or files to each member of its replica set.
- Copy each shard restore archive or files to each member of the shard’s replica set.
- If the restored files were received as an archive, extract the archive to the shard’s working database path.
Unmanage the Sharded Cluster¶
Before attempting to restore the data manually, remove the sharded cluster from Automation.
Restore the Sharded Cluster Manually¶
Follow the tutorial from the MongoDB Manual to restore the sharded cluster.
Reimport the Sharded Cluster¶
To manage the sharded cluster with automation again, import the sharded cluster back into Ops Manager.