MongoDB Plugin: Architecture

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 a Bacula File Daemon plugin. Bacula loads the plugin through the File Daemon, and the plugin launches a Java backend that communicates with MongoDB and with the Bacula MetaPlugin transport layer.

The plugin uses two MongoDB-facing components:

  • The MongoDB Java driver for connection validation, topology inspection, inventory discovery, compatibility checks, and metadata reads.

  • The MongoDB Database Tools, especially mongodump and mongorestore, for logical backup and restore payloads.

The plugin stores MongoDB payloads in the Bacula catalog under the virtual path /@mongodb. Database archive payloads are transferred through Bacula storage, while small control files, such as manifests and chain metadata, are staged locally under the plugin working path for planning and validation. Compatible normal Bacula restores stream full dump archives directly into mongorestore when the restore mode supports streaming.

Bacula Enterprise MongoDB Plugin Architecture

Bacula Enterprise MongoDB Plugin Architecture

Backup Data Flow

  1. Bacula starts a backup job using a Fileset that contains Plugin = "mongodb: ...".

  2. The File Daemon loads the MongoDB Plugin and passes job level, working path, and plugin parameters.

  3. The plugin validates the connection, topology, selected databases, permissions, tools, and available local working space.

  4. The plugin invokes mongodump for selected databases and collections.

  5. Full database archives are sent to Bacula storage.

  6. Metadata files are sent to Bacula under /@mongodb.

  7. For replica-set Incremental or Differential jobs, the plugin captures oplog segments and chain metadata.

Restore Data Flow

  1. The operator selects MongoDB files under /@mongodb in a Bacula restore session.

  2. The plugin reads restored metadata files and validates the artifact set.

  3. Compatible full archive payloads are streamed from Bacula to MongoDB restore tooling without writing complete dump archives locally.

  4. Small metadata files are staged locally because restore planning requires local access to them.

  5. The plugin validates target version, topology, conflicts, chain continuity, and isolated-DR guardrails.

  6. The plugin invokes mongorestore and, when needed, replays oplog segments.

Backup Artifact Layout

A typical Bacula backup appears under /@mongodb with paths similar to:

MongoDB backup files in Bacula
/@mongodb/manifest.json
/@mongodb/chain-index.json
/@mongodb/cluster-metadata.json
/@mongodb/dump/appdb.archive
/@mongodb/dump/analytics.archive
/@mongodb/oplog/local/oplog.rs.bson

Not every file is present in every backup. For example, chain-index.json and oplog/local/oplog.rs.bson are used for replica-set recovery chains, while cluster-metadata.json is used for sharded-cluster artifacts.

Metadata Files

The most important metadata file is manifest.json. It records source version, feature compatibility information, topology, selected databases, restore profile, checksums, and file inventory.

For recovery chains, chain-index.json records chain identity, artifact identity, parent linkage, source fingerprint, and oplog boundaries.

For sharded clusters, cluster-metadata.json records shard membership and routing metadata used by restore planning.

See also

Previous articles:

Next articles:

Go back to: MongoDB Plugin.