Atlas: verify a backup restore before trusting it

Verify a restore

Symptom: you restored from a snapshot or point-in-time and need to trust it.

Diagnose what "done" means

Atlas marks the restore complete when the cluster is up, not when your data is verified. You need three checks: data completeness, index presence, and app behavior.

Confirm

1. data URIs - compare document counts on key collections against the source (or the pre-incident counts). Spot-check recent documents around the restore timestamp; for point-in-time restores, confirm the cutoff is where you expected (oplog window limits how far back you can go).
2. Indexes: list indexes on the restored cluster and diff against the source. Restores should carry indexes, but verify rather than assume.
3. App: point a staging backend at the restored cluster and run the read smoke tests plus one write path.

Fix

If counts mismatch, you restored the wrong snapshot or timestamp; redo from the right one. If indexes are missing, build them before cutover.

Verify

Only cut traffic over after all three checks pass. Keep the old cluster until the new one has served cleanly through a full cycle, then decommission.

Point-in-time restore workflow 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.