> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Restore from Continuous Cloud Backup Atlas lets you restore data from a [Continuous Cloud Backup](https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup.md#std-label-pit-restore) by specifying one of the following options: - A specific date and time to which you want to restore - A specific [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) entry from which you want to restore You can restore [selected databases or collections](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-db-coll.md#std-label-restore-from-db-coll) from a continuous cloud backup. To learn more, see [Restore from Selected Databases and Collections.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-db-coll.md#std-label-restore-from-db-coll) **Note:** This page applies to Atlas Core only. To learn about Atlas Infinite restores, see [Restore an Atlas Infinite Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/atlas-infinite-restore.md#std-label-atlas-infinite-restore) ## Restore Considerations In addition to the [prerequisites](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview.md#std-label-restore-prereq) consider the following requirements and limitations when restoring from a [Continuous Cloud Backup.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup.md#std-label-pit-restore) - If the `DefaultRWConcern` value on the source snapshot differs from the `DefaultRWConcern` value on the target cluster, Atlas overrides the value on the source snapshot with the value on the target cluster. If there is no value configured for the `DefaultRWConcern` on the target cluster, Atlas keeps the value of `DefaultRWConcern` from the snapshot without explicit configuration. This may differ from the default value for that MongoDB version. This feature is only available for `M10+` dedicated clusters. ## Requirements for Using Faster Cross-Project Restores - For `M10+` dedicated clusters, Atlas restores MongoDB Search [index definitions](https://www.mongodb.com/docs/search/indexes/index-definitions.md#std-label-ref-index-definitions) from a Cloud Backup snapshot. Atlas doesn't restore search index data, so the `mongot` processes perform [initial syncs](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) for all restored search index definitions. If you've defined large search indexes on your cluster, you might experience delays during snapshot restorations. **Note:** The MongoDB Search index definitions captured at the snapshot time specified for the point in time restore replace any existing MongoDB Search index definitions. ### General Optimizations To take advantage of faster cross-project restores and to optimize performance and reduce the amount of time it takes to restore, you must follow all of these principles where they are applicable: - Select a target cluster that isn't global or multi-cloud. - Select a multi-region target cluster only if copies of the snapshot you plan to restore exist in every region of that cluster. - Select a target cluster that belongs to 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 (Amazon Web Services) with configured IOPS (Input/Output Operations per Second), select the configured IOPS (Input/Output Operations per Second) to fall within the configured range. - Select a target cluster that is not configured to use NVMe (non-volatile memory express) storage. NVMe (non-volatile memory express) storage degrades restore performance. - For AWS (Amazon Web Services) source clusters created before March 27, 2024, click the Faster Restore button in the cluster's [Backup](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fbackup%2Fclusters) details in Atlas UI to enable faster cross-project restores using the direct attach restore method. The target cluster must meet all conditions listed in this section to use this feature. When you activate Faster Restore, Atlas replaces each node in the source cluster one at a time during your next [maintenance window](https://www.mongodb.com/docs/atlas/tutorial/cluster-maintenance-window.md#std-label-configure-maintenance-window). If the maintenance window ends before all nodes are replaced, Atlas finishes replacing the current node, then waits for the next maintenance window to start replacing the next node. Secondary reads and analytic nodes are unavailable during the rolling replacement. Faster cross-project restores are automatically enabled for AWS (Amazon Web Services) clusters created after March 27, 2024, all Google Cloud and Microsoft Azure clusters, and all clusters in MongoDB Atlas for Government. If this feature is enabled for your cluster, the Faster Restore button doesn't appear. ## Required Access To monitor a backup restore job until it completes, you must have [`Project Read Only`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Read-Only) access or higher to the specific project. To start a restore job, you must have [`Project Backup Recovery Operator`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Recovery-Operator), [`Project Backup Manager`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Manager), or [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) access to the project. For cross-organization or cross-project restores, the required permissions apply to both the source and target projects. You must have the necessary permissions: [`Project Backup Manager`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Manager) or [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) in both projects to initiate or manage such restore operations. To restore an encrypted or unencrypted snapshot created in an Atlas project to the same project, you require the [`Project Backup Manager`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Manager) role. To restore an encrypted or unencrypted snapshot created in a source Atlas project to a different target project, you require the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) role in the target project. ## Procedure When you perform a cluster-level restore, Atlas deletes all existing data on the target cluster before the restore. The target cluster is unavailable for the duration of the restore. As part of the restore, Atlas also restores any indexes. This does *not* apply to collection- and database-level restore. To start a restore job for your project and cluster using the Atlas CLI, run the following command: ```sh atlas backups restores start [options] ``` To watch for a specific restore job to complete using the Atlas CLI, run the following command: ```sh atlas backups restores watch [options] ``` To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for [atlas backups restores start](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-restores-start/) and [atlas backups restores watch.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-restores-watch/) **See also: Related Links** - [Install the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/install-atlas-cli/) - [Connect to the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/connect-atlas-cli/) The Atlas Administration API provides an endpoint for restoring `M10+` clusters. [Restore One Snapshot of One Cluster](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-creategroupclusterbackuprestorejob) To restore a cluster from a PIT backup, set the `deliveryType` field to `pointInTime`. You can enable Continuous Cloud Backups for dedicated clusters when you [create](https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster.md#std-label-create-new-cluster) or [scale](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-backups) a cluster. 1. In Atlas, go to the Backup details for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Backup under the Database heading. The [Backup](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fbackup%2Fclusters) details display. Click the cluster link. 2. Click Point in Time Restore. Click the Point in Time Restore button on the far right side of the screen. 3. Select either the Date & Time or Oplog Timestamp tab. If you select the Date & Time option, you can specify the time of restore with one minute of granularity. If you select the Oplog Timestamp option, you can specify the time of restore with one second of granularity. 4. Enter the desired point in time to restore from. **Important:** You can restore a cluster from any time during its continuous cloud backup window **except** between when you initiated a restore and when Atlas completes a snapshot after the restore. 5. Click the Next: Select Cluster button. 6. Choose a project and cluster to restore to from the dropdown menus. **Important:** Atlas might create a host rollback alert due to differences in the data between the source and target clusters. You can ignore this alert. 7. Click the Restore button.