MongoDB Plugin: Scope

Enterprise

Bacula Enterprise Only

This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.

The Bacula Enterprise MongoDB Plugin is designed for Linux File Daemon hosts that can reach the MongoDB deployment and can run the MongoDB Database Tools, specifically mongodump and mongorestore. The plugin does not require mongosh for backup or restore operations. The plugin is available starting with Bacula Enterprise 18.2.5.

Supported MongoDB Server Versions

At the time of the plugin release, the following MongoDB server versions are supported: 6.0, 7.0, and 8.0. Future official versions are expected to be supported by the Bacula Enterprise MongoDB Plugin.

For more information about supported MongoDB server platforms and versions, contact Bacula Systems Support Team.

Restore to the same MongoDB major version, or to a newer major version, is supported, subject to MongoDB compatibility and feature compatibility version checks. Downgrade restores to an older MongoDB major version are rejected by the plugin before restore starts.

Supported Deployment Types

The plugin supports the following deployment types:

  • Standalone mongod instances

  • Writable replica-set primaries

  • Sharded clusters accessed through mongos.

The plugin intentionally does not support direct backup of secondaries, direct backup of shard members, or direct backup of config servers. For sharded clusters, always connect to mongos, the MongoDB query router. This is not mongosh, the interactive MongoDB shell.

Supported Security Modes

The plugin supports:

  • No-authentication MongoDB deployments

  • SCRAM username/password authentication

  • Passwords provided directly, through a password file, or through an environment variable

  • TLS server validation with a CA file

  • TLS client certificate/key files

  • MONGODB-X509 authentication using a client certificate identity.

Supported Backup Levels and Recovery Semantics

Bacula Full, Incremental, and Differential job levels are accepted. Their behavior depends on the source topology:

MongoDB backup level behavior by topology

Source topology

Full

Incremental

Differential

Recovery semantics

Standalone mongod

Full logical artifact

Full-style artifact

Full-style artifact

Restore from the selected logical artifact. Point-in-time replay is not

available because there is no replica-set oplog recovery chain.

Writable replica-set primary

Full logical artifact

with base oplog window

Oplog-chain segment

from the previous chain boundary

Oplog-chain segment

from the latest Full boundary

Full plus Incremental or Differential artifacts can be restored as a

validated oplog chain and replayed up to the selected recovery boundary.

Sharded cluster through mongos

Coordinated logical full

artifact with routing metadata

Full-style artifact

Full-style artifact

Restore through mongos with sharded planning metadata and balancer

guardrails. Sharded oplog point-in-time recovery is not supported.

Direct replica-set secondary,

shard member, or config server

Not supported

Not supported

Not supported

Connect to a writable replica-set primary for replica sets, or to

mongos for sharded clusters.

The entries in the matrix mean:

  • Full logical artifact: a logical MongoDB backup produced with MongoDB Database Tools and described by the plugin manifest. It contains the selected databases, collections, indexes, and eligible security metadata.

  • Full logical artifact with base oplog window: a Full replica-set backup that also records the oplog boundary needed to start a later recovery chain.

  • Coordinated logical full artifact with routing metadata: a sharded-cluster logical backup taken through mongos. The plugin captures sharded planning metadata and enforces balancer guardrails, but it does not replace config server disaster recovery.

  • Full-style artifact: an Incremental or Differential Bacula job that is accepted for schedule continuity, but is executed as a complete logical artifact for that job. It is safe to restore, but it is not an oplog delta and does not provide point-in-time replay.

  • Oplog-chain segment: a replica-set Incremental or Differential payload containing the validated local.oplog.rs range since the previous recovery boundary. Restore replays these segments after the base Full artifact.

  • Recovery boundary: the oplog timestamp where replay stops. The plugin can auto-select the chain tip or use an explicit operator-provided replay point when it falls inside the protected oplog range.

Use-Case Callouts

  • Application teams needing reliable logical MongoDB recovery without scripting.

  • Backup administrators who need MongoDB data in Bacula retention policies and storage pools.

  • Regulated environments requiring off-site, tape, or air-gapped copies of MongoDB data.

  • Replica-set deployments requiring incremental recovery chains and point-in-time replay.

  • Sharded deployments where cluster routing metadata must be captured and used during restore planning.

See also

Next articles:

Go back to: MongoDB Plugin.