- Back Up MongoDB Deployments >
- Restore MongoDB Deployments >
- Restore Flows
Restore Flows¶
On this page
Overview¶
Ops Manager Backup enables you to restore your mongod instance, replica set, or sharded cluster using stored snapshots, 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 a step-by-step guide to restoring a replica set or sharded cluster using Backup, 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. 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. See: Advanced Backup Restore Settings for informaton about configuring the restore behaviors.
With the SCP delivery
option, the Backup Daemon securely copies the restore file or
files directly to your system. The Backup File Format and Method tutorial describes how to
select a restore’s delivery method and file format.
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.
Windows does not come with SCP and require additional setup outside
the scope of this manual.
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 MMS HTTP service calls out to the Backup Daemon, which prepares the snapshot you will receive, then either the user downloads the files from the MMS 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 MMS 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 Backup Blockstore 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 MMS 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 requries 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 Backup Blockstore 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 requries 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 desintation 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 Backup Blockstore 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 desintation server
This restore method also requries 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.