A backup is a recoverable copy of database data. Recent backups can limit disruption after accidental deletion, corruption, or failure. Secure offline backups also provide a recovery option after ransomware, while regular backups help preserve records needed for audits. section 21.1
Atlas Cloud Backup can restore a cluster from a scheduled or on-demand snapshot, either to its original cluster or to another cluster. The destination matters: for a Cloud Backup restore, Atlas removes the target cluster’s existing data before rebuilding it to the chosen backup point. The cluster is temporarily offline during restoration. section 21.1.2
Choose a recovery path before you need it:
- For an Atlas cluster with a suitable snapshot, select the snapshot and target cluster, then start an automated restore. An alternative target can support restore testing or disaster-recovery preparation. section 21.1.2
- For a point-in-time restore, specify the desired UTC time and target cluster instead of a snapshot ID. section 21.1.2
- For a free M0 cluster, use mongorestore with a dump created by mongodump; M0 does not offer cloud backup snapshots. Check the tool’s Atlas-specific limitations before relying on it. section 21.1.2
- Test the restore procedure regularly. A backup is useful only if the recovery path works when data is lost. section 21.1.2
atlas backups restores start automated \ --clusterName "MongoDB-in-Action-M10" \ --targetClusterName "MongoDB-in-Action-M10" \ --snapshotId 6725be13eae896510f35a553 \ --targetProjectId 65d70c5bc9b5633e80a9c998
An automated Atlas CLI restore identifies the source cluster, destination cluster, snapshot, and target project. Confirm the destination before running it: an in-place Cloud Backup restore replaces its existing data. section 21.1.2
atlas backups restores start pointInTime \
--clusterName MongoDB-in-Action-M10 \
--pointInTimeUTCSeconds 1588523147 \
--targetClusterName myRestoreDemo \
--targetProjectId 1a2345b67c8e9a12f3456de7
A point-in-time restore uses --pointInTimeUTCSeconds in place of --snapshotId and names a target cluster and project. section 21.1.2
Do not treat Atlas Online Archive as the primary backup. It keeps infrequently accessed data in lower-cost, queryable storage rather than providing comprehensive recovery snapshots. Archived data can be moved back to a live cluster with a $merge pipeline, but that is a separate workflow: pause the archive, prepare a unique index to avoid duplicates, and ensure the destination has enough capacity. This approach is not advisable for large datasets of approximately 1 TB with many partitions. section 17.0 section 17.4
