Veritas NetBackup’s front-end-TB licensing climbs with every data-growth spurt, on top of a heavyweight master/media-server architecture and steep enterprise support renewals. Bacula is a mature, open-source enterprise backup system that removes the licensing tax for organizations with the skills to operate it. As with any backup migration, the project is really about proving restores and re-protecting workloads, you don’t convert backup catalogs, you re-baseline.
What you gain, and what you give up
You gain a capable, scriptable, no-license backup platform with a long track record (Bacula Enterprise is available if you later want commercial support). You give up NetBackup’s polished console, its breadth of out-of-the-box application/database agents, and turnkey enterprise support. Bacula is powerful but configuration-driven, it rewards teams comfortable editing config and writing job definitions. Be honest about that operational fit.
The architecture maps, but it’s different
Bacula has a distinct multi-daemon design, map NetBackup concepts to it:
- Master server → Bacula Director (orchestrates jobs, holds the catalog in PostgreSQL/MySQL).
- Media servers → Storage Daemons (write to disk/tape/object).
- Client agents → File Daemons on each protected host.
- Policies/schedules → Bacula Jobs, FileSets, Schedules, and Pools defined in config.
- Catalog → the Bacula catalog database.
This is a re-modeling exercise: NetBackup policies become Bacula job/fileset/schedule definitions, not a one-click import.
Get the FileSets right first
The FileSet is where migrations quietly go wrong. NetBackup policies often accreted include and exclude rules over years, and copying that intent into Bacula is the most detail-sensitive part of the job. An over-broad include inflates every backup and wastes storage; a missed path is silent data loss that you only discover when someone asks to restore it. Work through each policy’s backup selections deliberately, confirm the include and exclude rules against what the workload actually holds, and validate the first backup’s file list rather than assuming the FileSet is complete. Treat agent sprawl as an opportunity to consolidate: NetBackup estates often carry more client agents than are still needed, so re-inventory what still requires protection before you deploy File Daemons everywhere.
You re-protect, you don’t convert
Bacula can’t read NetBackup’s catalog or images. So you stand up Bacula, define jobs for each workload, take fresh full backups on the new platform, and keep the NetBackup environment read-only and retained until its retention (and any legal hold) ages out. Deleting the old catalog early is the only real risk here.
The migration flow
- Inventory NetBackup policies: protected clients, schedules, retention, dedup, offsite/tape copies, and RPO/RTO per workload.
- Deploy Bacula, Director + catalog DB, Storage Daemons with disk (and tape/object as needed), File Daemons on clients.
- Translate policies to Bacula jobs, FileSets, Schedules, Pools, and retention matching your NetBackup GFS scheme. Configure application-consistent backups where needed (DB plugins/pre-post scripts).
- Re-baseline, run first fulls on Bacula while NetBackup stays primary; run both in parallel.
- Test restores (the part that matters): file-level, full-system, database, and a complete DR rehearsal. Confirm backup windows fit and capacity/dedup are acceptable.
- Switch primary schedules to Bacula once restores validate; keep NetBackup read-only until retention lapses, then decommission.
First fulls, then proving them
The re-baseline is the step that actually protects data, so treat it with the weight it deserves. Your first Bacula backup of each client is a fresh full, and until that full completes and verifies, NetBackup remains the only recoverable copy for that workload. Stagger the initial fulls so the network and Storage Daemons are not saturated at once, and sequence the least-changing clients first so their chains settle quickly before you layer incrementals or differentials on top. Size both the storage and the backup window for that initial full sweep, since it is heavier than steady-state operation.
Restore testing is the acceptance gate, not an afterthought. For each job class, restore into a scratch location and diff against source: a file-level restore, a full-system restore, a database point-in-time restore where relevant, and at least one end-to-end DR rehearsal. Use Bacula’s Verify job to catch silent corruption, and confirm that tape or object targets actually recover and that offsite copies are re-established. Put restore drills on a recurring calendar rather than trusting green job logs, because the moment you rely on logs alone is the moment a recovery gap can hide.
Don’t retire the catalog too soon
Keep the NetBackup environment read-only and intact until every restore point it holds has aged past your retention and any legal-hold requirement. During the overlap, new backups go to Bacula while any restore of pre-cutover data still comes from NetBackup’s catalog, and you decommission the master, media servers, and catalog only after the last obligated restore point expires. Because NetBackup retention is often long, plan and budget for a parallel-run window measured in months or years, not weeks. That double-running overlap, the license and support you keep paying on NetBackup while Bacula ramps, is the real cost center of the migration, so account for it up front rather than being surprised by it.
What counts as done
The acceptance bar is “we can restore the workloads we care about, within RPO/RTO, including a full DR failover”, not “jobs are green.” Run real restores, verify retention and offsite copies are re-established, and confirm tape/object targets work end to end.
Where this nets out
Veritas NetBackup → Bacula removes front-end-TB licensing for teams comfortable with a config-driven platform; the work is re-modeling policies as Bacula jobs, re-baselining in parallel, and proving restores before aging out the NetBackup catalog. Model your per-TB savings in the calculator above, and treat them as illustrative until you confirm your retention, application-agent, and DR requirements, and consider Bacula Enterprise if you need vendor support.