MongoDB Backup Strategies

Tip: mongodump

mongodump --db myapp --out /backup/

Gotcha: mongodump Locks

mongodump doesn't lock the database but can impact performance during backup.

Tip: mongorestore

mongorestore --db myapp /backup/myapp/

Gotcha: Oplog for Point-in-Time

With oplog, you can restore to any point in time. Requires replica set.

Tip: MongoDB Atlas Backups

Atlas provides automated continuous backups with point-in-time recovery.

Gotcha: Backup Size

MongoDB backups can be large. Compress with --gzip flag.

Tip: Embed or Reference? The 80/20 Rule

If you always access data together, embed it. If you access it independently, reference it. The 16MB document size limit is the hard boundary — stay under 1MB for most documents.

Tip: Index Your Query Patterns, Not All Fields

Creating indexes on every field wastes RAM. Use explain() to find in-memory sorts and collection scans. Index only what your actual queries filter on.

Gotcha: No Transaction Rollback for Index Builds

Building an index on a large collection can take hours. If it fails midway, the partial index is silently discarded. Plan index builds during maintenance windows.

Senior Insight

MongoDB backup strategies evolved significantly with the introduction of transactions. mongodump with --oplog provides point-in-time backups for replica sets. For sharded clusters, mongodump requires stopping the balancer. I've learned that backups via filesystem snapshots (LVM or EBS snapshots) are faster and more reliable for large databases than mongodump. Always test your restore — a backup that can't be restored is just a waste of disk space.

Source: MongoDB Developer Center (https://www.mongodb.com/developer/), MongoDB Engineering Blog (https://www.mongodb.com/blog/channel/engineering-blog), Studio 3T Blog (https://studio3t.com/blog/)