mongodump exports MongoDB data to BSON files; mongorestore loads them back. They’re part of the MongoDB Database Tools (installed with the mongodb-org package or separately) and are the standard logical backup method for small and medium deployments.

Connection basics

With authentication enabled (as it should be), pass a connection string with a user that has backup privileges (the built-in backup role) or an admin:

export MONGO_URI='mongodb://backupUser:[email protected]:27017/?authSource=admin'

Create a dedicated user:

use admin
db.createUser({ user: "backupUser", pwd: passwordPrompt(), roles: ["backup", "restore"] })

Back up everything

mongodump --uri="$MONGO_URI" --gzip --archive=/var/backups/mongo/all-$(date +%F).archive.gz

--archive writes a single file instead of a directory tree; --gzip compresses each collection. One file is easier to copy, encrypt and rotate.

One database or collection

mongodump --uri="$MONGO_URI" --db=shop --gzip --archive=shop-$(date +%F).gz
mongodump --uri="$MONGO_URI" --db=shop --collection=orders --gzip --archive=orders.gz
mongodump --uri="$MONGO_URI" --db=shop --collection=orders --query='{"createdAt":{"$gte":{"$date":"2026-01-01T00:00:00Z"}}}' --out=/tmp/orders-2026

Consistency: –oplog on replica sets

A dump of a busy database takes time; documents change during it. On a replica set, --oplog also captures operations that happened during the dump, so you can restore to a consistent point:

mongodump --uri="$MONGO_URI" --oplog --gzip --archive=all-consistent.gz
mongorestore --uri="$MONGO_URI" --oplogReplay --gzip --archive=all-consistent.gz

--oplog works for full-instance dumps only. A standalone server has no oplog — for consistency there, briefly stop writes or use filesystem snapshots. Running even a single node as a one-member replica set enables this (and transactions).

Restore

mongorestore --uri="$MONGO_URI" --gzip --archive=all-2026-11-04.archive.gz

Options you’ll use:

--drop                                 # drop each collection before restoring it
--nsInclude='shop.*'                   # restore only matching namespaces
--nsFrom='shop.*' --nsTo='shop_copy.*' # restore into a different database name
--dryRun                               # check without writing

Without --drop, documents with existing _ids are skipped (duplicate key errors are reported), which can leave a mix of old and new data. Indexes are recreated from the dump’s metadata.

Automate

/usr/local/bin/mongo-backup.sh:

#!/bin/bash
set -euo pipefail
DEST=/var/backups/mongo
mkdir -p "$DEST"
mongodump --uri="$MONGO_URI" --oplog --gzip --archive="$DEST/all-$(date +%F_%H%M).archive.gz"
find "$DEST" -name '*.archive.gz' -mtime +14 -delete

Put MONGO_URI in a root-only environment file or use --config with a YAML file containing the password (mongodump 100.x supports --config). Schedule with cron, and copy archives off the server — see automated backups.

Test restores

Restore the latest backup into a separate database or a test server regularly and check document counts:

db.orders.countDocuments()

Large deployments

mongodump reads all data through the server — slow for hundreds of GB, and it competes with your workload. Alternatives:

  • Filesystem snapshots (LVM, ZFS) of the data directory with journaling enabled — consistent if taken correctly; see LVM.
  • Run backups from a secondary member of a replica set to keep load off the primary.
  • Percona Backup for MongoDB for consistent physical and logical backups of replica sets and sharded clusters.

Version notes

Use Database Tools versions compatible with your server version. Dumps restore into the same or newer MongoDB versions; restoring into an older version may fail.

Related: installing MongoDB, MongoDB replica sets and the 3-2-1 backup rule.

  • MongoDB
  • Backups
  • Databases