From Rubrik to Bacula

Teams leave Rubrik for Bacula when the subscription and appliance refresh cost outgrows the value, and they want a backup stack they own outright. Bacula is open-source, runs on commodity Linux and cheap storage, and scales to large estates without per-node licensing. The trade is plain: you are giving up a turnkey appliance for a system you assemble and operate yourself. This guide treats backup migration as its own discipline, because it has one rule that overrides everything else.

The rule that governs every backup migration

You cannot abandon old backups until their retention expires.

A backup product is only as good as its oldest recoverable point. If your policy says keep monthlies for seven years, you must be able to restore a seven-year-old monthly on the day you finally decommission Rubrik. That means Rubrik stays alive, licensed, and restorable for the entire retention window while Bacula runs alongside it. There is no clever shortcut. Plan and budget for an overlap measured in months or years, not weeks.

Map Rubrik concepts to Bacula

Rubrik organizes protection around SLA Domains. Bacula splits the same responsibility across several configuration objects, and understanding the mapping is most of the design work.

• A Rubrik SLA Domain becomes a Bacula Job plus a Schedule. Frequency and timing live in the Schedule; the Job ties together what, where, and how.
• What gets backed up becomes a FileSet, with include and exclude rules.
• Retention and physical placement become a Pool. Volume retention on the Pool is how Bacula enforces how long data lives.

Job {
  Name = "fileserver-daily"
  Type = Backup
  Level = Incremental
  Client = fileserver-fd
  FileSet = "FullSet"
  Schedule = "WeeklyCycle"
  Pool = "MonthlyPool"
  Messages = Standard
}

Deploy the components

Bacula is several daemons, not one box.

• The Director (bacula-dir) is the brain. It schedules jobs and holds the configuration.
• A File Daemon (bacula-fd) runs on every machine you protect.
• The Storage Daemon (bacula-sd) writes to disk, tape, or object storage.
• The Catalog is a database, almost always PostgreSQL, that records every file in every backup.

Stand up the Director and Storage Daemon first, push File Daemons to clients, then test connectivity with bconsole before scheduling anything real.

Re-baseline with fresh fulls

Bacula cannot read Rubrik’s backups. You start clean. Schedule full backups of every client into Bacula, then layer incrementals or differentials on top. Until that first Bacula full completes and verifies, Rubrik is still your only line of defense for that system. Stagger the fulls so you do not saturate the network.

Test restores, not just backups

A backup you have never restored is a rumor. For every job class, perform a real restore into a scratch location and diff against source. Use Bacula’s Verify job with VolumeToCatalog to catch silent corruption. Schedule restore drills on a calendar, because the moment you trust green job logs without testing is the moment you have a recovery gap you cannot see.

Protect the catalog

This is the failure mode that ruins Bacula deployments. If you lose the Catalog, you lose the index that maps files to volumes, and your backups become an unsearchable blob. Back up the Catalog itself on every cycle (Bacula ships a BackupCatalog job for exactly this), replicate the PostgreSQL database, and store a copy off the backup server. Treat the Catalog as the most precious thing in the system, because it is.

What maps cleanly, and what doesn’t

The SLA Domain is a deliberately high-level abstraction: you assign a workload to a domain and Rubrik decides frequency, retention, and placement for you. Bacula pushes those decisions back into explicit config, which is more work but also more transparent. When you translate, resist the urge to collapse several SLA Domains into one generic Job, because the whole point of the domains was that different workloads had different recovery obligations. Keep monthlies and yearlies in their own Pools so retention is enforced independently, and mirror each SLA’s frequency in its Schedule rather than averaging them.

What does not carry over is the appliance experience itself. Rubrik’s global dedup, single search pane, immutable air-gapped snapshots, and instant VM boot are product features you were paying for, and Bacula does not reproduce them by default. Some you can approximate with engineering (object-lock storage for immutability, storage-side dedup), and some you simply operate differently (restore by copying data back rather than instant mount). Decide which of these were real requirements versus conveniences before you commit, and write the answer down so the trade is a choice rather than a surprise.

Cutover and aging out Rubrik

Cutover is gradual, not a flag day. Once a workload’s first Bacula full has verified and you have proven a real restore of it, you can make Bacula primary for that workload while Rubrik continues to hold its pre-cutover history read-only. Move workloads over in waves rather than all at once, so any surprise surfaces on a small blast radius. Throughout the overlap, new backups land in Bacula while any restore of older data still comes from Rubrik, and you retire Rubrik only after its last obligated recovery point expires. Because that overlap runs the full length of your longest retention, the double-running window, Rubrik subscription plus Bacula storage and staff time together, is where this migration actually costs money, so budget for it explicitly rather than assuming savings begin on day one.

Where Rubrik still wins

Be honest before you commit:

• Turnkey operation. Rubrik is a polished appliance; Bacula is config files and daemons you maintain.
• Ransomware immutability. Rubrik’s immutable, air-gapped snapshots are first-class. You can approximate this in Bacula with object-lock storage, but you build it yourself.
• Instant recovery. Rubrik can boot a VM directly from a backup in minutes. Bacula restores by copying data back, which is slower.
• Global dedup and a single search pane. Matching those in open-source takes real engineering.

Weighing it up

Migrating Rubrik to Bacula trades subscription cost and appliance lock-in for a stack you own and operate. The non-negotiable is overlap: run both through the entire retention window, because you cannot delete a recovery point you are still obligated to provide. Map SLA Domains to Jobs, FileSets, and Pools, re-baseline with fresh fulls, drill your restores, and guard the Catalog above all else. Model the parallel-run overlap, storage, and staff time in the calculator above, since that double-running window is where this migration actually costs you money.