Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

MongoDB backups: what mongodump can and cannot do, filesystem snapshots, and restoring a replica set

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A self-managed MongoDB backup plan may begin with a scheduled mongodump written to local storage. That works for small databases. As data grows, as replica sets and encryption are added, and as recovery expectations tighten, the limits of that approach start to matter.

MongoDB's documentation is candid about those limits. This guide sets out what each self-managed backup method does, what it does not do, and how to restore a replica set from backup in the order the documentation requires.

It covers self-managed deployments: standalone servers and replica sets on your own infrastructure. Sharded clusters have separate, more involved procedures, and MongoDB's managed services have their own backup features; both are outside the scope here.

Why it matters

A logical dump that cannot be restored consistently, or restored at all into the version you now run, is not the safety net it appears to be. Likewise a snapshot taken from the wrong storage layout. These failures show up at restore time, not backup time.

Replica sets add a trap of their own. Restoring the same data onto three new servers and then joining them looks sensible, but it is not how the documentation says to do it, and it costs a full resynchronisation.

How it works

The three self-managed approaches

The backup methods page describes three approaches for self-managed deployments: MongoDB's own Cloud Manager or Ops Manager services, copying the underlying data files (by filesystem snapshot or by cp/rsync), and mongodump.

Its comparison table is a useful summary. For mongodump/mongorestore, it rates recovery time objective "High", recovery point objective "High", backup storage cost "High", and incremental backup "No". For filesystem snapshots, recovery time is "Low", recovery point "High", and incremental backup "Depends on storage and tool". Neither offers continuous point-in-time backup and restore; the table shows that only for the Cloud Manager/Ops Manager column.

(Here, a "High" recovery point objective means more potential data loss: you can only go back to when the backup was taken.)

mongodump: what it is for

The backup tools tutorial says the tools "work with BSON data dumps, and are useful for creating backups of small deployments. For resilient and non-disruptive backups, use file system snapshots or block-level disk snapshots with Cloud Backups from MongoDB Atlas." For self-managed servers, that points to filesystem snapshots.

The reason is performance. The tools "create traffic and force the database to read all data through memory. When MongoDB reads infrequently accessed data, it evicts frequently accessed data, degrading performance for the database's regular workload."

According to the mongodump reference, a dump contains "Collection documents, metadata, and options", "Index definitions", and "Writes that occur during the export, if run with the mongodump --oplog option." Index definitions, not index data: indexes are rebuilt on restore, which adds time for large collections. The tutorial also notes that "mongodump excludes the content of the local database from its output."

Two practical warnings from the tutorial: mongodump "overwrites existing files in the output folder", so each run should write to a new, dated location; and backups should be labelled "to identify backup contents and the backup time."

Consistency and --oplog

On a replica set that is taking writes, a dump is read over time, so different collections reflect different moments. The tutorial is clear: "To ensure mongodump can take a consistent backup of a replica set, you must either use the --oplog option to capture writes received during backup operations or stop all writes to the replica set for the duration of the backup."

With --oplog, "mongodump copies all data from the source database and all oplog entries from the beginning to the end of the backup", so that mongorestore --oplogReplay can "restore a backup that reflects the exact moment mongodump completed."

The limits are important:

  • It is not point-in-time recovery. The tutorial states that --oplogReplay "does not support restoring to an arbitrary point in time." It only makes the dump consistent as of its end.
  • It needs a full dump. The reference says --oplog "fails if you use any of the following options to limit the data to be dumped": --db, --collection, --dumpDbUsersAndRoles and --query.
  • It is for replica sets. It "only works against nodes that maintain an oplog", and "You can't run mongodump with --oplog on a sharded cluster."
  • Feature version changes during a dump can break it. The reference warns not to change the feature compatibility version between MongoDB 8.x and 9.0 while mongodump --oplog runs on a deployment with time series collections, because the result "can't replay". Newer tools fail instead of producing such a dump.

What mongodump cannot back up

The reference states: "You can't use mongodump with a collection that uses Queryable Encryption or client-side field level encryption (CSFLE)." The mongorestore reference has the matching limit. If your applications use either feature, those collections need another backup method.

Restoring a dump

mongorestore "loads data from either a binary database dump created by mongodump or the standard input into a mongod or mongos instance." Several of its behaviours matter for planning:

  • Version rule. Both references say: "You can restore the BSON files generated from mongodump into MongoDB deployments running the same major version or feature compatibility version as the source deployment." Record the source version with each dump, and keep a way to run that version for restores.
  • Errors do not stop it by default. "By default, mongorestore continues when it encounters duplicate key and document validation errors." The --stopOnError option changes that. Our recommendation: read the restore log in full, and use --stopOnError when a complete, exact restore is the goal.
  • --drop is partial. It "drops the collections from the target database" before restoring, but "does not drop collections that are not in the backup."
  • --drop with the admin database replaces users. The reference warns that when the restore includes the admin database, mongorestore with --drop "removes all user credentials and replaces them with the users defined in the dump file." Restoring that over a live system can lock current administrators out.
  • Concurrency. "MongoDB doesn't support running multiple mongorestore programs concurrently for the same collection."

Privileges are worth planning too. The tutorial explains that the built-in restore role is enough unless the dump includes profiler data or you use --oplogReplay. For --oplogReplay, it says to "create a user-defined role that has anyAction on anyResource" and to "Grant only to users who must run mongorestore with --oplogReplay." That is effectively unrestricted access; keep such an account for restores only, and disable it between uses.

