Backup, restore and point-in-time recovery

conceptThe concept

Open the interactive lesson to use this diagram.

Point-in-time recovery = restore the latest full backup taken before the target time, then replay the oplog up to just before the bad operation (mongorestore --oplogReplay --oplogLimit <ts>, or pbm restore --time).

whyWhy it matters

Replication protects against hardware failure, not against db.orders.drop(), a bad migration or ransomware: those replicate instantly. Backups are the only protection, and an untested backup is a hope, not a plan.

Use caseReal-world scenario

At 14:05 an engineer runs a deleteMany with a wrong filter. The team finds the exact oplog timestamp of the first delete, restores last night's PBM snapshot to a new cluster, replays oplog slices up to 14:04:59, validates counts, and copies the affected collection back. RPO: zero data loss up to the bad operation; RTO: 45 minutes, matching the last drill.

Try itExamples

Run and edit these in the interactive lesson.

# consistent dump of a replica set, compressed, with oplog
mongodump --uri "mongodb://backup:***@mongo-1:27017/?replicaSet=rs0&readPreference=secondary" \
  --oplog --gzip --out /backups/2026-09-29

# restore one collection into a scratch database
mongorestore --uri "mongodb://restore:***@scratch:27017" --gzip \
  --nsInclude "shop.orders" --nsFrom "shop.orders" --nsTo "restore_check.orders" /backups/2026-09-29

# point-in-time: replay oplog up to just before the bad operation
mongorestore --oplogReplay --oplogLimit 1790000000:1 /backups/2026-09-29

pbm config --file /etc/pbm/storage.yaml     # S3 bucket, prefix, credentials
pbm config --set pitr.enabled=true          # continuous oplog slices
pbm backup --type=physical                  # or logical / incremental
pbm list                                    # backups + PITR ranges
pbm restore --time="2026-09-29T14:04:59"    # point-in-time restore
pbm status

db.lab_victim.drop()
db.lab_victim.insertMany([{ n: 1 }, { n: 2 }, { n: 3 }])
db.lab_victim.deleteMany({})
db.getSiblingDB("local").oplog.rs.find({ ns: "shop.lab_victim", op: "d" }, { ts: 1, op: 1, o: 1 }).sort({ $natural: 1 }).limit(1)

internalsUnder the hood

mongodump --oplog captures oplog entries written during the dump so the restore (--oplogReplay) is consistent to a single point for a replica set. For sharded clusters, a consistent backup needs coordination across shards and config servers (PBM and Ops Manager do this; manual snapshots require stopping the balancer and taking snapshots close together, which is only approximately consistent). Restoring to a cluster with a different topology or name needs care with config metadata.

Avoid / preferDo this, not that

mongodump --uri "$URI" --out /backup   # replica set, no --oplog

mongodump --uri "$URI" --oplog --gzip --archive=/backup/shop-$(date +%F).gz

# backups run nightly; nobody has ever restored one

mongorestore --uri "$STAGING_URI" --oplogReplay --gzip --archive=/backup/shop-2026-10-08.gz
mongosh "$STAGING_URI" --eval 'db.getSiblingDB("shop").orders.countDocuments()'

PitfallsCommon mistakes

• Treating replicas as backups.
• Never testing restores; discovering during an incident that backups are incomplete or take 3 days to restore.
• Backups stored in the same account/region with the same credentials as production (ransomware, region loss).
• Snapshotting data without the journal volume or without fsyncLock.
• Running mongodump against the primary of a busy cluster during peak hours.

LimitsWhen not to use it

mongodump is fine up to tens of gigabytes. For terabytes it is too slow to dump and far too slow to restore, because every index is rebuilt. Use physical backups (Percona Backup for MongoDB physical mode, filesystem snapshots, or Ops Manager) and point-in-time recovery from oplog slices.

SecuritySecurity notes

A backup is a full copy of your data. Encrypt it in transit and at rest, use the built-in backup role rather than root, and keep at least one copy where production credentials cannot delete it: ransomware goes after reachable backups first.

ChallengeTry it yourself

db.getCollectionNames().map(c => {
  const s = db.getCollection(c).stats()
  return { coll: c, dataMB: +(s.size / 1048576).toFixed(2), indexMB: +(s.totalIndexSize / 1048576).toFixed(2) }
})

InterviewQuestions you should be able to answer

QuizCheck your understanding

4 questions with instant feedback in the interactive lesson; a wrong answer goes into your review deck.