Restore Parameters

Bacula Enterprise Only

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

Note

Restore parameters are not Fileset backup parameters. They are entered during a Bacula restore session from the Plugin Options prompt, or through a Bacula GUI that exposes plugin restore options.

Restore parameters are entered from the Bacula restore Plugin Options prompt or through a Bacula GUI that exposes plugin restore options.

Restore parameters
Option	Required	Default	Values	Example	Description
`conflict_strategy`	No	`fail`	`fail`, `drop`, `skip`	`drop`	Behavior when target collections already exist.
`collection`	No	All collections	Collection name	`widgets`	Restore only matching collection names across selected databases.
`map_db`	No		`source=target`	`appdb=appdb_restored`	Restore a dumped database under a different target database name.
`replay_to`	No	Chain end	`seconds[:ordinal]`	`1778245150:3`	Stop oplog replay at a selected point in a replica-set recovery chain.
`isolated_dr`	No	`no`	`yes` or `no`	`yes`	Enable isolated disaster-recovery guardrails.
`recover_admin`	No	`no`	`yes` or `no`	`yes`	Explicitly replay dumped `admin` database during isolated DR where supported.
`skip_security`	No	`no`	`yes` or `no`	`yes`	Skip restoring application users and custom roles.
`dry_run`	No	`no`	`yes` or `no`	`yes`	Validate restore plan without changing the target.
`report_format`	No	`text`	`text` or `json`	`json`	Dry-run report format.

Restore Conflict Strategy

conflict_strategy controls how the plugin handles MongoDB objects that already exist in the restore target. It is the MongoDB Plugin overwrite policy. It is not the same as the generic Bacula Replace option shown by Bconsole.

For normal standalone and replica-set application restores, conflict handling is collection-based:

fail: before running mongorestore, the plugin checks whether any collection selected for restore already exists in the target database. If a matching target collection exists, restore is rejected before data is written. This is the safest default.
drop: the plugin runs mongorestore with --drop. For each restored collection, MongoDB drops the matching target collection first and then recreates it from the backup. All documents, indexes, and collection options inside that restored target collection are replaced by the backup content. Collections that are not part of the restore scope are not dropped. The plugin does not use --drop for automated admin database replay.
skip: the plugin removes already-existing target collections from the restore plan and restores only selected collections that do not exist in the target. Existing collections are kept exactly as they are. This is a collection-level decision, not a document-level merge.

The plugin does not compare or merge individual documents inside a collection. If a collection is restored, its content comes from the backup. If a collection is skipped, all existing documents in that target collection remain untouched.

For sharded restore artifacts, conflict_strategy=drop is broader. Before recreating sharded routing metadata, the plugin drops the target database named in the sharded restore plan, then prepares the sharded collections and runs mongorestore through mongos. Use this only when the target database can be replaced.

Examples:

Conflict strategy examples
Scenario	Target state before restore	Result
`conflict_strategy=fail`	`appdb.widgets` already exists	Restore fails before writing data. No MongoDB collection is changed.
`conflict_strategy=drop`	`appdb.widgets` exists and is selected for restore; `appdb.logs` exists but is not selected	`appdb.widgets` is dropped and recreated from the backup. `appdb.logs` is left untouched.
`conflict_strategy=skip`	`appdb.widgets` exists and `appdb.events` does not exist; both are selected for restore	`appdb.widgets` is skipped and left untouched. `appdb.events` is restored from the backup.
`conflict_strategy=drop` with sharded artifact	Target sharded database `appdb` exists	The target `appdb` database is dropped before sharded routing metadata and selected data are restored through `mongos`.

Bacula Replace Option

Bconsole also shows the generic Bacula restore Replace option, with values such as Never, Always, Ifnewer, and Ifolder. That option is a filesystem restore policy used by Bacula for ordinary file restores.

