How to Back Up a MongoDB Database

To back up a MongoDB database you have four options: a logical dump with mongodump, a filesystem or volume snapshot, Ops Manager or Cloud Manager, or Atlas Cloud Backup if the cluster runs on Atlas. mongodump suits small replica sets; snapshots and the managed tools suit large and sharded clusters and add point-in-time recovery. None of them counts as a backup until you have restored from it.

This guide follows MongoDB's documentation for the 8.0 and 9.0 releases and Database Tools 100.19, checked on 11 October 2026.

mongodump connects to a running mongod or mongos and writes BSON data plus index definitions. On a replica set that keeps taking writes, add --oplog: the dump then includes the oplog entries written while it ran, and mongorestore --oplogReplay brings the restore to the moment the dump finished. Without it the dump is not a single point in time.

mongodump --uri="mongodb://backupUser@db1.example.net:27017,db2.example.net:27017/?replicaSet=rs0" \
  --oplog --gzip --archive=/backups/rs0-2026-10-11.archive.gz

mongorestore --uri="mongodb://restore-test.example.net:27017" \
  --oplogReplay --gzip --archive=/backups/rs0-2026-10-11.archive.gz

The limits are what matter in production:

• --oplog needs a full dump of a replica set member. It fails with --db, --collection or --query, has no effect through mongos, and the dump fails if a client runs renameCollection, an aggregation with $out, mapReduce or a user or role change while it runs.
• Restores are documented for the same major version or feature compatibility version as the source. On 9.0, do not change FCV between 8.x and 9.0 during a --oplog dump of time series collections; Database Tools 100.18.0 and later fail the dump rather than produce one that cannot be replayed.
• Indexes are rebuilt from metadata after the data loads, which on large collections can take longer than the load.
• mongorestore --drop on a dump that includes admin replaces every user with the users in the dump.
• The dump reads every document, so it competes with the application for cache and I/O. The backup and restore built-in roles cover the privileges.

LVM, EBS or storage-array snapshots copy the data files at block level and complete quickly. For a snapshot of a running WiredTiger mongod to be valid, the journal must be on the same volume as the data files. If it is on a separate volume, or the data sits on EBS volumes striped in RAID, flush and lock first:

db.fsyncLock()
# take the snapshot, for example:
lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb
db.fsyncUnlock()

Two details catch people. The fsync lock is counted, so every fsyncLock() needs a matching fsyncUnlock(), and the lock persists across a restart, so a node that was restarted while locked comes back still refusing writes. Copy the snapshot off the storage it came from; a snapshot on the same array does not survive losing that array.

A sharded cluster backup has to capture every shard and the config server replica set at the same moment. For self-managed snapshots or dumps, MongoDB's procedure is: pick a window without chunk migrations or resharding, stop the balancer with sh.stopBalancer(), lock the cluster from mongos with db.getSiblingDB("admin").fsyncLock(), back up the config server and each shard, then unlock and restart the balancer. Locking through mongos needs 7.1, or 7.0.2, 6.0.11 or 5.0.22 and later.

That procedure stops writes for the whole backup, and it does not preserve the atomicity of transactions across shards. MongoDB names Atlas, Cloud Manager and Ops Manager as the methods that back up with the balancer running and transactions in flight. Clusters still on 4.2 or 4.4 cannot lock through mongos at all; OSSeva, AceMQ's extended support platform, patches self-managed 4.2 to 6.0 while the upgrade is planned.

Both run the MongoDB Agent's backup module, which tails the primary's oplog and copies data files to snapshot storage on a schedule, so you get regular snapshots plus point-in-time restore for replica sets and sharded clusters, with namespace filtering. Ops Manager is installed on your own infrastructure and comes with Enterprise Advanced; from Ops Manager 8.0 the agent can write snapshot blocks directly to S3. Cloud Manager is the hosted version and requires MongoDB Enterprise Server. For an active backup job, Ops Manager keeps at least one restorable snapshot even if newer jobs are failing.

Atlas Cloud Backup uses the cloud provider's native snapshots, stored in the cluster's highest-priority region. The default policy on Dedicated clusters:

Continuous cloud backup is enabled by default on new clusters and replays the oplog to restore to any point in the restore window, which cannot be longer than the hourly snapshot retention. A burst of writes that rolls the oplog over before Atlas collects it deletes the existing oplog backups, so size the oplog for peak write rates. You can restore whole clusters or selected databases and collections, and snapshots can be copied to other regions. A Backup Compliance Policy stops anyone, including project owners, deleting snapshots or shortening retention. Flex clusters get one daily snapshot and no point-in-time restore. The storage and oplog charges are covered in our Atlas pricing guide.

Set retention from how long a silent corruption could go unnoticed and what your regulators require, and keep one copy in a different region or account.

mongodump archives are ordinary BSON files, so protect them with encrypted storage and tight access controls. Atlas encrypts snapshots with the cloud provider's storage encryption, and adds a layer with customer-managed keys; deleting a key makes every snapshot encrypted with it unrecoverable, so check retained snapshots before retiring one. With the Enterprise encrypted storage engine in AES256-GCM mode, restoring a cold filesystem backup needs --eseDatabaseKeyRollover to avoid IV reuse.

Test restores on a schedule: restore to a separate host or a new Atlas cluster, run application checks and document counts against it, and record the time taken. Atlas requires that the target cluster receives no client traffic during a restore, which is another reason to restore to a new cluster and switch over.

• A nightly mongodump --oplog failing because a job runs $out or renames a collection at the same time.
• The balancer left on during a sharded snapshot, giving missing or duplicated documents.
• A node restarted while fsync-locked, rejecting writes until someone unlocks it.
• An oplog too small for peak writes, breaking point-in-time coverage.
• Backups on the same volume, host or account as the data.
• A restore that has never been timed, discovered to take a day during an incident.

Backups fail quietly and are tested during the worst week of the year. AceMQ's MongoDB support engineers design and test backup and restore for self-managed, Enterprise and Atlas deployments; our deployment assessment case includes a backup recoverability review. Planning an upgrade or a move to Atlas? Start with the MongoDB migration guide, and see MongoDB support options for vendor and independent coverage.

• MongoDB: Backup Methods for a Self-Managed Deployment
• MongoDB: Back Up and Restore with MongoDB Tools
• MongoDB Database Tools: mongodump (--oplog limits)
• MongoDB Database Tools: mongorestore
• MongoDB: Back Up with Filesystem Snapshots
• MongoDB: Back Up a Sharded Cluster with File System Snapshots
• MongoDB: Back Up a Sharded Cluster with a Database Dump
• MongoDB: db.fsyncLock()
• MongoDB Ops Manager: Backup Process
• MongoDB Atlas: Back Up Your Cluster
• MongoDB Atlas: Dedicated Cluster Backups and Continuous Cloud Backup
• MongoDB Atlas: Configure a Backup Policy
• MongoDB Atlas: Restore Your Cluster
• MongoDB Atlas: Backup Compliance Policy
• MongoDB Atlas: Storage Engine and Cloud Backup Encryption
• MongoDB Atlas: Flex Limitations