MongoDB backup.

mongodump

mongodump --uri="mongodb://host/db" --out=./dump
mongodump --db=myapp --out=./dump
mongodump --collection=users --db=myapp
mongodump --archive=backup.archive --gzip
mongodump --uri="..." --archive=- | aws s3 cp - s3://bucket/backup.archive

mongorestore

mongorestore --uri="..." ./dump
mongorestore --archive=backup.archive --gzip
mongorestore --drop ./dump        # drop existing first
mongorestore --nsInclude="myapp.users"

Snapshot-based (preferred at scale)

EBS / GCP PD snapshots while DB consistent:

# Fsync + lock for consistent snapshot
mongo --eval 'db.fsyncLock()'
# Take cloud snapshot
mongo --eval 'db.fsyncUnlock()'

Or use a hidden delayed replica + snapshot from it.

Point-in-time recovery (PITR)

Atlas / Ops Manager / Cloud Manager features. Snapshot + replay oplog.

Manual:

  1. Restore latest snapshot.
  2. Apply oplog up to target timestamp.

Backup strategy

  • Daily full backup.
  • Continuous oplog tailing for PITR.
  • 30-day retention.
  • Off-site (different region / S3).
  • Monthly restore test.

Atlas

Built-in continuous backups with PITR (paid tier).

Encryption

Server-side: enable WiredTiger encryption at rest.

Backups: encrypt before upload.

mongodump --archive=- | openssl enc -aes-256-cbc -salt -pass file:./key | aws s3 cp - s3://bucket/backup

Performance impact

mongodump on primary → I/O. Run on hidden secondary if possible.

Restore verification

mongorestore --dryRun --archive=backup.archive --gzip

Then real restore + verify counts:

db.users.countDocuments()

Common mistakes

  • Backups never restored as test.
  • mongodump on busy primary → impact.
  • Skipping oplog → PITR impossible.
  • No off-site copy.
  • Old snapshots accumulating (cost).

Read this next

If you want my backup automation, it’s at rajpoot.dev .

Building something AI-, backend-, or data-heavy and want a second pair of eyes? I do consulting and freelance work — see my projects and ways to reach me at rajpoot.dev .