Docs Menu

Restore Your Database Deployment

On this page

Note
Feature Unavailable in Free-Tier Clusters

This feature is not available for M0 free clusters. To learn more about which features are unavailable, see Atlas M0 (Free Cluster), M2, and M5 Limitations.

Atlas lets you restore data from a scheduled Cloud Backup.

Note

You must have the Project Owner role for the Atlas projects that contain the source and target clusters to restore data from one Atlas cluster to another.

Tip
See also:
  • The target cluster must run the same or the next major release version of MongoDB as the snapshot MongoDB version.

    Example

    You can restore a MongoDB 4.2 snapshot to an Atlas cluster running MongoDB 4.4. If you try to restore a MongoDB 4.2 snapshot to an Atlas cluster running MongoDB 5.0, you receive the following error:

    Error: The requested restore could not be started: The source and destination
    mongoDB versions are incompatible.
  • The source and target sharded cluster must have the same number of shards.
  • Atlas can only restore to a replica set or sharded cluster that uses the same encryption provider as the source snapshot cluster.
  • Atlas can't restore a sharded cluster snapshot to a replica set.

If a scheduled snapshot fails for any reason, Atlas attempts to repeat the snapshot process. If necessary, you may use the resulting fallback snapshot to restore the cluster. This isn't recommended: fallback snapshots use a different process from regular snapshots. They may contain inconsistent data.

Fallback snapshots are marked in the UI with a warning icon, and a warning message appears in the restore modal window if the restore uses a fallback snapshot.

Warning

Restoring your cluster from a fallback snapshot may result in inconsistent data across your cluster, and should be considered an option of last resort.

You must ensure that the target Atlas cluster does not receive client requests during restoration. You must either:

  • Restore to a new Atlas cluster and reconfigure your application to use that new cluster once the new deployment is running, or
  • Ensure that the target Atlas cluster cannot receive client requests while you restore data.
Important
Restoring Snapshots for Clusters using Encryption at Rest

Atlas automatically encrypts Cloud Backups for clusters using Encryption at Rest using Customer Key Management, in addition to the existing encryption applied to all Atlas storage and snapshot volumes. For documentation on restoring an encrypted snapshot, see Restore a Snapshot of a Cluster with Encryption at Rest

The following instructions only apply to snapshots for clusters not using Encryption at Rest.

Important

Atlas deletes all existing data on the target cluster prior to the restore. The cluster will be unavailable for the duration of the restore.

  1. Click Restore in the Actions column for the snapshot you want to restore.
  2. From the Restore dialog, select the target cluster to which you want to restore.

    Note

    To optimize performance and reduce the amount of time it takes to restore, use these tips:

    • Select a target cluster that isn't a global, multi-region, or multi-cloud cluster.
    • Select a target cluster that belongs to the same Atlas project and the same cloud provider region as the snapshot.
    • Select a cluster tier with the same storage capacity as the capacity of the original volume used by the source cluster.
    • If the target cluster runs on AWS with configured IOPS, select the configured IOPS to fall within the valid range.
    • Select a tier that hasn't been configured to use NVMe storage. The tier can support NVMe storage, but if you enable NVMe, restore performance degrades.
  3. Click Restore.
  4. Restart your application and ensure it uses the new target cluster.
Important

Snapshots of clusters using Encryption at Rest using your Key Management can only restore to other clusters that use Encryption at Rest. You cannot restore a snapshot with Encryption at Rest to a Cloud Manager project.

If the target project does not have a cluster with Encryption at Rest enabled, you can either deploy a cluster with Encryption at Rest, or enable Encryption at Rest in an existing cluster.

Clusters which use AWS KMS encrypt their PIT restore oplog data with the customer's CMK. The current CMK must be valid for the encrypted oplog data to perform a restore from a snapshot.

  1. Click Databases in the top-left corner of Atlas.
  2. From the Database Deployments view, click on the cluster name.
  3. Click the Backup tab.

    If the cluster has no Backup tab, then Atlas backups are disabled for that cluster and no snapshots are available. You can enable backups when modifying the cluster.

  4. Click Restore in the Actions column for the snapshot you want to restore.
  5. From the Restore dialog, select the target Atlas Project to which you want to restore. You can restore to any Atlas project for which the authenticated Atlas user has the Project Owner role.
  6. Select the Cluster to restore to. You can only restore to an Atlas replica set running Encryption at Rest. The target cluster must run the same or greater version of MongoDB as the MongoDB Version of the snapshot.

    After the restoration procedure, Atlas triggers a key rotation for MongoDB encryption key. Atlas then encrypts the new MongoDB encryption keys based on the configured Encryption at Rest provider for the target cluster.

  7. Restart your application and ensure it uses the new target cluster.

If Atlas has an issue with the encryption of either the snapshot or the target cluster, it displays one of the following errors:

Error
Result
Cannot restore a non-encrypted snapshot to a cluster with Encryption at Rest enabled.
The snapshot cannot be restored to Atlas.
Target cluster does not have encryption enabled.
You can either deploy a new target cluster with Encryption at Rest, or enable Encryption at Rest on your desired target cluster.
Encryption provider of target cluster does not match selected snapshot's encryption provider.

The encryption provider for the snapshot and target cluster do not match. You can either:

  1. Create a new snapshot with the same encryption provider.
  2. Change the encryption provider for the target cluster.
Encryption credentials on snapshot are not present.
Atlas cannot restore a snapshot whose encryption key was deleted.

