How to back up a MongoDB Docker container (2026)

Backing up MongoDB safely means one rule: dump, don't copy. `mongodump --archive --oplog` produces a consistent, restorable dump from the running container, which restic then encrypts off-site. --oplog records operations during the dump so mongorestore --oplogReplay can rebuild a point-in-time-consistent snapshot. Anything that copies /data/db live risks an unrestorable backup.

Detection

What Dockstash detects

Env keys detected	MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE
Default port	27017
Live data paths (never copied live)	/data/db
Example images	mongo:7, mongo:6, mongo:5, mongo

Commands

The dump command

mongodump --archive --oplog

The restore command

mongorestore --archive --oplogReplay --drop

--oplog records operations during the dump so mongorestore --oplogReplay can rebuild a point-in-time-consistent snapshot.

The gotchas

Gotchas to avoid

Never restic the live /data/db WiredTiger files — copied mid-checkpoint they are inconsistent and often unrecoverable.
--oplog requires the server to be a replica-set member (even a single-node replica set); on a standalone mongod it is a no-op with no point-in-time guarantee.
On restore, --oplogReplay must accompany --oplog dumps or the point-in-time consistency is lost.

Do it in one click with Dockstash

Dockstash runs the exact dump above, restics it off-site, and drill-tests the restore automatically — no script to maintain.

Start free All guides

Last updated: July 2026

PostgreSQL

Back up PostgreSQL in Docker

Redis

Back up Redis in Docker

Elasticsearch

Back up Elasticsearch in Docker

n8n

Workflow automation

Frequently asked questions

What does --oplog actually do?

It records the operations log entries that occur while mongodump runs and stores them in the archive. On restore, --oplogReplay applies them so the dump reflects a single consistent point in time rather than a smear across the dump window.

Do I need a replica set for consistent backups?

For point-in-time consistency, yes — --oplog only works on a replica-set member. Many single-node deployments run as a one-member replica set specifically to get this guarantee.

Why not copy /data/db directly?

WiredTiger writes checkpoints continuously. A file copy mid-checkpoint captures an inconsistent state that frequently will not start. mongodump reads a logical, restorable snapshot.

How do I restore into a clean database?

mongorestore --archive --oplogReplay --drop drops existing collections before restoring so you do not merge old and new data. Dockstash restores to a staging target first by default.