Back up, observe, and recover

A backup is useful only when you can restore it. Plenty of teams discover at the worst moment that their backups were empty, partial, or three weeks old. So this lesson works backwards: define what recovery must achieve, then pick tools, then prove they work.

Start with two numbers. How much data can you afford to lose (recovery point)? How long can you be down (recovery time)? “One hour of data, back within thirty minutes” leads to very different tooling than “yesterday’s snapshot is fine.”

On Atlas, enable scheduled backups and, if your recovery point is tight, continuous backup with point-in-time restore. Self-managed, the starting tool is mongodump:

mongodump --uri="mongodb://backup_user:s3cret@localhost:27017/animals" \
  --out=/backups/animals-2026-08-03
# writes BSON + metadata per collection

For anything beyond small databases, prefer filesystem snapshots or Atlas backups — mongodump reads everything through the server and gets slow at scale. Whatever you pick, know the backup’s consistency point: a dump of a live server captures collections at slightly different moments unless you use oplog options or snapshot-based tooling. A backup whose consistency point you cannot state is a guess.

Remember replication is not backup. A replica set faithfully replicates your accidental deleteMany({}) to every member within milliseconds. Only a backup holds the state from before the mistake.

Watch the signals that predict trouble

Monitor connections, operation rates, replication lag, storage growth, cache pressure, slow queries, and failed backups. Atlas exposes these as metrics and alerts; self-managed setups can scrape them from db.serverStatus(). Keep alerts tied to user-visible risk: “replication lag above 60 seconds” and “backup job failed” deserve a page. A dashboard where every moving number alerts trains everyone to ignore it.

The drill

Restore a disposable backup into a separate environment — never over the production database:

mongorestore --uri="mongodb://localhost:27018" --drop /backups/animals-2026-08-03
# 1240 document(s) restored successfully. 0 document(s) failed.

Then verify like you mean it: compare db.animals.countDocuments({}) against the source, and run one real application workflow against the restored data. Write down the steps and how long they took — that document is your runbook, and the recovery time you measured is the only one that counts.