How to back up and restore MongoDB databases in production

mongodump and mongorestore

mongodump exports a database or individual collection to BSON files on disk. mongorestore reads those files back into a running MongoDB instance. These tools are the standard backup and restore mechanism for self-hosted MongoDB clusters and work reliably across major version upgrades.

# Full database backup — use dated directory for retention
mongodump \
  --uri="mongodb://user:pass@host:27017/shopDB" \
  --out=/backups/$(date +%Y-%m-%d)

# Backup a single collection
mongodump --uri="..." --collection=orders --out=/backups/

# Restore entire database from backup directory
mongorestore \
  --uri="mongodb://user:pass@host:27017" \
  /backups/2024-06-01/shopDB

# Restore with drop — wipe existing data before restoring
mongorestore --drop --uri="..." /backups/2024-06-01/shopDB

# Export to human-readable JSON (for inspection, not production backups)
mongoexport --uri="..." --collection=products --out=products.json

Production backup best practices

Always run mongodump targeting a secondary node to avoid adding read load to the primary serving live traffic. Pass the --oplog flag to capture a point-in-time consistent snapshot even across long-running dumps. Schedule daily backups to cloud object storage such as Amazon S3 or Google Cloud Storage, and verify restores monthly — an untested backup is not a valid backup. On MongoDB Atlas, enable Continuous Cloud Backup for point-in-time recovery down to the minute without managing any of this infrastructure manually.

One often overlooked aspect of backup strategy: verify the restore process on a staging environment at least once per month. A backup file that cannot be successfully restored is worthless. Document the exact restore commands, the expected restore duration for your data volume, and the steps to verify data integrity after restore so that during an actual incident the team is not learning the process under pressure for the first time.