El viernes por la noche cerré el último commit de PodHeitor FD — el cliente Bacula (File Daemon) que reescribí desde cero en Rust, byte-for-byte compatible con el protocolo de cable de Bacula Community 15.0.3. Sábado y domingo enteros dedicados a una sola cosa: medir. Y no medir de cualquier forma — medir bien, siguiendo la metodología de diez pasos de Raj Jain (The Art of Computer Systems Performance Analysis, 1991), la referencia canónica para este tipo de comparación.
La pregunta que quería responder era simple: «¿el cliente que reescribí es, de hecho, más rápido que el bacula-fd oficial — y en qué escenarios?»
La respuesta, ahora puedo afirmarla con números: sí, en los nueve escenarios medidos.
Cómo se ejecutó el experimento
Monté una matriz de 9 celdas — tres cargas de trabajo (Manyfiles, Media, Mixed) cruzadas con tres niveles de backup (Full, Differential, Incremental). Cada celda corrió 10 réplicas (180 jobs en total), todos disparados por el Bacula Director y Storage Daemon originales, sin modificación — es decir: la fidelidad de protocolo está preservada, lo único que cambia es el cliente.
El bacula-fd 15.0.3 de Community fue la baseline. PodHeitor FD fue el desafiante.
Lo que mostraron los datos

bacula-fd 15.0.3.- 9 victorias en 9 celdas, todas por mediana
- Peor caso: −5,3% (Manyfiles/Differential) — empate técnico, aún así a favor de PodHeitor FD
- Mejor caso: −66,7% (Mixed/Incremental) — el escenario más común en rutinas horarias
- Media geométrica de ganancia ≈ −21%

Qué significa para quien opera Bacula
Las ganancias más fuertes cayeron exactamente donde el operador corre con más frecuencia: Incrementales y Diferenciales. Traducido al vocabulario de SLA:
- Una ventana de RPO horario en datos mixtos (laptops de desarrolladores, servidores de aplicación) que antes consumía ~3 segundos de FD por cliente, ahora consume ~1 segundo. Caben 3× más clientes en el mismo Director, o la misma flota con cadencia triple.
- En entornos Manyfiles (árboles de configuración, repositorios de código), el Incremental quedó 35% más rápido — comprimiendo la ventana nocturna en el mismo factor y liberando tiempo para verificación de integridad o migración de medios.
Por qué todavía no está terminado
Honestamente: está excelente, pero se puede mejorar. El análisis de cola (P90) mostró que en algunos escenarios Media y Mixed PodHeitor FD tiene una cola un poco más pesada que bacula-fd. La próxima iteración de ingeniería ya tiene esa mira en el blanco, y la misma matriz Raj-Jain será la prueba de regresión.
El análisis de restore (lado de RTO) aún no está medido — es el siguiente experimento agendado y saldrá en un whitepaper de continuación.
Por qué reescribir en Rust importa
Rust es un diferencial concreto, no una moda. El cliente FD corre con privilegios elevados en cada máquina protegida — exactamente el tipo de proceso donde la memory-safety nativa, la ausencia de garbage collector y la estabilidad a largo plazo dejan de ser detalle académico y se convierten en reducción auditable de riesgo operacional. Trabajos recientes sobre Rust-for-Linux confirman lo que RustBelt ya había probado formalmente: la disciplina de tipos de Rust elimina, por construcción, clases enteras de bugs que históricamente afligieron a daemons C/C++ longevos.
Whitepaper técnico completo
Si quieres ver la metodología en detalle (matriz Raj-Jain, configuración estadística, threats to validity y los números celda a celda), publiqué el paper completo:
📄 Descargar whitepaper técnico (PDF) — incluye tabla de medianas/medias/P90 de las 9 celdas, gráficos completos (boxplots, RPO shrink factor) y la discusión honesta sobre tail behavior y limitaciones.
🚀 PodHeitor FD en trial — sin costo, con acompañamiento
Si operas Bacula en producción y quieres verificar, en tu propio entorno, si estos números se sostienen — abrí slots de trial guiado de PodHeitor FD para un conjunto pequeño de empresas.
Lo que incluye el trial:
- Binario de PodHeitor FD (RPM/DEB) compatible con Bacula Community 15.x y Bacula Enterprise
- Configuración asistida en UNA de tus máquinas en producción (call de 1h)
- 30 días de uso ilimitado, con la misma instrumentación del whitepaper
- Comparación A/B con tu
bacula-fdactual, en TU workload - Reporte ejecutivo al final con los deltas medidos en tu entorno
Lo que pido a cambio:
- Permiso para citar el nombre de tu empresa (anonimizable) en una futura republicación de los números
- Feedback honesto sobre lo que faltó o se rompió
Cómo participar:
- 💬 WhatsApp prioritario: +1 (786) 726-1749
- ✉️ Email: heitor@opentechs.lat
- 🩺 Diagnóstico gratuito de 30 minutos — al final de la call ya decidimos si el trial encaja en tu caso
Sobre el autor. Heitor Faria es consultor Bacula desde 2009, mantiene el canal técnico @podheitor y desarrolla la suite PodHeitor de 21 plugins comerciales sobre Bacula. Doctor en Ingeniería Eléctrica (UnB) con tesis en deduplicación de datos, autor de Bacula: Backup e Recuperação de Dados de Forma Segura (Novatec) e instructor desde hace más de 10 años.
Disponível em:
Português (Portugués, Brasil)
English (Inglés)
Español