PodHeitor FD: el cliente Bacula que, en Rust, salió más rápido en todos los escenarios que probamos

PodHeitor FD: el cliente Bacula que, en Rust, salió más rápido en todos los escenarios que probamos

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

Mediana de tiempo de backup por celda — PodHeitor FD vs bacula-fd 15.0.3
Mediana de tiempo de backup por celda, 10 réplicas. Menor es mejor. Las anotaciones muestran la reducción porcentual de PodHeitor FD frente a 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%
Throughput sostenido por celda — PodHeitor FD vs bacula-fd 15.0.3
Throughput de backup sostenido por celda. Mayor es mejor. El salto más expresivo está en Mixed/Incremental: 3× más bytes útiles por segundo de ventana.

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-fd actual, 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:


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: pt-brPortuguês (Portugués, Brasil)enEnglish (Inglés)esEspañol

Deja una respuesta