PodHeitor FD: the Bacula client that, in Rust, came out faster on every scenario we tested

PodHeitor FD: the Bacula client that, in Rust, came out faster on every scenario we tested

Friday night I closed the last commit on the PodHeitor FD — the Bacula File Daemon I rewrote from scratch in Rust, byte-for-byte compatible with the wire protocol of Bacula Community 15.0.3. Saturday and Sunday were spent on a single thing: measuring. Not measuring any old way — measuring the right way, following Raj Jain’s ten-step methodology (The Art of Computer Systems Performance Analysis, 1991), the canonical reference for this kind of comparison.

The question I wanted to answer was simple: “is the client I rewrote actually faster than the official bacula-fd — and in which scenarios?”

The answer, I can now state with numbers: yes, in all nine scenarios measured.

How the experiment ran

I built a 9-cell matrix — three workloads (Manyfiles, Media, Mixed) crossed with three backup levels (Full, Differential, Incremental). Each cell ran 10 replicas (180 jobs total), all driven by the unmodified Bacula Director and Storage Daemon — meaning protocol fidelity is preserved; the only thing that changes is the client.

The bacula-fd 15.0.3 from Community Edition was the baseline. PodHeitor FD was the challenger.

What the data showed

Median backup time per cell — PodHeitor FD vs bacula-fd 15.0.3
Median backup wall-clock time per cell, 10 replicas. Lower is better. Annotations show the percentage reduction of PodHeitor FD relative to bacula-fd 15.0.3.
  • 9 wins out of 9 cells, all by median
  • Worst case: −5.3% (Manyfiles/Differential) — statistical tie, still in PodHeitor FD’s favour
  • Best case: −66.7% (Mixed/Incremental) — the most common scenario in hourly cadences
  • Geometric mean of gains ≈ −21%
Sustained throughput per cell — PodHeitor FD vs bacula-fd 15.0.3
Sustained backup throughput per cell. Higher is better. The most striking jump is on Mixed/Incremental: 3× more useful bytes per second of window.

What it means for Bacula operators

The heaviest gains landed exactly where operators run most frequently: Incremental and Differential. Translated to SLA vocabulary:

  • An hourly RPO window on mixed data (developer laptops, application servers) that previously consumed ~3 seconds of FD time per client now consumes ~1 second. 3× more clients fit on the same Director, or the same fleet runs at triple cadence.
  • In Manyfiles environments (configuration trees, source repositories), Incremental got 35% faster — compressing the nightly window by the same factor and freeing time for integrity verification or media migration.

Why it isn’t done yet

Honestly: it’s great, but it can get better. Tail (P90) analysis showed that on some Media and Mixed cells PodHeitor FD has a slightly heavier tail than bacula-fd. The next engineering iteration is targeted at exactly that, and the same Raj-Jain matrix will be the regression test.

The restore analysis (RTO side) hasn’t been measured yet — it’s the next experiment on the schedule, and it will land in a follow-up whitepaper.

Why rewriting in Rust matters

Rust is a concrete differentiator, not a fad. The FD client runs with elevated privileges on every protected machine — exactly the kind of process where native memory safety, the absence of a garbage collector, and long-term stability stop being academic detail and become auditable operational risk reduction. Recent work on Rust-for-Linux confirms what RustBelt had already proven formally: Rust’s type discipline rules out, by construction, entire classes of bugs that have historically afflicted long-lived C/C++ daemons.

Full technical whitepaper

If you want to see the methodology in detail (Raj-Jain matrix, statistical setup, threats to validity, and the per-cell numbers), I published the full paper:

📄 Download technical whitepaper (PDF) — includes the median/mean/P90 table for the 9 cells, full plots (boxplots, RPO shrink factor), and the honest discussion of tail behaviour and limitations.


🚀 PodHeitor FD trial — at no cost, with hands-on support

If you operate Bacula in production and want to verify, in your own environment, whether these numbers hold up — I’ve opened guided trial slots for PodHeitor FD for a small set of companies.

What’s included in the trial:

  • PodHeitor FD binary (RPM/DEB) compatible with Bacula Community 15.x and Bacula Enterprise
  • Assisted setup on ONE of your production machines (1-hour call)
  • 30 days of unlimited use, with the same instrumentation as the whitepaper
  • A/B comparison against your current bacula-fd, on YOUR workload
  • Executive report at the end with the deltas measured in your environment

What I ask in return:

  • Permission to cite your company’s name (anonymisable) in a future republication of the numbers
  • Honest feedback on what was missing or broke

How to join:


About the author. Heitor Faria has been a Bacula consultant since 2009, runs the technical channel @podheitor, and develops the PodHeitor suite of 21 commercial plugins on top of Bacula. PhD in Electrical Engineering (UnB) with a thesis on data deduplication, author of Bacula: Backup e Recuperação de Dados de Forma Segura (Novatec), and a 10+-year instructor.

Disponível em: pt-brPortuguês (Portuguese (Brazil))enEnglishesEspañol (Spanish)

Leave a Reply