- Back Up and Restore Deployments >
- Restore MongoDB Deployments >
- Restore Overview
Restore Overview¶
On this page
To restore a deployment from a backup, select a snapshot or point in time from which you want to restore your database. Ops Manager provides you with the files from which you can restore your database.
You can restore a single MongoDB database, a replica set, or a sharded cluster. You may select to restore from:
- An existing snapshot,
- A specific point in time by selecting:
- A specific date and time,
- A specific oplog timestamp, or
- A specific sharded cluster checkpoint.
If you are restoring from a point in time, you must download the MongoDB Backup Restore Utility to your target host. The MBRU requests and applies oplog entries between the latest complete snapshot and the point in time you chose.
Note
For sharded clusters, enable checkpoints before restoring to a point between snapshots.
You can restore your backup in one of two ways:
- Ops Manager can restore the files to another cluster if you use Ops Manager automation.
- You can copy restored files manually to the hosts you choose.
Automated Restore¶
If you choose to have Ops Manager automation restore your backup, the Automation Agent removes all existing data from the target hosts and replaces that data with new backup data from your snapshot.
Prerequisites¶
To perform automated restores, you must have:
An Automation Agent installed on the source and all target hosts.
A Monitoring Agent on the target deployment that can connect to all hosts in the target deployment.
The Backup Admin and Automation Admin roles in Ops Manager.
A target cluster whose
featureCompatibilityVersion
is greater than or equal to the source cluster’sfeatureCompatibilityVersion
.Example
Run the following command to retrieve the
featureCompatibilityVersion
of a given host:The
featureCompatibilityVersion
of each host in the target cluster must be greater than or equal to thefeatureCompatibilityVersion
of any host in the source cluster.See setFeatureCompatibilityVersion for complete documentation on changing the
featureCompatibilityVersion
flag.The following compatibility matrix lists the supported source cluster FCV of each MongoDB version. The MongoDB version of each host in the target cluster must support the FCV of the snapshot of the source cluster.
Source Cluster FCV MongoDB 3.2 MongoDB 3.4 MongoDB 3.6 3.2
✓ ✓ 3.4
✓ ✓ 3.6
✓
Restore to Different Project¶
You can choose to restore to a cluster of a different project:
- To restore to another Ops Manager project, you must have Automation Admin or Backup Admin roles for the target project.
- To restore to another MongoDB Atlas project, you must have Project Owner role for the target project.
Potential Causes for Automated Restore Failure¶
An automated restore can fail when certain storage settings of the backup’s database and target database do not match:
storage.engine
storage.directoryPerDB
storage.mmapv1.nsSize
storage.mmapv1.smallFiles
storage.wiredTiger.collectionConfig.blockCompressor
storage.wiredTiger.engineConfig.directoryForIndexes
No method exists to check for mismatches before attempting a restore. If a restore attempt fails, Ops Manager displays any mismatched settings. If you still want to restore the backup’s database, fix the settings in the target database that do not match backup’s database, then retry the restoring the backup’s database.
Restore Procedures¶
To perform an automated restore, see the procedure for the deployment you want to restore:
Manual Restore¶
Prerequisites¶
To perform manual restores, you must have the Backup Admin role in Ops Manager.
Considerations¶
Restore File Format¶
Ops Manager provides each snapshot as an uncompressed (.tar
)
or compressed (.tar.gz
) archive containing a complete copy of the
data directory.
Choosing compressed snapshots results in faster delivery, but requires sufficient space on the target host for both the compressed snapshot and its extracted database files.
- For a replica set, Ops Manager provides one snapshot that you copy to each replica set member.
- For a sharded cluster, Ops Manager provides one snapshot for the config servers and one snapshot for each shard.
File Delivery Methods¶
With a manual restore, Ops Manager can deliver the snapshots in two ways:
Provide a link to download the snapshots through HTTP.
Transfer the snapshots to a target directory on a target host that you choose using SCP.
Note
If you use SCP, you may choose to transfer the individual database files instead of the snapshot as an archive file.
Important
You need to generate a key pair before using SCP. SCP transfers files faster than HTTP.
Note
Microsoft Windows does not include SCP. Installing SCP is outside the scope of this manual.
Restore Process Flows¶
The following pages illustrate the process flows for manual restores using the different restore methods:
- Restore a Completed Snapshot using HTTP
- Restore a complete snapshot and retrieve it using HTTP.
- Restore from a Specific Point-in-Time using HTTP
- Restore a snapshot based on a specific point in time, oplog timestamp, or cluster checkpoint and retrieve it using HTTP.
- Restore a Complete Snapshot using SCP
- Restore a complete snapshot and transfer it using SCP.
- Restore from a Specific Point-in-Time using SCP
- Restore a snapshot based on a specific point in time, oplog timestamp, or cluster checkpoint and retrieve it using SCP.
Manual Restore Procedures¶
To perform a manual restore, see the procedure for the deployment you want to restore: