Sexta à noite eu fechei o último commit do PodHeitor FD — o cliente Bacula (File Daemon) que escrevi do zero em Rust, byte-for-byte compatível com o protocolo de fio do Bacula Community 15.0.3. Sábado e domingo foram inteiros dedicados a uma coisa só: medir. Não medir de qualquer jeito — medir do jeito certo, seguindo a metodologia de dez passos do Raj Jain (The Art of Computer Systems Performance Analysis, 1991), que é a referência canônica para esse tipo de comparação.
A pergunta que eu queria responder era simples: “o cliente que reescrevi é, de fato, mais rápido que o bacula-fd oficial — e em quais cenários?”
A resposta, eu agora posso afirmar com números: sim, em todos os nove cenários medidos.
Como rodou o experimento
Montei uma matriz de 9 células — três cargas de trabalho (Manyfiles, Media, Mixed) cruzadas com três níveis de backup (Full, Differential, Incremental). Cada célula rodou 10 réplicas (180 jobs no total), todos disparados pelo Bacula Director e Storage Daemon originais, sem modificação — ou seja: a fidelidade de protocolo está preservada, o que muda é só o cliente.
O bacula-fd 15.0.3 da Community foi a baseline. O PodHeitor FD foi o desafiante.
O que os dados mostraram
bacula-fd 15.0.3.- 9 vitórias em 9 células, todas por mediana
- Pior caso: −5,3% (Manyfiles/Differential) — empate técnico, ainda assim a favor do PodHeitor FD
- Melhor caso: −66,7% (Mixed/Incremental) — o cenário mais comum em rotinas horárias
- Média geométrica de ganho ≈ −21%
O que isso significa para quem opera Bacula
Os ganhos pesados caíram exatamente onde o operador roda mais frequentemente: Incrementais e Diferenciais. Tradução em vocabulário de SLA:
- Uma janela de RPO horário em dados mistos (laptops, servidores de aplicação) que antes consumia ~3 segundos de FD por cliente, agora consome ~1 segundo. Cabem 3× mais clientes no mesmo Director, ou a mesma frota com cadência tripla.
- Em ambientes Manyfiles (árvores de configuração, repositórios de código), o Incremental ficou 35% mais rápido — o que comprime a janela noturna do mesmo fator e libera tempo para verificação de integridade ou migração de mídia.
Por que ainda não está pronto
Honestamente: está ótimo, mas dá para melhorar. A análise de cauda (P90) mostrou que em alguns cenários Media e Mixed o PodHeitor FD tem cauda um pouco mais pesada que o bacula-fd. A próxima iteração de engenharia já tem essa mira no alvo, e a mesma matriz Raj-Jain vai ser o teste de regressão.
A análise de restore (lado do RTO) ainda não está medida — é o próximo experimento agendado, e vai sair em um whitepaper de continuação.
Por que reescrever em Rust importa
Rust é um diferencial concreto, não modismo. O cliente FD roda com privilégios elevados em toda máquina protegida — esse é exatamente o tipo de processo onde memory-safety nativa, ausência de garbage collector e estabilidade de longo prazo deixam de ser detalhe acadêmico e viram redução de risco operacional auditável. Trabalhos recentes sobre Rust-for-Linux confirmam o que o RustBelt já tinha provado formalmente: a disciplina de tipos do Rust elimina, por construção, classes inteiras de bugs que historicamente afligiram daemons C/C++ longevos.
Whitepaper técnico completo
Se você quer ver a metodologia em detalhe (matriz Raj-Jain, statistical setup, threats to validity, e os números célula a célula), publiquei o paper inteiro:
📄 Baixar whitepaper técnico (PDF) — inclui tabela de medianas/médias/P90 das 9 células, gráficos completos (boxplots, RPO shrink factor) e a discussão honesta sobre tail behavior e limitações.
🚀 PodHeitor FD em trial — sem custo, com acompanhamento
Se você opera Bacula em produção e quer ver, no seu próprio ambiente, se esses números se sustentam — abri slots de trial guiado do PodHeitor FD para um conjunto pequeno de empresas.
O que está incluso no trial:
- Binário do PodHeitor FD (RPM/DEB) compatível com Bacula Community 15.x e Bacula Enterprise
- Configuração assistida em UMA das suas máquinas em produção (call de 1h)
- 30 dias de uso ilimitado, com instrumentação igual à do whitepaper
- Comparação A/B com seu
bacula-fdatual, no SEU workload - Relatório executivo no fim com os deltas medidos no seu ambiente
O que peço em troca:
- Permissão de citar o nome da sua empresa (anonimizável) em uma futura republicação dos números
- Feedback honesto sobre o que faltou ou quebrou
Como participar:
- 💬 WhatsApp prioritário: +1 (786) 726-1749
- ✉️ E-mail: heitor@opentechs.lat
- 🩺 Diagnóstico gratuito de 30 minutos — no fim da call já decidimos se o trial encaixa no seu caso
Sobre o autor. Heitor Faria é consultor Bacula desde 2009, mantém o canal técnico @podheitor e desenvolve a suíte PodHeitor de 21 plugins comerciais sobre Bacula. Doutor em Engenharia Elétrica (UnB) com tese em desduplicação de dados, autor de Bacula: Backup e Recuperação de Dados de Forma Segura (Novatec) e instrutor há 10+ anos.
Disponível em: 
Português
English (Inglês)
Español (Espanhol)
