Restore from a Specific Point-in-Time

Considerations

When you request a point-in-time restore, the restore dialog shows the restorable time ranges for the selected deployment. These ranges represent the periods for which Ops Manager has a complete and continuous oplog history. You can only choose a restore time that falls within one of these ranges.

Oplog gaps can occur in the following situations:

• The oplog tailing stops because of an issue with a backup job tailing the oplog, and the oplog rolls over before MongoDB Agent tails it again.

• A topology change occurs, until Ops Manager completes a new snapshot.

• A FCV change occurs, until Ops Manager completes a new snapshot. You cannot apply a point-in-time restore across MongoDB version changes.

• A restore completes, until Ops Manager completes a new snapshot.

If the restore time you need is not available in the dialog, investigate recent topology or FCV changes and review backup job history to understand why that period is not restorable.

For example, the restore dialog might show these restorable time ranges:

• June 8th 13:45:03 to June 8th 17:45:03

• June 8th 19:45:03 to June 9th 07:45:03

In this case, you cannot restore to any time between June 8th 17:45:03 and June 8th 19:45:03 because an oplog gap exists for that period.

You can request a point-in-time restore to a specific point in time that includes stale data.

Procedure

1. The user selects a timestamp:

   • Through the Ops Manager application:

     1. Click on a timestamp.

     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:

   1. A blockstore streams blocks.

   2. A 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.

6. The user downloads the MongoDB Backup Restore Utility from the Ops Manager application to the target snapshot host.

   Note

   The MBRU can be used with any restore. If the utility is installed on the host where you want to restore the snapshot, the user doesn't need to download it again.

7. The user starts a temporary MongoDB instance on the target snapshot host. The fetched oplog is applied to the snapshot restored to this instance.

8. The user runs the MBRU to request the oplog.

9. The MBRU fetches the oplog for the point-in-time snapshot.

10. The MBRU applies the oplog to snapshot in the temporary MongoDB instance.

11. The user exports the restored database from the temporary MongoDB instance.