MongoDB Plugin: Features

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 protects MongoDB using logical backup and restore operations. It relies on the official MongoDB Database Tools for the actual dump and restore payloads, and it adds Bacula-specific orchestration, metadata, validation, streaming, and recovery-chain handling.

Feature Summary

Full logical backup and restore of selected MongoDB application databases
Database and collection include/exclude filters
Application-scoped user and custom role backup and restore
Optional admin database capture for isolated disaster recovery
Replica-set Full, Incremental, and Differential recovery chains using oplog segments
Point-in-time restore for replica-set chains using replay_to
Sharded-cluster logical backup and restore through mongos
Sharded routing metadata capture and restore planning
Dry-run backup and restore reports
Checksum validation of artifact files before restore
Manifest and chain metadata for auditability and recovery-chain validation
TLS, SCRAM, and MONGODB-X509 connection support
Bacula LIST and QUERY operations for inventory discovery.

Standalone MongoDB

For standalone MongoDB servers, the plugin creates a logical backup using mongodump. This is suitable for many application databases where full logical restore is sufficient.

Consistency guarantee:

Full: logical full snapshot as produced by MongoDB Database Tools
Incremental and Differential: accepted by Bacula, but stored as full-style logical artifacts because standalone servers do not provide an oplog recovery chain.

Replica Sets

A replica set in MongoDB is a group of mongod processes that maintain the exact same dataset. It provides data redundancy, fault tolerance, and high availability, serving as the foundational building block for production MongoDB deployments.

A standard replica set consists of multiple MongoDB nodes, typically at least three, that work together in a primary/secondary relationship.

For replica sets, connect the plugin to a writable primary. Prefer a replica set URI or seed list (replicaSet=..., multiple hosts, directConnection=false) so the MongoDB driver can discover the topology and route operations to the current primary.

If you use directConnection=true or a single fixed endpoint, make sure that endpoint is the writable primary. Connecting directly to a secondary makes the plugin reject backup or restore operations that require primary-side guarantees or target writes.

A Full backup captures a logical snapshot and records enough oplog metadata to seed a recovery chain. Incremental and Differential jobs capture oplog segments.

Consistency guarantee:

Full: logical snapshot plus base oplog window metadata
Incremental: oplog segment since the previous chain boundary
Differential: oplog segment since the latest Full boundary
Restore: validated chain replay, optionally stopped at a point in time with replay_to.

The plugin validates chain continuity before replay. It checks artifact identity, parent linkage, source fingerprint, oplog boundaries, and boundary digests. This prevents common unsafe restore scenarios such as missing incrementals or replay after an oplog rollback/divergence.

Sharded Clusters

A MongoDB sharded cluster is a horizontal scaling architecture that distributes massive datasets and high-throughput operations across multiple servers. Instead of overloading a single machine, it breaks data into smaller, manageable partitions called “chunks” and stores them across separate database instances to ensure high availability and performance.

A sharded cluster consists of three primary components that work together to route and store information:

Shards: individual servers or replica sets that store subsets of data. In production environments, each shard is typically a replica set.
Config servers: replica-set members that store cluster metadata and routing configuration, such as which chunks live on which shards.
Query routers (mongos): processes that receive client requests, route them to the relevant shards, and merge the results.

For sharded clusters, connect to mongos. This can be done through the uri parameter, for example: uri=mongodb://backup:secret@mongos1.example.com:27017/admin?authSource=admin

The plugin captures selected application data through the router and records cluster routing metadata used during restore planning.

Consistency guarantee:

Full: sharded coordinated logical artifact with captured routing metadata
Incremental and Differential: full-style logical artifacts
Restore: sharded application restore through mongos with routing preparation where supported by the captured metadata.

The balancer must be stopped before sharded backup and restore operations. This is a deliberate guardrail: running with an active balancer can move chunks during backup or restore and make the resulting artifact harder to reason about.

Security-Aware Backup

By default, the plugin attempts to capture users and custom roles that belong to the selected application databases. This enables application restore that also recreates the database-level security model.

Use skip_security=yes when:

The backup user has only data read permissions.
User and role restore is managed manually outside Bacula.
A migration should restore data only.

The admin database is not included by default. It is protected by explicit isolated disaster-recovery guardrails because restoring admin can affect cluster users, roles, and administrative state.

TLS and MONGODB-X509

The plugin supports TLS for both the Java driver connection and MongoDB Database Tools. When using MONGODB-X509, the MongoDB username must match the client certificate subject exactly as MongoDB reports it, for example:

Example X.509 username

O=Bacula,OU=Backup,CN=bacula-mongodb-client

For X.509 authentication, set authentication_mechanism=MONGODB-X509, authentication_database=$external, tls=yes, and tls_certificate_key_file. Do not provide a password.