For MongoDB live plugin restore with Where=/, the MongoDB Plugin does not currently use the Bacula Replace value to decide what happens inside MongoDB. The MongoDB target overwrite behavior is controlled by plugin restore options, mainly conflict_strategy.

For example, if Bconsole displays Replace: Always but the plugin restore options keep conflict_strategy=fail, an existing target collection still causes the MongoDB restore to fail. Conversely, conflict_strategy=drop can replace selected MongoDB collections even though the Bacula Replace option is only a generic restore setting.

When using Where=/local/fd/path for file-based artifact restore, the restore is not applied to MongoDB. The selected Bacula files are reconstructed under the chosen File Daemon path for inspection or manual use.

Isolated DR Parameters

Use isolated_dr=yes only for a dedicated recovery target. This allows artifacts containing admin to be considered for restore. For standalone and replica-set targets, recover_admin=yes explicitly replays the dumped admin database. For sharded targets, automated admin replay is blocked; manual cluster security recovery remains required.

Supported Restore Use Cases

Use restore parameters according to the recovery goal:

Standard full restore to an empty target: keep defaults (conflict_strategy=fail) and restore all dumped databases/collections.
Overwrite existing target data: set conflict_strategy=drop so existing collections are dropped before replay.
Merge into a partially populated target: set conflict_strategy=skip to preserve existing collections and restore only missing ones.
Restore only selected application objects: use collection to limit restore scope to matching collection names.
Restore into alternate database names: use one or more map_db mappings (source=target) to avoid overwriting original names.
Point-in-time restore on replica-set incremental chains: set replay_to=seconds[:ordinal] to stop oplog replay at a controlled boundary.
Isolated disaster recovery including admin payload: set isolated_dr=yes and add recover_admin=yes only when the target architecture supports automated admin replay.
Schema and plan validation only: set dry_run=yes (optionally report_format=json for automation pipelines).

Operational rules:

report_format is evaluated only with dry_run=yes.
recover_admin=yes requires isolated_dr=yes and an artifact set that includes admin.
On sharded targets, keep isolated_dr=yes for admin-containing artifacts, but expect manual admin/security recovery.
collection filters are applied per selected database in the restore plan.

Replay_To Format Details

replay_to uses the same format as MongoDB oplog limits:

Format: seconds[:ordinal]
seconds: Unix epoch time in UTC seconds (for example 1778245150).
ordinal: MongoDB oplog increment within that same second (the i component of Timestamp(t, i)).

Accepted values:

seconds must be a non-negative integer.
ordinal is optional; when omitted, it defaults to 0.
ordinal must also be a non-negative integer.
Invalid formats (extra separators, non-numeric values, negatives) are rejected before restore starts.

Meaning:

1778245150 means 1778245150:0.
1778245150:3 means replay until the oplog position t=1778245150, i=3.
Use :ordinal when multiple oplog entries share the same second and you need a deterministic cut point.

Planner behavior:

If replay_to is not set, restore automatically replays to the end of the selected chain.
If replay_to is outside the selected Full+Incremental chain boundaries, restore is rejected.
replay_to is relevant only when oplog replay is used (replica-set incremental recovery path).

Examples:

Replay to exact second with default ordinal 0

replay_to=1778245150

Replay to specific oplog entry within the same second

replay_to=1778245150:3

General Examples

Overwrite existing target collections

conflict_strategy=drop

Preserve existing collections and restore only missing ones

conflict_strategy=skip

Restore only two collection names across selected databases

collection="widgets,events"

Remap databases during restore

map_db="appdb=appdb_restored,logs=logs_recovered"

Replica-set point-in-time restore with oplog cutoff

replay_to=1778245150:3

Isolated DR with explicit admin replay (supported targets)

isolated_dr=yes
recover_admin=yes

Dry-run preflight report for CI/CD checks

dry_run=yes
report_format=json

Combined selective restore with overwrite policy

conflict_strategy=drop
map_db="appdb=appdb_stage"
collection="widgets"
skip_security=yes