Atlas provides a detailed list of completed and in-progress snapshot restorations, including when Atlas took the snapshot and the snapshot's delivery type. To view this list, from a cluster's Backup tab, click the Restores & Downloads tab.

The Status column of the table displays the results of completed snapshots, and the progress of snapshots currently being restored.

  • For manually downloaded snapshots, the Status column displays progress while Atlas prepares the download link. Once the download is ready, the column displays the link to download the snapshot.
  • For automated restores and Continuous Cloud Backup restores, the Status column updates as the restoration progresses on each node in the cluster. When the restoration completes, the column displays the time of completion and the cluster to which Atlas restored the snapshot.

Atlas lets you restore data from an M2 or M5 cluster snapshot. You can restore M2 and M5 snapshots to a cluster tier M2 or greater.

Note

You must have the Project Owner role for the Atlas projects that contain the source and target clusters to restore data from one Atlas cluster to another.

  • Atlas can restore M2 and M5 snapshots only to a replica set that does not use Encryption at Rest.
  • The target cluster must run the same major release version of MongoDB as the snapshot MongoDB version. For example, you can restore a snapshot using MongoDB 4.0 only to a target cluster running MongoDB 4.0.
  • Starting with MongoDB 5.0, you can restore snapshots of clusters that run only the two most recent major versions of MongoDB to M2 and M5 clusters.

    Example
    • You can restore snapshots taken from clusters that run MongoDB 4.2 to an M2 or M5 cluster that runs MongoDB 5.0.
    • You can't restore snapshots taken from clusters that run MongoDB 4.0 to an M2 or M5 cluster that runs MongoDB 5.0.
  1. You must ensure that the target Atlas cluster does not receive client requests during restoration. You must either:
    • Restore to a new Atlas cluster and reconfigure your application to use that new cluster once the new deployment is running, or
    • Ensure that the target Atlas cluster cannot receive client requests while you restore data.
  2. To download your snapshot via HTTPS, you must add the IP or CIDR addresses of the client downloading the snapshot to your Atlas project access list.
  1. Click Databases in the top-left corner of the {atlas-ui+}.
  2. From the Database Deployments view, click the {+cluster_} name.
  3. Click the Backup tab.
  4. Find the desired cluster snapshot to restore.
  5. For the desired cluster, click Restore or Download.
  6. Follow the prompts to restore your cluster. You may choose to one of the following actions:

Important

Atlas deletes all existing data on the target cluster prior to the restore. The cluster will be unavailable for the duration of the restore.

You can restore to any Atlas cluster in a project for which you have the Project Owner role.

  1. In the Snapshots tab, locate the snapshot to restore in the All Daily Snapshots table.
  2. In the Actions column of the table, click Restore.
  3. From the Restore dialog, select the target cluster to restore to.
  4. Click Restore.
  5. Restart your application and ensure it uses the new target cluster.

Atlas lets you restore data to a serverless instance from a snapshot.

Note

You must have the Project Owner role for the Atlas projects that contain the source and target clusters to restore data from one Atlas cluster to another.

To learn more, see Serverless Instance Backups.

  • If you use Basic Backup, you can restore from only the two most recent snapshots of a serverless instance.
  • If you use Serverless Continuous Backup, you can restore your data to a selected point in time using only Date & Time.
  • You can't restore snapshots from shared clusters, dedicated clusters, or from Cloud Manager to serverless instances.

You must ensure that the target serverless instance doesn't receive client requests during restoration. You can restore to a new serverless instance and reconfigure your application to use that new serverless instance once it is running for maximum uptime.

Important

Atlas disables database users on a target serverless instance during a restore to prevent the target from receiving client requests.

Warning

Atlas deletes all existing data on the target serverless instance prior to the restore. The serverless instance is unavailable for the duration of the restore.

Follow these steps to restore a database deployment from a serverless instance snapshot.

  1. Click Restore in the Actions column for the snapshot to restore.
  2. From the Restore dialog, select the target serverless instance to restore to.

    Note

    For best possible restore performance, select a target serverless instance that belongs to one of the following options:

    • The same Atlas project as the snapshot.
    • The same cloud provider region as the snapshot.
  3. Click Restore.
  4. Restart your application and ensure it uses the new target cluster.

Atlas provides a detailed list of completed and in-progress snapshot restorations, including when Atlas took the snapshot and the snapshot's delivery type. To view this list, from a serverless instance's Backup tab, click the Restores tab.

The Status column of the table displays the results of completed snapshots, and the progress of snapshots currently restoring.

The Status column updates as the restoration progresses on the serverless instance. When the restoration completes, the column displays the time of completion and the serverless instance that Atlas restored the snapshot to.

Note

This feature is not available for M0 free clusters. For more information, see Atlas M0 free cluster Limitations.

Atlas provides a mechanism for downloading cloud provider, legacy backup, and M2/M5 snapshots as compressed files.

Note

You can't download snapshots for serverless instances.

The downloaded files consist of the raw files copied from the data directory. mongorestore is incompatible with these files. To access the data files, use the following procedure to start a mongod instance and point it to the extract directory.

You can automatically restore a backup for a Cloud Manager deployment to an Atlas deployment. 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.

Also, 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.

To learn more, see Restoring a Deployment to MongoDB Atlas.

←  Export Cloud Backup SnapshotImport Archive from S3 →
Give Feedback
© 2022 MongoDB, Inc.

About

  • Careers
  • Investor Relations
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2022 MongoDB, Inc.