Docs Home → MongoDB Cloud Manager
Restore a Deployment to MongoDB Atlas
On this page
You can automatically restore a backup for a Cloud Manager deployment to a MongoDB Atlas deployment. Atlas is a fully-managed cloud database that handles the complexities of deploying, managing, and healing deployments running on the AWS, Azure, and Google cloud providers.
Prerequisites
See Prerequisites for a list of prerequisites required for all automatic restores to Atlas deployments. In addition, you must have the following roles to perform this procedure:
Project Backup Admin
on the source Cloud Manager deploymentProject Owner
on the target Atlas deployment
If you have not yet created a destination Atlas cluster, see Create a Cluster.
Note
Your Atlas deployment must use M10 or larger instance nodes. Shared Cluster Tier deployments do not support restoring snapshots from Cloud Manager clusters.
You cannot restore a Cloud Manager backup snapshot to an Atlas deployment with Encryption at Rest enabled.
Considerations
Before you restore a snapshot from a Cloud Manager deployment to an Atlas deployment, ensure that the hosts for your Atlas deployment have sufficient storage space for the restored databases, plus additional space for dataset growth. Use db.stats() to find the current database size.
The MongoDB server version must be one of the following:
The same on both deployments.
One version higher on the Atlas deployment.
In addition, the instance types of the nodes in the Atlas deployment should have at least as much memory and throughput capacity as the nodes in the Cloud Manager deployment.
Procedure
Select the restore point.
Choose the point from which you want to restore your backup.
Restore TypeDescriptionActionSnapshotAllows you to choose one stored snapshot.Select an existing snapshot to restore.Point In TimeCreates a custom snapshot that includes all operations up to but not including the selected time. By default, the Oplog Store stores 24 hours of data.
Example
If you select
12:00
, the last operation in the restore is11:59:59
or earlier.Important
In FCV 4.0, you cannot perform a PIT restore that covers any time prior to the latest backup resync. For the conditions that cause a resync, see Resync a Backup. This note does not apply to FCV 4.2 or later.
Select a Date and Time.Oplog TimestampCreates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:
TimestampTimestamp in the number of seconds that have elapsed since the UNIX epoch
IncrementOrder of operation applied in that second as a 32-bit ordinal.Type an Oplog Timestamp and Increment.
Run a query against
local.oplog.rs
on your replica set to find the desired timestamp.Click Next.
To find the latest Oplog entry, run the following query
in mongosh
:
db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()
A successful result should look like this:
{ "ts": Timestamp(1537559320, 1), "h": NumberLong("-2447431566377702740"), "v": 2, "op": "n", "ns": "", "wall": ISODate("2018-09-21T19:48:40.708Z"), "o": { "msg": "initiating set" } }
The parts of the ts
value correspond to the values
you need for the Timestamp and
Increment boxes.
Note
To translate the epoch time into a human-readable timestamp, try using a tool like Epoch Converter
MongoDB does not endorse this service. Its reference is intended only as informational.
For more information about Atlas, see MongoDB Atlas.