How to back up MongoDB in Docker with mongodump and restic

mongodump creates BSON data plus collection metadata and index definitions. With --archive, those files travel as one binary stream, which is convenient to capture outside a Docker container and hand to restic.

This is a logical export, not a storage-engine snapshot. It is useful for modest self-managed deployments, migrations, and recovery points that can tolerate the dump's runtime. Large or sharded systems, strict recovery time objectives, and point-in-time recovery usually call for a provider-native or coordinated replica-set backup design.

A production job should write the archive outside the container layer, authenticate with a dedicated backup account, reject overlapping runs, and publish an artifact only after mongodump succeeds. Those details are what separate a scheduled backup from a command that merely produced a file once.

MongoDB recommends protected configuration or an interactive prompt because credentials placed in a URI or command arguments may be visible to process inspection. Choose the host's secret mechanism deliberately and keep database credentials out of shipped logs.

A plain mongodump that overlaps writes does not necessarily represent one instant across the database. MongoDB documents that changes during the export can affect the backup. The --oplog option can capture writes made during a full replica-set dump, but it cannot be combined with --db or --collection and it does not apply to a full sharded-cluster dump through mongos.

For a write-heavy application, quiesce writes for the dump window or choose a backup method designed for the deployment topology and required recovery point. A successful archive is not evidence that concurrent writes were captured at one consistent instant.

• Queryable Encryption collections cannot be backed up with mongodump.
• Match mongodump and mongorestore tool versions; MongoDB also documents server-version and feature-compatibility constraints.
• A full dump and restore of the admin database can replace users and roles.
• Test how long index rebuilding takes, because it can dominate recovery time.

Treat the archive as production data. Restic encrypts the file before it reaches the repository, but you still need to protect the local staging directory and remove expired local copies deliberately.

Use a separate repository password file and least-privilege storage credentials. A successful restic snapshot confirms that bytes reached the repository; it does not prove mongorestore can rebuild the application.

A good rehearsal leaves the source database alone. Restore app.* into a newly named namespace, then inspect collection names, document counts, indexes, and a few application invariants. The target should be empty so duplicates cannot hide a partial restore.

Select an exact recovery point, restore into a new namespace, and stop the rehearsal on the first import error. Authentication, tool versions, indexes, and application validation must match the real recovery environment.

A database restore can replace matching collections or an entire selected database; it is not a merge-safe preview. Rehearse against an isolated MongoDB instance, record the namespaces and counts you expect, and require those checks to pass before approving a live restore.

Rested presents the selected scope and recovery point before it queues the work, keeps the operation in run history, and leaves application-level validation with the operator. That keeps the destructive decision visible without publishing the orchestration used to perform it.