Bacula

1. Visão geral e contexto

O Bacula é um sistema de backup open‑source (AGPLv3) baseado em arquitetura cliente‑servidor, projetado para gerenciar backups centralizados de múltiplos servidores, estações de trabalho e dispositivos de rede. Ele se destaca em ambientes com dezenas ou centenas de clientes, oferecendo um catálogo robusto em banco de dados (PostgreSQL, MySQL, SQLite) que indexa metadados de todos os backups, permitindo restaurações granulares e políticas de retenção sofisticadas.

Diferentemente de ferramentas como restic ou Borg, o Bacula não realiza deduplicação em nível de bloco, mas compensa com suporte nativo a fitas magnéticas (LTO), replicação entre Storage Daemons e um modelo de agendamento flexível. Para ISPs que precisam de air‑gap físico (fitas removíveis) e conformidade com a regra 3‑2‑1‑1‑0, o Bacula continua sendo uma escolha relevante.

2. Arquitetura — Director, SD, FD e Catálogo

O Bacula é composto por três daemons principais e um banco de dados central (Catálogo):

Accurate mode: por padrão, o Bacula usa o timestamp e tamanho do arquivo para decidir se ele foi modificado. O "Accurate mode" (opção Accurate = yes no Job) força uma verificação adicional via checksum (MD5/SHA1), garantindo que alterações sutis (ex.: corrupção silenciosa) sejam detectadas — essencial para conformidade com a LGPD que exige integridade dos dados.

3. Instalação (Debian/Ubuntu) + TLS

No servidor central (Director + Storage Daemon + catálogo PostgreSQL):

apt update
apt install bacula-director bacula-sd bacula-console postgresql

# Escolha PostgreSQL como backend do catálogo durante a instalação (recomendado)

# Nos clientes (ex.: servidor RADIUS)
apt install bacula-fd

Comunicação segura com TLS: por padrão, as conexões entre Director, SD e FD não são criptografadas. Para ativar TLS (recomendado para qualquer tráfego fora de localhost), adicione em cada configuração:

Director { ... TLS Enable = yes TLS Require = yes TLS Certificate = /etc/bacula/certs/dir-cert.pem TLS Key = /etc/bacula/certs/dir-key.pem }

Verificação: systemctl status bacula-director bacula-sd e ss -tlnp | grep -E '910[1-3]'.

4. Job de backup — servidor RADIUS + backup do Catálogo

Trecho de bacula-dir.conf configurando cliente e job:

Client { Name = radius-server-fd Address = 10.0.0.5 FDPort = 9102 Catalog = MyCatalog Password = "senha-forte" TLS Enable = yes }

FileSet { Name = "RadiusFileSet" Include { Options { signature = MD5; compression = GZIP; Accurate = yes } File = /etc/freeradius File = /var/lib/mysql-dump } }

Job { Name = "Backup-Radius" Type = Backup Client = radius-server-fd FileSet = "RadiusFileSet" Schedule = "DiarioNoturno" Storage = File1 Pool = Diario Messages = Standard Priority = 10 RunBeforeJob = "/usr/local/bin/dump-radius-db.sh" }

O script dump-radius-db.sh deve conter o mysqldump adequado. Backup do próprio Catálogo: crie um job separado que execute bacula-dir -c /etc/bacula/bacula-dir.conf --dump e armazene esse bootstrap em local seguro, pois ele é essencial para recriar o catálogo após um desastre total.

5. Agendamento, volumes, pools e retenção

Schedule { Name = "DiarioNoturno" Run = Full 1st sun at 23:00 Run = Incremental mon-sat at 23:00 }

Pool { Name = Diario Pool Type = Backup Recycle = yes AutoPrune = yes Volume Retention = 30 days Maximum Volume Bytes = 10G Maximum Volumes = 50 }

Pool agrupa Volumes (unidades de armazenamento) com política de retenção comum. Esse exemplo faz Full semanal + Incremental diário, retendo 30 dias. Cada Volume limita o tamanho (ex.: 10 GB) para facilitar a gestão e a cópia off-site.

6. Cópia off-site (duplicação) e air-gap

A forma nativa é configurar um segundo Storage Daemon em outro local físico e um Job do tipo Copy ou Migrate para replicar os Volumes entre os Storages. Para air-gap (fita), o Bacula gerencia diretamente dispositivos de fita (LTO) — o simples fato de remover a fita do drive já cria o isolamento físico.

Alternativa híbrida: após o backup local, um script RunAfterJob pode sincronizar o Volume para um bucket S3 com Object Lock (imutabilidade), atendendo ao requisito de cópia imutável da regra 3-2-1-1-0.

7. Restauração — bconsole e recuperação de desastre

$ bconsole
* restore
# Opção "Select the most recent backup for a client"
Client: radius-server-fd
# Navegador de arquivos (estilo shell)
cwd /etc/freeradius
mark *
done
# Escolha destino (ex.: /restore-tmp para teste)
yes
* status dir

Recuperação de desastre (catálogo perdido): se o servidor central for destruído, recrie o Bacula a partir do backup do bootstrap (arquivo bootstrap.bsr) e do último backup do Catálogo. Procedimento completo está na documentação oficial.

8. Teste de restore automatizado (exigência LGPD)

A LGPD (Art. 46) exige medidas de recuperação; a regra 3-2-1-1-0 adiciona "0 erros" = testes periódicos. Script automatizado:

#!/bin/bash
# teste-restore-bacula.sh
echo -e "restore client=radius-server-fd select all done yes" | bconsole
sleep 60
ULTIMO_JOB=$(echo "list jobs" | bconsole | grep Restore | tail -1)
echo "$ULTIMO_JOB" | grep -q "OK" && echo "Restore OK" || echo "FALHA — investigar"

9. Monitoramento — logs, SNMP traps, script health check

O Director escreve logs em /var/log/bacula/bacula.log. Para monitorar via Zabbix, PRTG ou LibreNMS, crie um script que retorne 0 (sucesso) ou 2 (falha) analisando o último job.

#!/bin/bash
# check_bacula_job.sh
LOG="/var/log/bacula/bacula.log"
JOB_NAME="Backup-Radius"
if grep "Termination: Backup OK.*$JOB_NAME" $LOG | tail -1 | grep -q OK; then
  echo "OK - Último backup de $JOB_NAME"
  exit 0
else
  echo "CRITICAL - Falha no backup de $JOB_NAME"
  exit 2
fi

Para SNMP traps, o Bacula pode enviar eventos via bsmtp ou script pós-job que aciona o daemon SNMP do sistema. Consulte a documentação do seu NMS para integração.

10. Dimensionamento e métricas

Ao planejar a capacidade, considere:

• Volume médio por job Full: ex.: 500 MB (dados RADIUS compactados).
• Incrementos diários: ~5% do full = 25 MB.
• Retenção: 30 dias → 1 Full (500 MB) + 29 Incrementais (29×25 MB) = ~1.2 GB por ciclo.
• Catálogo: pode crescer 5–10% do tamanho dos dados backupeados, exigindo manutenção periódica (bconsole → prune).
• I/O do Storage Daemon: utilizar discos separados do sistema, de preferência em RAID 10 ou SSD para fitas virtuais.

11. Comparativo com restic/Borg

12. Glossário

13. Referências

• Documentação oficial do Bacula (bacula.org) — manuais, howtos.
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems (para políticas de backup e recuperação).
• CISA — #StopRansomware Guide (justificativa para air-gap e imutabilidade).
• Páginas relacionadas: Regra 3-2-1(-1-0), restic, BorgBackup, LGPD.

Conteúdo técnico independente. Comandos e configurações refletem o funcionamento do software.