MongoDBBackup & Restore

Backup and Restore

A backup you have never restored is a hypothesis, not a safety net. This page covers the tools — mongodump/mongorestore, mongoexport/mongoimport, and Atlas's managed backups — and the practice of actually rehearsing a restore.

mongodump / mongorestore — BSON

mongodump exports data in BSON, preserving every type exactly (ObjectId, Date, Decimal128, etc.) — the right tool for a real backup, as opposed to a human-readable export.

Bash
# Full deployment dump
mongodump --uri="mongodb://localhost:27017" --out=./backup

# Single database
mongodump --uri="mongodb://localhost:27017" --db=shop --out=./backup

# Single collection
mongodump --db=shop --collection=orders --out=./backup

# Only documents matching a query
mongodump --db=shop --collection=orders \
  --query='{"status":"shipped"}' --out=./backup

# Compressed, single-file archive — convenient for storage/transfer
mongodump --uri="mongodb://localhost:27017" --archive=backup.gz --gzip

Bash
# Restore everything from a directory dump
mongorestore --uri="mongodb://localhost:27017" ./backup

# Restore a single database, dropping existing collections first
mongorestore --db=shop --drop ./backup/shop

# Restore from a compressed archive
mongorestore --archive=backup.gz --gzip
The --oplog Flag — Point-in-Time Consistency

A plain mongodump of a busy database can capture different collections at slightly different moments as data keeps changing during the dump — producing an internally inconsistent snapshot. --oplog records the oplog during the dump and replays it on restore, bringing every collection to the exact same point in time.

Bash
mongodump --uri="mongodb://localhost:27017" --oplog --out=./backup
mongorestore --oplogReplay ./backup
Warning
--oplog only works against a replica set (it reads the oplog) and only guarantees consistency for the duration the dump takes — it does not turn mongodump into a continuous backup solution. For always-on point-in-time recovery, use Atlas Continuous Backups or a filesystem/volume snapshot strategy.
mongoexport / mongoimport — JSON / CSV

mongoexport/mongoimport work with JSON or CSV — human-readable and easy to inspect or hand-edit, but they lose some BSON type fidelity (e.g. a Date may round-trip as a string unless you use MongoDB Extended JSON). Use these for interop with non-MongoDB tools, one-off data loads, or spreadsheets — not as your backup strategy.

Bash
mongoexport --uri="mongodb://localhost:27017/shop" \
  --collection=users --out=users.json

mongoimport --uri="mongodb://localhost:27017/shop" \
  --collection=users --file=users.json

# CSV
mongoexport --db=shop --collection=users --type=csv \
  --fields=name,email,createdAt --out=users.csv

mongoimport --db=shop --collection=users --type=csv \
  --headerline --file=users.csv
mongodump/export Comparison

mongodump / mongorestore

mongoexport / mongoimport

Format

BSON (binary)

JSON or CSV (text)

Type fidelity

Exact (ObjectId, Date, Decimal128, etc.)

Approximate unless using Extended JSON

Human readable

No

Yes

Point-in-time consistency

Yes, with --oplog

No

Typical use

Backups, environment cloning

Interop, data migration to other tools, quick edits

Atlas Backups

Atlas offers fully managed Continuous Backups with point-in-time restore (PITR) — instead of discrete daily snapshots, Atlas continuously records the oplog and lets you restore to nearly any second within the retention window, not just a snapshot boundary.

  • Snapshots taken on a configurable schedule (e.g. every 6 hours) plus continuous oplog capture in between.

  • Point-in-time restore to any moment within the retention window — useful for recovering from an accidental delete/update a few minutes after it happened.

  • Restores can target a new cluster (safe, non-destructive) or, with care, the same cluster.

  • Backups are stored in a separate region/cloud account boundary from the primary cluster, protecting against a regional outage taking out both.

Tip
For any accidental-delete incident, restoring to a NEW cluster and then selectively copying the recovered documents back is almost always safer than restoring in place — it avoids compounding the mistake with a bad restore.
Restore Drills

A backup strategy is only as good as your last verified restore. Schedule regular drills:

  • Restore the latest backup into an isolated environment on a regular cadence (monthly, or after any major schema change).

  • Verify document counts, spot-check a sample of records, and confirm indexes were recreated.

  • Time the restore — know how long a full recovery actually takes, so your recovery time objective (RTO) is based on evidence, not hope.

  • Test the oplog replay / PITR path specifically, not just a plain snapshot restore — it exercises a different code path and is where surprises hide.

Summary

  • mongodump/mongorestore (BSON) is the right tool for real backups — add --oplog for point-in-time consistency across collections.

  • mongoexport/mongoimport (JSON/CSV) are for interop and one-off data movement, not backup strategy.

  • Atlas Continuous Backups add scheduled snapshots plus point-in-time restore without any manual tooling.

  • A restore drill you have actually run beats a backup schedule you merely trust.