Backup, Restore, and Data Recovery
This domain tests backup design and restore execution: what Atlas protects, how far back you can recover, and how to prove recovery works.
Core rules
- Atlas-managed cloud backups and point-in-time restore require dedicated M10+ clusters. Free and shared tiers do not provide Atlas continuous backups, so use logical dumps if needed.
- Continuous backup captures snapshots plus oplog, enabling PITR to a timestamp. The recoverable window is set by the oplog window, which depends on write volume and cluster resources, not a fixed 24 hours.
- Snapshot schedules define frequency and retention. A backup compliance policy locks retention and prevents snapshot deletion; plan it before production.
- Restore options include same cluster, new cluster, and snapshot download. Restoring over the same cluster overwrites data and can cause downtime; restore to a new cluster for verification and cutover.
- Backups are encrypted; with BYOK, deleting or disabling the KMS key can make restores impossible.
Worked example
A team needs RPO 15 minutes and RTO 2 hours. Enable continuous cloud backup on an M30 cluster and confirm the oplog window exceeds 24 hours. Schedule a restore drill to a new cluster, replay to a timestamp before a simulated bad deploy, run validation queries, then document cutover. If the oplog window is only 30 minutes under peak writes, the stated RPO is at risk; reduce write load or adjust the cluster before relying on PITR.
Traps
Assuming PITR always reaches 24 hours; restoring directly over production without a test; treating snapshots as immutable without a compliance policy; forgetting that deleted KMS keys break restores; never measuring actual restore time.