Atlas: run a point-in-time restore without making things worse

Point-in-time restore

Steps

1. Pick the restore point: the exact timestamp before the bad event. It must be inside the continuous backup oplog window; outside it, Atlas cannot do it.
2. Atlas UI: Backup, cluster, Restore, point in time. Restore to a NEW cluster, never over the production cluster. Restoring over production destroys the evidence and the rollback path.
3. Wait for the restore to finish. Large clusters take a while; the oplog replay is the long tail.
4. Verify: document counts on key collections, spot-check documents around the cutoff timestamp, confirm indexes exist, run the app smoke tests against the new cluster.
5. Cut over: update the connection string (env var, rolling deploy), watch metrics on the new cluster.
6. Keep the old cluster for a retention period before deleting, in case the restore point was wrong.

Rules

• Decide the restore point from evidence (logs, timestamps), not gut feel. Off by an hour can mean restoring the corruption too.
• Tell the team before cutover: writes to the old cluster after the restore point are lost. Freeze writes during the window.

Verify

The app serves correctly from the new cluster for a full cycle, and a second engineer independently confirms the data looks right.

Point-in-time restore procedure and the oplog window constraint per https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-snapshot/ and https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup/, verified 2026-09-26.