Docs Menu

Docs HomeMongoDB Cloud Manager

Restore a Deployment to MongoDB Atlas

On this page

  • Prerequisites
  • Considerations
  • Procedure

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.

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:

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.

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.

1
2
3
  1. Choose the point from which you want to restore your backup.

    Restore Type
    Description
    Action
    Snapshot
    Allows you to choose one stored snapshot.
    Select an existing snapshot to restore.
    Point In Time

    Creates 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 is 11: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 Timestamp

    Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:

    Timestamp
    Increment
    Order 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.

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

4
5
6
7
8

Verify your Cloud Manager password.

For more information about Atlas, see MongoDB Atlas.

←  Migrate a MongoDB Community Deployment to AtlasMonitor Your Deployments →