- Back Up and Restore Deployments >
- Restore MongoDB Deployments >
- Restore Overview
Restore Overview¶
On this page
Introduction¶
When you restore a deployment from a backup, you select a restore point and Ops Manager provides you with one or more restore files. If you use Ops Manager automation, Ops Manager can automatically restore the files for you. Otherwise, you manually restore the files by copying them yourself to the servers you choose.
You can restore a single MongoDB process or an entire replica set or sharded cluster. You select whether to restore from an existing snapshot or a restore point between snapshots. For the latter, Ops Manager builds a custom snapshot based on the restore point you choose. Installing from a custom snapshot takes longer as Ops Manager must build the snapshot by applying the oplog to the previous regular snapshot. For sharded clusters, you must enable checkpoints before you can restore to a point between snapshots.
You can restore to either new hardware or existing hardware. If you use existing hardware and perform the restore manually, create a new path for the MongoDB data directory. Do not use existing data directories.
Automated Restore¶
If you choose to have Ops Manager automatically restore your backup, Ops Manager removes all existing data from the target servers and replaces that data with new backup data from your snapshot. For automated restores, you must have:
- An Automation Agent installed on the source and target hosts.
- A Monitoring Agent installed on a host in the target deployment that can connect to all other managed hosts in that deployment.
Note
You must have the Backup Admin and Automation Admin Ops Manager roles to perform automated restores.
Important
Under certain conditions, an automated restore fails because either:
- The backup and destination databases’ storage engines do not match, or
- The destination database uses settings that are different from the
settings of the backup itself:
storage.directoryPerDB
storage.mmapv1.nsSize
storage.mmapv1.smallFiles
storage.wiredTiger.collectionConfig.blockCompressor
storage.wiredTiger.engineConfig.directoryForIndexes
If the backup and destination database storage engines or settings do not
match, mongod
cannot start once the backup is restored. At this time,
you can either:
- Not restore this snapshot, or
- Change the storage engine or settings of the destination sharded cluster or replica set to match the configuration of the snapshot.
Manual Restore¶
Ops Manager provides each restore file as an archive, .tar
or .tar.gz
,
containing a complete copy of the data directory.
- For a replica set, Ops Manager provides one archive that you copy to each replica set member.
- For a sharded cluster, Ops Manager provides one archive for the config servers and separate archives for each shard.
Note
You must have the Backup Admin Ops Manager role to perform manual restores.
With a manual restore, Ops Manager can provide the files in two ways:
- Download via
HTTP
- Ops Manager provides a link to download the restore files.
- Transfer via secure copy (
SCP
) Ops Manager transfers the restore archive(s) or the individual data files to a target directory on a destination server of your choosing.
Important
SCP
requires you to generate a key pair before attempting to transfer files.SCP
provides faster file delivery thanHTTP
.Note
Microsoft Windows computers do not include
SCP
and require additional setup outside the scope of this manual.
If you choose to receive archive files, you must extract the contents of each archive, then reconstruct your data.
This is generally faster than choosing to download the individual data files but requires sufficient space on the destination server for both the archive file and the extracted contents.