Migrating from Bacula

NGBackup includes a migration path from Bacula Community 15. It can read an existing Bacula catalog, volumes and configuration, so you can move over incrementally, even run mixed deployments during the transition, without a forklift migration.

What the migration tooling handles

• Configuration import — your Director{}, Storage{}, Client{}, Job{}, FileSet{} resources are imported.
• Catalog & volumes — point NGBackup at an existing catalog and storage and resume.
• Concepts — jobs, levels, pools, schedules, retention map across cleanly.
• Console output — existing scripts, dashboards and parsers that scrape a legacy console keep working against backup-console, so your operational tooling survives the move. Every console verb also speaks output=json, a stable JSON envelope the Web and Desktop consoles use.

What changed (names only)

Bacula	NGBackup
bacula-dir	backup-dir
bacula-sd	backup-sd
bacula-fd	backup-fd
bconsole	backup-console
bcopy / bextract / bls / bscan	backup-copy / backup-extract / backup-ls / backup-scan
/opt/bacula/{bin,etc}	/opt/backup/{bin,etc}

Suggested path

1. Stand up a NGBackup Director/SD alongside Bacula.
2. Point it at a copy of the catalog; validate configs with backup-dir -t.
3. Move clients over as you go; add the NGBackup plugins (dedup, ransomware, replication) for capabilities Bacula Community doesn’t have.