Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

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 chosen servers and replaces that data with new backup data from your backup. For an automated restore, only the systems restoring and receiving the backup data needs to have Automation Agents installed.

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 not currently preserved in the backup itself.

If the backup and destination database storage engines 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 of the destination sharded cluster or replica set to match the configuration of the snapshot.

If the destination database uses any of the following settings, an automated restore fails:

Manual Restore

For a manual restore, Ops Manager provides each restore file as an archive (.tar or .tar.gz) containing the 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.

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:

  • Temporary space to store the archive and its extracted files on the server hosting the Backup Daemon.
  • Sufficient space on the destination server for both the archive file and the extracted contents.