MongoDB Plugin: Best Practices

Bacula Enterprise Only

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

The following practices are recommended for production MongoDB backups with Bacula Enterprise.

General Practices

Use one Bacula job per MongoDB deployment or per clear recovery scope.
Prefer structured connection parameters with password_file over embedding passwords in URIs.
Run dry_run=yes before enabling a new Fileset in production.
Test restore into a non-production MongoDB target regularly.
Keep MongoDB Database Tools aligned with the protected MongoDB server family.
Monitor Bacula job logs for topology, compatibility, and chain warnings.
Keep the File Daemon host clock synchronized; recovery-chain metadata uses timestamps.

Connect to a writable primary, not to a secondary.
Size the oplog so the oldest available oplog entry cannot roll past the backup interval.
Schedule regular Full backups to limit chain length and recovery time.
Keep all required Incremental or Differential jobs available until the next Full chain is validated.
Test point-in-time restore with replay_to before relying on it during an incident.

Connect only through mongos.
Stop the balancer before backup and restore.
Confirm that the balancer is not active before starting the Bacula job.
Treat sharded artifacts as application-data recovery artifacts, not full config-server disaster-recovery images.
Maintain a separate MongoDB operational runbook for config-server and cluster-wide security recovery.

Use a dedicated MongoDB backup user.
Grant only the privileges required for the selected backup mode.
Use skip_security=yes for data-only lower-privilege backups.
Use include_admin=yes only for isolated disaster-recovery artifacts.
Protect password files and TLS private keys with filesystem permissions readable only by the File Daemon service user.
For MONGODB-X509, document the exact certificate subject used as the MongoDB username.

Prefer restoring to an empty target with conflict_strategy=fail for validation restores.
Use dry_run=yes before production restore.
Use conflict_strategy=drop only when the target data can be overwritten.
Record the selected JobIds and restore options in the incident ticket or recovery log.
Run application-level validation after MongoDB restore completes.