- Back Up and Restore Deployments >
- Restore MongoDB Deployments >
- Restore Overview
Restore Overview¶
Introduction¶
Ops Manager Backup enables you to restore your mongod instance, replica set, or sharded cluster from a stored snapshot or from a point in time as far back as the retention period of your longest snapshot.
The general flows and options are the same whether you are restoring a mongod, replica set, or sharded cluster; the only major difference is that sharded cluster restores result in the production of multiple restore files that must be copied to the correct destination.
This page describes the different types of restores and different delivery options, and then provides some insight into the actual process that occurs when you request a restore through Ops Manager.
For the procedure for restoring a replica set or sharded cluster, see: Restore MongoDB Deployments.
Restore Types¶
With Backup, you can restore from a stored snapshot or build a custom snapshot reflecting a specific point in time. For all backups, restoring from a stored snapshot is faster than restoring from a specific point in time.
Snapshots provide a complete backup of the state of your MongoDB deployment at a given point in time. You can take snapshots every 6, 8, 12, or 24 hours and set a retention policy to determine for how long the snapshots are stored.
Point-in-time restores let you restore your mongod instance or replica set to a specific point in time in the past. You can restore to any point back to your oldest retained snapshot. For sharded clusters, point-in-time restores let you restore to a checkpoint. You must first enable checkpoints. See Checkpoints for more information.
Point-in-time restores take longer to perform than snapshot restores, but allow you to restore more granularly. When you perform a point-in-time restore, Ops Manager takes the most recent snapshot that occurred prior to that point and then applies the oplog to bring the database up to the state it was in at that point in time. This way, Ops Manager creates a custom snapshot, which you can then use in your restore.
Delivery Methods and File Formats¶
Ops Manager provides two delivery methods: HTTP delivery, and SCP.
With HTTP delivery, Ops Manager creates a link that you can use to download the snapshot file or files.
With the SCP
delivery
option, the Backup Daemon securely copies the restore file or
files directly to your system. To use this option, you must first
generate a key pair for SCP restores. Windows machines do not
come with SCP
and require additional setup outside the scope of this
manual.
For SCP delivery, you can choose your file format to better suit your restore needs. With the Individual DB Files format, Ops Manager transmits the MongoDB data files directly to the target directory. The individual files format only requires sufficient space on the destination server for the data files.
In contrast, the Archive (tar.gz) option bundles the database
files into a single tar.gz
archive file, which you must extract before
reconstruction your databases. This is generally faster than the
individual files option, but requires temporary space on the server
hosting the Backup Daemon and sufficient space on the destination server
to hold the archive file and extract it.
The conf-daemon.properties
Ops Manager configuration file provides
access to several settings that affect Backup’s restore behaviors.
See: Advanced Backup Restore Settings for information about
configuring the restore behaviors.
Restore Flows¶
Regardless of the delivery method and restore type, Ops Manager’s restore flow follows a consistent pattern: when you request a restore, the Ops Manager HTTP Service calls out to the Backup Daemon, which prepares the snapshot you will receive, then either the user downloads the files from the Ops Manager HTTP Service, or the Backup Daemon securely copies the files to the destination server.
The following sections describe the restore flows for both snapshot restores and point-in-time restores, for each delivery and file format option.
HTTP Restore¶
Snapshot¶
With the HTTP PULL snapshot restore, the Backup Daemon simply creates a link to the appropriate snapshot in the Backup Blockstore Database. When the user clicks the download link, they download the snapshot from the Ops Manager HTTP Service, which streams the file out of the Backup Blockstore.
This restore method has the advantage of taking up no space on the server hosting the Backup Daemon: the file passes directly from the Backup Blockstore to the destination server.
Point-In-Time¶
The HTTP PULL point-in-time restore follows the same pattern as the HTTP PULL snapshot restore, with added steps for applying the oplog. When the user requests the restore, the Backup Daemon retrieves the snapshot that immediately precedes the point in time and writes that snapshot to disk. The Backup Daemon then retrieves oplog entries from the Oplog Store Database and applies them, creating a custom snapshot from that point in time. The Daemon then writes the snapshot back to the Backup Blockstore. Finally, when the user clicks the download link, the user downloads the snapshot from the Ops Manager HTTP Service, which streams the file out of the Backup Blockstore.
This restore method requires that you have adequate space on the server hosting the Backup Daemon for the snapshot files and oplog.
Archive SCP Restore¶
Snapshot¶
For a snapshot restore, with SCP archive delivery, the Backup Daemon
simply retrieves the snapshot from the Backup Blockstore and writes it
to its disk. The Backup Daemon then combines and compresses the snapshot into a
.tar.gz
archive and securely copies the archive to the destination
server.
This restore method requires that you have adequate space on the server hosting the Backup Daemon for the snapshot files and archive.
Point-In-Time¶
The point-in-time restore with SCP archive delivery follows the same pattern as the snapshot restore, but with added steps for applying the oplog.
When the user requests the restore, the Backup Daemon retrieves
the snapshot that immediately precedes the point in time and writes
that snapshot to disk. The Backup Daemon then retrieves oplog entries
from the Oplog Store Database and applies them, creating a custom snapshot
for that point in time. The Backup Daemon then combines and compresses
the snapshot into a tar.gz
archive and securely copies the archive
to the destination server.
This restore method requires that you have adequate space on the server hosting the Backup Daemon for the snapshot files, oplog, and archive.
Individual Files SCP Restore¶
Snapshot¶
For a snapshot restore, with SCP individual files delivery, the Backup Daemon simply retrieves the snapshot from the Backup Blockstore and securely copies the data files to the target directory on the destination server.
This restore method also has the advantage of taking up no space on the server hosting the Backup Daemon: the file passes directly from the Backup Blockstore to the destination server. The destination server requires only sufficient space for the uncompressed data files. The data is compressed during transmission.
Point-In-Time¶
The point-in-time restore with SCP individual files delivery follows the same pattern as the snapshot restore, but with added steps for applying the oplog.
When the user requests the restore, the Backup Daemon retrieves the snapshot that immediately precedes the point in time and writes that snapshot to disk. The Backup Daemon then retrieves oplog entries from the Oplog Store Database and applies them, creating a custom snapshot for that point in time. The Backup Daemon then securely copies the data files to the target directory on the destination server
This restore method also requires that you have adequate space on the server hosting the Backup Daemon for the snapshot files and oplog. The destination server requires only sufficient space for the uncompressed data files. The data is compressed during transmission.