• Back Up and Restore Deployments >
• Restore MongoDB Deployments >
• Restore Overview

Restore Overview

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 than HTTP.

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.

←   Restore MongoDB Deployments Restore Flows  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.