Filesystem snapshots

The filesystem snapshot tutorial describes block-level methods that "complete quickly and work reliably, but require additional system configuration outside of MongoDB."

The key condition is that the data on disk is valid at the moment of the snapshot: "all writes accepted by the database need to be fully written to disk: either to the journal or to data files." For WiredTiger, "the data files reflect a consistent state as of the last checkpoint. Checkpoints occur with every 2 GB of data or every minute."

The documentation's two pages phrase the storage layout rule differently, and it is worth reading both:

  • The backup methods page says: "To get a correct snapshot of a running mongod process, you must have journaling enabled and the journal must reside on the same logical volume as the other MongoDB data files."
  • The snapshot tutorial says that for WiredTiger "the data files and the journal are no longer required to reside on a single volume", but adds: "when the MongoDB instance's data files and journal files reside on separate volumes... to create a coherent backup, the database must be locked and all writes to the database must be suspended during the backup process."

Read together: a single snapshot of one volume holding both data and journal can be taken while the server runs. If they are on separate volumes, writes must be stopped for the duration, because separately initiated snapshots do not establish one coherent capture. Some storage platforms offer coordinated snapshot groups, but that capability must be verified against the supported MongoDB procedure; it cannot be assumed from the word "snapshot".

The tutorial adds three points that apply to any snapshot strategy:

  • Snapshots are not storage. They "typically depend and reside on the same storage infrastructure as the original disk images. Therefore, it's crucial that you archive these snapshots and store them elsewhere."
  • Copy-on-write space runs out. "If your snapshot runs out of space, the snapshot image becomes unusable."
  • Keep the volume focused. Consider "isolating your MongoDB data files, journal (if applicable), and configuration on one logical disk that doesn't contain any other data."

The tutorial warns about consistency in software RAID spanning cloud block volumes. Treat that as a requirement to verify capture coordination for the actual platform and storage layout, rather than a claim that every modern platform has identical snapshot limits.

Encrypted storage and cold backups

For MongoDB Enterprise's encrypted storage engine with the AES256-GCM cipher, the filesystem snapshot tutorial explains a subtle risk. Restoring from a "hot" backup is handled automatically: "MongoDB detects 'dirty' keys on startup and automatically rolls over the database key". But for a "cold" backup taken while mongod was stopped, "MongoDB does not detect 'dirty' keys on startup, and reuse of IV voids confidentiality and integrity guarantees." The documented remedy is the --eseDatabaseKeyRollover startup option, and the backup methods page advises: "If using filesystem-based backups for MongoDB Enterprise, use the 'hot' backup feature."

Restoring a replica set from data files

The replica set restore tutorial starts with a warning: "You cannot restore a single data set to three new mongod instances and then create a replica set. If you copy the data set to each mongod instance and then create the replica set, MongoDB will force the secondaries to perform an initial sync."

The documented process deliberately rebuilds replica-set identity from one restored member, then seeds or synchronises the others. Old local configuration and oplog state are treated separately from application data. Removing that local database is destructive, so the tutorial belongs in a qualified, version-specific recovery runbook applied to preserved copies. It is not a task to improvise on a surviving production member.

Plan the initial-sync cost before deciding the cluster is recovered. The tutorial notes: "If your database is large, initial sync can take a long time to complete. For large databases, it might be preferable to copy the database files onto each host." Seeding files still requires the documented clean state, compatible software, permissions and network isolation. A working first member is only an intermediate result; the required replica-set membership and application behaviour must also be validated.

Two cautions (our recommendations). Do this on new servers, not on the members of a running production replica set: removing the local database and emptying data directories are destructive steps. And the tutorial's warning about network exposure applies: before binding the restored instance to a reachable address, make sure authentication and network controls are in place.

What to choose and why

These are our recommendations, based on the documentation above.

  • Small, low-write databases: mongodump with --oplog on a replica set member, written to a new dated location each run, copied off the server, and restored regularly to test.
  • Larger or busy databases: filesystem snapshots, with data, journal and configuration on one dedicated volume, the snapshot copied to separate storage, and enough copy-on-write space for the copy period.
  • Point-in-time recovery requirements: a dump or storage snapshot alone does not provide continuous arbitrary point-in-time recovery. The vendor comparison lists that capability for its managed backup tooling; this comparison is not an exhaustive claim about every third-party solution. If you need it, plan for that, or accept and record the recovery point your method gives.
  • Encrypted fields (Queryable Encryption, CSFLE): do not rely on mongodump for those collections.
  • Every method: record the server version and feature compatibility version with each backup, keep restore credentials separate and tightly held, and restore to a test deployment on a schedule. The tutorial puts it simply: "Verify your backups by restoring them to a test deployment."

Risks and limits

  • mongodump affects performance on the source by pulling cold data through memory.
  • --oplog gives end-of-dump consistency only, not point-in-time recovery.
  • mongorestore --drop with the admin database replaces user credentials.
  • Default restores continue past duplicate key and validation errors.
  • Snapshot layouts matter; separate data and journal volumes require writes to be stopped.
  • Replica set restores involve destructive steps; do them on new servers.
  • Sharded clusters need their own procedures, not covered here.
  • Nothing here was run. Behaviour is quoted from the documentation for planning.

Sources

This article was originally published on .