Commvault is a comprehensive data-protection platform, but its licensing, historically per-front-end-terabyte or capacity-based, plus the CommServe and MediaAgent footprint, is a recurring cost that scales with your data. Bacula is a mature open-source backup system (Director, Storage daemon, File daemon) that many teams adopt to remove that license line. The defining constraint of any backup migration applies here in full: you cannot abandon your old backups until their retention has expired. That single fact shapes the entire plan, you run both systems in parallel for as long as your longest retention policy, and only then decommission Commvault.
Map the model: subclients → jobs
Commvault and Bacula describe the same operations with different nouns. The migration is largely a translation exercise:
| Commvault | Bacula |
|---|---|
| CommServe (control) | Director (bacula-dir) + catalog DB |
| MediaAgent (data mover) | Storage daemon (bacula-sd) |
| Agent on a client | File daemon (bacula-fd) |
| Subclient (what to protect) | FileSet + Job |
| Schedule policy | Schedule |
| Storage policy / retention | Pool + retention settings |
Work through each Commvault subclient and express it as a Bacula FileSet (what to include/exclude), a Job (the client + schedule + pool), and a Pool (the media and retention). Get the FileSets right, over-broad includes inflate every backup; missed paths are silent data loss.
A Commvault estate usually carries more subclients than you need, because they accumulate as workloads come and go. Treat the migration as a chance to re-inventory: confirm which clients still require protection, which subclients overlap, and where retention was set generously by default rather than by policy. Every subclient you carry forward becomes ongoing Bacula config you have to maintain, so prune deliberately before you translate. Where a Commvault storage policy encoded a specific GFS-style retention, re-express it precisely in the Bacula Pool rather than approximating, because auditors check the retention math, not the intent.
Stand it up and re-baseline
- Deploy the components, Director plus its catalog database (PostgreSQL), one or more Storage daemons with adequate disk/tape, and File daemons on each client.
- Define Pools and retention to match your existing policy (and your compliance/legal-hold obligations), this is the part auditors care about.
- Re-baseline with full backups. Bacula starts fresh; your first Bacula backup of each client is a new full, after which incrementals/differentials proceed normally. Size the storage and the backup window for that initial full sweep.
- Test restores immediately, a backup system is only as good as its last successful restore. Run file-level and full-system restore drills before you trust it for anything.
Sequencing the re-baseline
The initial full sweep is the heaviest part of the whole project, so plan its shape. Until each client’s first Bacula full completes and verifies, Commvault is still the only recoverable copy for that system, which means the re-baseline window is also a window of concentrated dependence on the old platform. Stagger the fulls so the network and the Storage daemon are not saturated at once, and lead with the clients whose data changes least so their chains stabilize before you add incrementals or differentials. Watch the catalog database grow during this phase and confirm your Storage daemon disk keeps pace, because a stalled first full leaves that workload protected only by Commvault for longer than you intended.
The retention overlap, the rule you cannot skip
Keep the Commvault environment read-only and intact until everything it holds has aged past your retention and legal-hold requirements. During that window:
- New backups go to Bacula.
- Old restores (anything before the cutover) still come from Commvault’s catalog.
- You decommission the CommServe/MediaAgents only after the last protected point in Commvault has expired.
Pulling Commvault early to save license cost a few months sooner is how teams discover, during an audit or an incident, that a restore point they were legally required to keep is gone.
Gotchas worth flagging
- Application-aware backups. Commvault’s database/VM-aware agents (SQL, Oracle, VMware) have Bacula equivalents (plugins, pre/post scripts, the dump-then-backup pattern) but they’re not automatic, rebuild app-consistent jobs deliberately and test point-in-time restores.
- Catalog is critical. Bacula’s catalog database is your index of every backup; back it up and protect it as carefully as the data itself.
- Tape and dedup. If you relied on Commvault’s deduplication or specific tape-library integration, validate Bacula’s behaviour (and consider Bacula Enterprise or storage-side dedup) before assuming parity.
- Monitoring/reporting. Rebuild backup-success reporting and alerting; don’t run blind between Commvault’s console going away and Bacula reporting being wired up.
The takeaway
Commvault → Bacula removes capacity-based licensing in exchange for running and tuning an open-source stack yourself. Translate subclients into FileSets/Jobs/Pools, re-baseline with fresh fulls, and test restores before trusting anything. Above all, run both systems in parallel through your full retention window and decommission Commvault only after its last required restore point expires. Model the removed license cost against the storage and operational time to run Bacula in the calculator above, and treat retention compliance, not speed, as the gating factor.