Backup, restore and operational tooling
Pick a backup method from your recovery target rather than from convenience, restore into a scratch namespace first, and monitor the signals that predict trouble.
The backup methods
| Method | Recovery point | Notes |
|---|---|---|
mongodump / mongorestore | Up to the dump | Logical and portable; slow to restore at scale |
| Filesystem or volume snapshot | Up to the snapshot | Fast, but needs a consistent stop or a journal flush |
| Atlas continuous backup | Seconds, with the oplog | Restores to an arbitrary point inside the window |
| Delayed replica member | A fixed lag behind | A live copy you can promote without a restore step |
| Oplog replay after a dump | Just before the event | Only as far back as the retained oplog |
mongodump --uri "mongodb+srv://user:[email protected]/shop" \
--out /backups/2026-09-18 --gzip --oplog
mongorestore --uri "mongodb://localhost:27017" \
--gzip --oplogReplay --drop /backups/2026-09-18
# single-archive form, easier to move and encrypt
mongodump --uri "$URI" --archive=shop.archive --gzipRestoring without surprises
- Restore into a scratch namespace with
--nsFromand--nsTo, never over the live database. - Compare counts and an aggregate checksum on a few important collections against the source.
- Run the application against the restored copy and confirm the queries it depends on work.
- Only then promote it, and record how long the whole exercise took — that number is your real recovery time.
db.orders.countDocuments({})
db.orders.aggregate([
{ $group: { _id: null, total: { $sum: "$total" }, orders: { $sum: 1 } } }
])mongorestorerebuilds indexes by default;--noIndexRestoreis faster for a bulk load you intend to index afterwards.- Restoring a single collection is often all you need after a bad script, and it is far cheaper than a full restore.
- A restore is a load test. It also tells you whether the indexes and the document count match what the application expects.
Monitoring and the operational basics
| Signal | Why it matters |
|---|---|
connections in serverStatus | Approaching the limit means requests queue and then time out |
| Replication lag | Read preference correctness and failover readiness |
| Oplog window | How far a consumer or a backup can fall behind |
db.currentOp() | Long-running operations, and the indexes they are missing |
| Disk free space | WiredTiger needs room to write new journals and to compact |
| Cache eviction and page faults | The working set no longer fits in RAM |
⚠️
A backup becomes a backup only once it has been restored. Schedule the restore drill, restore into a scratch namespace, and record the elapsed time. During an incident the number you need is recovery time, not backup size.
FAQ
How often should I back up?
Work backwards from the recovery point objective: how much data can the business afford to lose? Continuous oplog-based backup gives seconds, a nightly dump gives up to a day. The schedule follows from that answer rather than from what is convenient.
Is a delayed replica a backup?
It is a useful second line of defence against an accidental delete, because you can promote it after the damage has replicated. It is not a backup: it lives on the same platform, shares the same credentials, and cannot restore one collection to a chosen point in time.
Related
Replica sets, failover and read preferences Setting up MongoDB: Atlas, local install and mongosh
Last refreshed 2026-09-18.