Point-in-time recovery restores a database to a chosen moment rather than only to the time of a saved snapshot. In Atlas, continuous cloud backup captures the oplog—a real-time record of write operations—so a cluster can be restored to a chosen minute within its retention window. section 21.1.1
Use it when a recent snapshot is not precise enough, such as after accidental deletion or data corruption. Choose a retention window that covers the incidents you need to recover from. Continuous backup is available for dedicated M10-and-higher clusters and may add storage and processing costs. section 21.5 section 21.1.1
For an Atlas dedicated cluster:
- Enable continuous cloud backup before an incident; a snapshot alone provides a saved backup point, not an arbitrary moment between snapshots. section 21.1.1 section 21.5
- Select a UTC time within the retained window and start a point-in-time restore with the Atlas CLI, specifying the source cluster and target cluster. section 21.1.1 section 21.1.2
- Keep reads and writes from interfering with restoration; verify the restored data before resuming normal application operations. section 21.1.2
atlas backups restores start pointInTime \
--clusterName MongoDB-in-Action-M10 \
--pointInTimeUTCSeconds 1588523147 \
--targetClusterName myRestoreDemo \
--targetProjectId 1a2345b67c8e9a12f3456de7
The `pointInTime` command supplies the selected moment as `--pointInTimeUTCSeconds` and identifies where the restored cluster should go. section 21.1.2
Cluster tier matters. M0 free clusters have no Cloud Backup snapshots, and Atlas `mongorestore` does not support `--oplogReplay` for recovering changes since a dump. Flex clusters use daily snapshots restored through the Atlas UI, rather than this dedicated-cluster CLI workflow. section 21.1.2 section 21.5
