Restore a Completed Snapshot

1. The user selects a snapshot:

   • Through the Ops Manager application:

     1. Click on a snapshot.

     2. Submit their request.

   • Through the API:

     1. Find the cluster to restore.

     2. Create new Restore Job for that cluster.

2. Ops Manager creates a RestoreJob document.

3. Ops Manager sets the RestoreJob document status to Transferring... and starts streaming the snapshot in the requested format from the snapshot store to Ops Manager. Each Snapshot Store streams its snapshot components through Ops Manager:

   • A blockstore streams

     the blocks.

   • An S3 snapshot store streams the blocks.

4. With the status set to Waiting for Customer..., Ops Manager creates a URL.

5. The user clicks the get link link, then Download in the Ops Manager application to download the snapshot.

click to enlarge

1. The user selects a snapshot:

   • Through the Ops Manager application:

     1. Click on a snapshot.

     2. Submit their request.

   • Through the API:

     1. Find the cluster to restore.

     2. Create new Restore Job for that cluster.

2. Ops Manager creates a RestoreJob document.

3. The Backup Daemon service picks up the RestoreJob document and sets the status of this RestoreJob document to Waiting for Customer....

4. With the status set to Waiting for Customer..., Ops Manager creates a URL.

5. The user clicks the get link link, then Download in the Ops Manager application to download the snapshot.

6. Ops Manager sets the RestoreJob document status to Transferring... and starts streaming the snapshot in the requested format from the snapshot store to the target snapshot host. Each Snapshot Store streams its snapshot components through Ops Manager:

   • A blockstore streams

     the blocks.

   • An S3 snapshot store streams the blocks.

   • A file system store streams the files.

This process works like replica set data synchronization.

The backup process:

1. Performs an initial sync to back up all of your existing data in its current state. In sharded clusters, this occurs on each shard and on the config servers.

   Note

   Conditions or Actions that Restart Initial Sync

   During the initial sync process, certain actions or conditions can restart the initial sync process. Avoid the following actions and conditions:

   Actions to Avoid during Initial Sync:

   • Restarting, shutting down, or changing the version or FCV value of the source database.

   • Renaming the collection of the source database.

   • Changing the $out value in the Aggregation Pipeline of the source database.

   • Restarting or shutting down Ops Manager Application or Backup Daemon.

   • Restarting, shutting down, or upgrading the MongoDB Agent.

   Conditions to Avoid during Initial Sync:

   • Head Directory is full.

   • Network connectivity between Ops Manager components is unstable.

2. Takes snapshots of the data directory in a deployment as often as your snapshot schedule specifies and then transfers the snapshots to a storage system.

   Note

   Sharded Clusters also can enable checkpoints to permit restores at points in time between snapshots. To learn how sharded clusters use checkpoints, see checkpoints.

   Important

   You may use checkpoints for clusters that run MongoDB with Feature Compatibility Version of 4.0 or earlier. Checkpoints were removed from MongoDB instances with FCV of 4.2 or later.

3. Monitors the oplog constantly and adds new database operations to the latest backup to keep the local Ops Manager copy of the data current.

The backup process works in this manner regardless of how snapshots are stored.