For more posts regarding MongoDB, please click on Index

 

Mongodump creates a binary export of MongoDB data in BSON format. It’s ideal for logical backups and supports replica set consistency with the –oplog option.

MongoDB Utilities :

Mongoexport : Export specific data from certain collection

Mongoexport -d infra -c topics -o file_name.txt

The export will be done in JSON Object, not as Extended JSON Object

Mongoimport : import data into MongoDB Database

mongoimport -d infra -c topics –file file_name.txt

Mongodump : Creates dump from MongoDB database

Here for each collection, a BSON and metadata.json file is created. In the .BSON file, data from the collection is stored in BSON Format

.metadata,json file contains information about indexes

To open the BSON file, use hexdump utility.

Hexdump -C ->  -C attempts to parse sequence of the ASCII Codes

Mongorestore : Restore data from MongoDB database Dump

 

Steps to Install mongodump Correctly

  1. Download the Database Tools TGZ

Use the version that matches MongoDB 8.2.x (tools are backward compatible):

Download from MongoDB’s official page:
https://www.mongodb.com/try/download/database-tools

Choose:

  • OS: Linux x86_64
  • Package: TGZ
  • Version: 100.x (latest)
  1. Extract inside /mongo

cd /mongo tar -xvf mongodb-database-tools-*-linux-x86_64.tgz

This creates a folder like:

mongodb-database-tools-rhel93-x86_64-100.9.4/

  1. Create a symlink (for clean PATH)

ln -s mongodb-database-tools-* tools

  1. Add tools to PATH (same style as mongod & mongosh)

echo ‘export PATH=/mongo/tools/bin:$PATH’ | sudo tee /etc/profile.d/mongotools.sh source /etc/profile.d/mongotools.sh



  1. Verify

mongodump –version

mongorestore –version

 

Common Backup Commands

Purpose

Command

Backup all databases

mongodump –out /backup/mongodb_backup_$(date +%F)

Backup specific database

mongodump –db myDatabase –out /opt/myDatabase_backup

Backup specific collection

mongodump –db myDatabase –collection users –out /opt/myDatabase_users_backup

Backup with authentication

mongodump –db myDatabase –username mongoadm –authenticationDatabase admin –out /opt/backup

Compressed archive backup

mongodump –db myDatabase –gzip –archive=/opt/myDatabase_backup.gz

Replica set consistent backup

mongodump –oplog –out /opt/backup

 

 

Restore with mongorestore

mongorestore imports BSON data created by mongodump into a MongoDB instance. It recreates databases, collections, and indexes.

🔧 Common Restore Commands

 

 

 

 

 

Purpose

Command

Restore all databases

mongorestore /opt/mongodb_backup_2026-03-28

Restore specific database

mongorestore /opt/mongodb_backup_2026-03-28/myDatabase –db myDatabase

Restore specific collection

mongorestore –db myDatabase –collection users /backup/users_backup/myDatabase/users.bson

Restore with authentication

mongorestore –db myDatabase -u mongoadm –authenticationDatabase admin /opt/backup

Restore with drop (overwrite existing)

mongorestore –db myDatabase –drop /opt/backup

Restore from compressed archive

mongorestore –gzip –archive=/opt/myDatabase_backup.gz

MongoDB backup and restore revolve around two logical‑level tools—mongodump and mongorestore—and a set of architectural considerations that determine how consistent, recoverable, and scalable your backup strategy is. A complete understanding includes how these tools work internally, how they behave in replica sets and sharded clusters, and when to choose alternatives like filesystem snapshots or cloud‑native backups.

MongoDB Backup

  1. Backup Approaches

MongoDB supports three broad categories of backups, each suited to different environments.

Logical Backups (mongodump)

  • Export data in BSON format.
  • Portable across versions and platforms.
  • Ideal for small to medium datasets, migrations, and dev/test.
  • Can include the oplog for point‑in‑time consistency in replica sets.

Physical Backups (Filesystem Snapshots)

  • Capture the underlying data files (dbPath).
  • Fast and consistent when using LVM, ZFS, EBS, or SAN snapshots.
  • Best for large datasets and production clusters.
  • Must ensure the snapshot is taken from a quiesced or secondary node.

Cluster‑Aware Backups (Ops Manager / Cloud Manager)

  • Coordinated backups for sharded clusters.
  • Support point‑in‑time recovery (PITR).
  • Automated scheduling, retention, and compression.
  1. mongodump: Commands and Deep Behavior

Basic Syntax

mongodump –out /path/to/backup

Database‑Level Backup

mongodump –db mydb –out /backup/mydb

Collection‑Level Backup

mongodump –db mydb –collection users –out /backup/users

Compressed Archive Backup

mongodump –gzip –archive=/backup/mydb.gz

Backup With Authentication

mongodump –username admin –password ‘Pass123’ –authenticationDatabase admin –out /backup



Consistent Replica Set Backup (with oplog)

mongodump –oplog –out /backup/rs_backup

 

How –oplog works internally

  • Captures a snapshot of data.
  • Captures the oplog entries generated during the dump.
  • Produces a consistent point‑in‑time backup across all collections.

 

Backup From a Secondary Node

mongodump –host secondary1:27017 –oplog –out /backup

This reduces load on the primary.

 

MongoDB Restore

  1. mongorestore: Commands and Behavior

Restore Entire Backup

mongorestore /backup/rs_backup

Restore a Single Database

mongorestore –db mydb /backup/mydb

Restore a Single Collection

mongorestore –db mydb –collection users /backup/users/users.bson

Restore With Drop (overwrite existing data)

mongorestore –drop /backup/mydb

Restore From Compressed Archive

mongorestore –gzip –archive=/backup/mydb.gz

Restore With Authentication

mongorestore –username admin –password ‘Pass123’ –authenticationDatabase admin /backup



  1. How Restore Works Internally

BSON Import

  • Reads BSON files generated by mongodump.
  • Recreates collections, indexes, and metadata.

Oplog Replay (if backup used –oplog)

mongorestore –oplogReplay /backup/rs_backup

  • Applies oplog entries to bring data to the exact point‑in‑time snapshot.
  • Ensures consistency across collections.

Index Rebuild

  • Indexes are recreated automatically.
  • Large restores may take time due to index building.

 

Backup and Restore in Replica Sets

Backup

  • Best practice: run mongodump on a secondary.
  • Use –oplog for consistency.
  • Ensure oplog window is large enough to cover backup duration.

Restore

  • Restore to a standalone node first.
  • Convert to replica set after verification.
  • Avoid restoring directly into an active replica set unless performing controlled recovery.

Backup and Restore in Sharded Clusters

Backup

  • mongodump is not cluster‑aware.
  • Must run mongodump through mongos:

mongodump –host mongos1:27017 –out /backup/sharded

  • For production clusters, filesystem snapshots or Ops Manager are recommended.

Restore

  • Restore through mongos:

mongorestore –host mongos1:27017 /backup/sharded

  • Shard key must exist before restore.
  • Collections must be sharded before restoring sharded data.

 

Operational Best Practices

Backup

  • Store backups off‑host and off‑region.
  • Automate with cron or systemd timers.
  • Encrypt backups at rest and in transit.
  • Monitor oplog window to avoid sync failures.

Restore

  • Always test restores in staging.
  • Validate data integrity after restore.
  • Rebuild indexes and validate schema.
  • For large datasets, restore to a standalone node for speed.