Blog

Whitepaper — PodHeitor File Replication (BRC)

Whitepaper — PodHeitor File Replication (BRC)

Replicação contínua entre clusters PodHeitor. Replica jobs cross-site em tempo real, com filtro de pool, transformação de cliente, e dedup global compartilhado entre origem e destino.

  • Replicação contínua entre Storage Daemons — RPO em minutos.
  • Transformação cross-site — renomeio de Storage, Pool e Client no destino, automático.
  • Dedup compartilhada — só envia chunks novos, banda mínima.
  • Bandwidth throttling adaptativo — não compete com produção, recupera capacidade quando ociosa.
  • Verify automático no destino — checksums per-chunk garantem integridade end-to-end.

Comece em 30 dias, no mínimo 50% mais barato. Trial gratuito, RPMs e DEBs assinados, suporte direto com Heitor Faria. Substitua sua licença Veeam, Commvault ou Bacula Enterprise sem quebrar a janela noturna.

Solicitar trial gratuito de 30 dias →

Sumário

  1. Resumo Executivo
  2. Descrição do Problema
  3. Visão Geral da Solução
  4. Arquitetura
  5. Casos de Uso
  6. Instalação
  7. Referência de Configuração
  8. Dimensionamento e Requisitos
  9. Matriz de Compatibilidade
  10. Opções de Backup e Restauração
  11. Exemplos de Configuração
  12. Procedimentos Operacionais
  13. Segurança
  14. Conformidade e Relatórios
  15. Considerações de Desempenho
  16. Resolução de Problemas
  17. Evidências Validadas
  18. Roadmap
  19. Informações Comerciais

1. Resumo Executivo

PodHeitor BRC (Backup, Replication and Conversion) é um plugin comercial para o PodHeitor Backup Edition que transforma o Storage Daemon em um motor de replicação de arquivos em tempo real. Ao interceptar os fluxos de dados de backup no nível do SD, o BRC replica os arquivos para um sistema de arquivos de destino enquanto o backup está sendo realizado — entregando disponibilidade imediata dos arquivos sem a latência de uma restauração tradicional do Bacula.

Principais Benefícios

Benefício Impacto
Recuperação instantânea de arquivos Acesse os arquivos replicados diretamente — sem necessidade de fluxo de restauração
Redução do RTO Recuperação em minutos em vez de horas
Integração nativa com o Bacula Aproveita a infraestrutura de backup existente — sem agentes adicionais
Automação de conformidade Relatórios de RPO/RTO para auditoria e governança
Fidelidade de metadados Preservação completa de ACLs, xattrs, arquivos esparsos, proprietário e timestamps
Recursos empresariais Criptografia, grupos de consistência, multi-site, failover, snapshots

Como Funciona

  1. Um job de backup padrão do Bacula é executado (Full, Incremental ou Differential)
  2. O File Daemon envia os dados dos arquivos ao Storage Daemon normalmente
  3. O plugin PodHeitor BRC intercepta o fluxo de dados no SD
  4. Os arquivos são gravados em tempo real no destino de réplica configurado
  5. O backup é concluído normalmente — os arquivos ficam disponíveis tanto no volume do Bacula quanto no caminho da réplica

Resultado: uma cópia de DR aquecida, sempre sincronizada com o último backup e acessível como arquivos regulares no sistema de arquivos.

2. Descrição do Problema

Os fluxos de restauração tradicionais do Bacula exigem:

  1. Identificar o conjunto de backup correto
  2. Iniciar um job de restauração via bconsole ou Bacularis
  3. Aguardar a leitura dos dados nos volumes de armazenamento
  4. Gravar os arquivos no local de destino

Para grandes volumes de dados, esse processo pode levar horas para ser concluído. Em cenários de recuperação de desastres, cada minuto de indisponibilidade impacta diretamente as operações do negócio.

Desafios Operacionais

  • RTO elevado: tempo de restauração proporcional ao tamanho do conjunto de dados
  • Intervenção manual: a restauração requer ação do operador
  • Sem acesso imediato: arquivos indisponíveis até a conclusão da restauração
  • Validação de DR: difícil verificar a recuperabilidade sem realizar uma restauração de fato
  • Carga de conformidade: comprovar a aderência ao RPO/RTO requer evidências manuais

O PodHeitor BRC resolve todos esses desafios mantendo uma réplica continuamente sincronizada e sempre pronta para uso.

3. Visão Geral da Solução

Três Pilares

B — Orquestração de Backup

O plugin opera de forma transparente dentro do fluxo de backup existente do Bacula. Suporta todos os três níveis de backup (Full, Incremental, Differential) e mantém fidelidade total de metadados, incluindo ACLs POSIX, atributos estendidos, otimização de arquivos esparsos e proprietário/permissões/timestamps precisos.

Um recurso diferencial é o modo FIFO, que elimina a sobrecarga de I/O local fazendo o backend ler os blocos de volume do Bacula diretamente de um named pipe. Isso significa que o Storage Daemon não grava em um volume tradicional — o plugin processa o fluxo de dados em voo.

R — Replicação

Dois modos de replicação estão disponíveis:

  • Mirror: mantém uma cópia 1:1 da origem. Em backups Full, arquivos órfãos (presentes na réplica, mas excluídos da origem) são removidos automaticamente.
  • Retention: mantém cópias versionadas dos arquivos, permitindo recuperação a um ponto no tempo a partir da própria réplica.

Recursos avançados de replicação incluem:

  • BLAKE3 skip-unchanged: compara hashes do conteúdo dos arquivos para evitar gravações redundantes
  • Multi-site fan-out: replica para múltiplos destinos simultaneamente com limites de bandwidth por destino
  • Throttling de bandwidth: limites de taxa de transferência configuráveis
  • Grupos de consistência: coordena a replicação entre múltiplos jobs relacionados
  • Automação de failover: hooks de verificação de saúde, promoção e rebaixamento para alternância automática de DR
  • Integração com snapshots: criação de snapshots pré-replicação no LVM, ZFS ou Btrfs

C — Conversão e Normalização

O plugin processa o fluxo de dados do Bacula, tratando:

  • Descompressão: fluxos comprimidos com zlib e LZ4 são descomprimidos de forma transparente
  • Criptografia em repouso: criptografia AES-256-GCM opcional para os arquivos replicados
  • Relatórios de conformidade: relatórios automatizados de RPO/RTO nos formatos JSONL, JSON e Markdown

4. Arquitetura

Diagrama de Componentes

┌────────────────────────────────────────────────────────────────────┐
│                    BACULA INFRASTRUCTURE                           │
│                                                                    │
│  ┌──────────┐    ┌──────────────┐    ┌──────────────────┐         │
│  │  File     │───▶│  Storage     │───▶│  Rust cdylib     │         │
│  │  Daemon   │    │  Daemon      │    │  (.so / SD v13)  │         │
│  └──────────┘    └──────────────┘    └────────┬─────────┘         │
│                                                │ canal / FIFO      │
└────────────────────────────────────────────────┼──────────────────┘
                                                 │
                                                 ▼
┌────────────────────────────────────────────────────────────────────┐
│                    PODHEITOR BRC BACKEND (Rust)                     │
│                                                                    │
│  ┌──────────┐  ┌───────────┐  ┌───────────┐  ┌──────────────┐    │
│  │ Record   │─▶│ Pipeline  │─▶│ Policy    │─▶│ File Writer  │    │
│  │ Parser   │  │ (decomp/  │  │ (mirror/  │  │ (Linux/Win)  │    │
│  │          │  │  decrypt) │  │  retention)│  │              │    │
│  └──────────┘  └───────────┘  └───────────┘  └──────┬───────┘    │
│                                                      │            │
│  ┌──────────────────────────────────────────────────┐│            │
│  │ Cross-cutting: Checksum · Manifest · Logging     ││            │
│  │ Throttle · Consistency · Failover · Snapshot     ││            │
│  │ RPO/RTO Reporting · Dashboard                    ││            │
│  └──────────────────────────────────────────────────┘│            │
└──────────────────────────────────────────────────────┼────────────┘
                                                       │
                                                       ▼
                                             ┌──────────────────┐
                                             │   REPLICA TARGET │
                                             │   FILESYSTEM     │
                                             │   (ext4/XFS/     │
                                             │    Btrfs/NFS)    │
                                             └──────────────────┘

Stack Tecnológica

Componente Tecnologia Finalidade
Plugin SD (cdylib) Rust (edição 2021) — ABI SD Plugin API v13 em clean-room Integração com SD, canal de comunicação interno, gerenciamento de pipe FIFO
Backend Rust (edição 2021) Análise de registros, processamento de fluxo, gravação de arquivos
Criptografia AES-256-GCM (autenticada) Criptografia em repouso
Hashing BLAKE3 Skip-unchanged por endereçamento de conteúdo, verificação de integridade
Compressão zlib / LZ4 Descompressão de fluxo
Serialização JSON Relatórios RPO/RTO, status do dashboard, manifesto

Protocolo de Comunicação Interno

O plugin e o backend se comunicam via canal binário interno:

Fase Direção Conteúdo
1 — Hello cdylib → Backend Versão do protocolo, identificação do plugin
2 — Job Info cdylib → Backend Nome do job, ID, tipo, nível, timestamp de referência
3 — Params cdylib → Backend Todos os parâmetros do plugin (key=value)
4 — Start cdylib → Backend Comando ReplicaStart
5 — Data cdylib → Backend Fluxo de registros do Bacula (atributos de arquivo + dados)
6 — End cdylib → Backend Sinal de fim de fluxo

No modo FIFO, as fases de controle ocorrem via canal interno, mas os dados são lidos diretamente de um named pipe, contornando o canal de dados para maximizar o throughput.

Fluxo de Dados — Modo FIFO

┌──────────┐      ┌──────────┐      ┌───────────────┐
│ Bacula   │─────▶│ Named    │─────▶│ BRC Backend   │
│ SD       │      │ Pipe     │      │ (volume       │
│ (writes  │      │ (FIFO)   │      │  block reader)│
│  volume) │      └──────────┘      └───────┬───────┘
└──────────┘                                │
                                            ▼
                                   ┌──────────────────┐
                                   │ Replica Target   │
                                   └──────────────────┘

5. Casos de Uso

5.1 Site de DR Aquecido

Cenário: Uma organização precisa manter uma cópia de DR aquecida de servidores de arquivos críticos.

Solução: Configure o PodHeitor BRC em modo mirror apontando para um sistema de arquivos de DR (montagem local ou NFS). Cada backup sincroniza a réplica automaticamente. Em caso de desastre, os arquivos ficam imediatamente acessíveis.

target_base=/mnt/dr_site/replicas
mode=mirror
delete_removed=yes
skip_unchanged=yes

5.2 Recuperação Instantânea de Arquivos Near-line

Cenário: Usuários solicitam frequentemente restaurações individuais de arquivos, e o processo tradicional de restauração do Bacula é demorado.

Solução: Use o BRC para manter uma réplica atualizada. Quando um usuário precisar de um arquivo, basta copiá-lo do caminho da réplica — sem necessidade de um job de restauração do Bacula.

target_base=/mnt/fast_recovery
mode=mirror
verify_after=yes

5.3 Atualização de Dados para Desenvolvimento/Teste

Cenário: As equipes de desenvolvimento precisam de cópias atualizadas regularmente dos dados de produção.

Solução: Aponte o BRC para um sistema de arquivos acessível pelo time de desenvolvimento. Após cada ciclo de backup, os ambientes de dev/teste terão dados atuais automaticamente.

target_base=/mnt/dev_data
mode=mirror
bandwidth_limit=50M
exclude_patterns=*.log,*.tmp,*.pid

5.4 Evidências de Conformidade e Auditoria

Cenário: Requisitos regulatórios exigem comprovação de conformidade com RPO/RTO.

Solução: Ative o relatório de conformidade do BRC. Cada job gera arquivos de evidência com timestamp nos formatos JSONL, JSON e Markdown.

target_base=/mnt/compliant_replica
rpo_report_dir=/var/lib/podheitor/compliance
sla_rpo_secs=14400
sla_rto_secs=3600

5.5 Replicação Multi-site

Cenário: Dados críticos precisam ser replicados tanto para um SSD local rápido quanto para um local de DR remoto.

Solução: Use o fan-out multi-site com limites de bandwidth por destino.

target_base=/mnt/primary_replica
targets=/mnt/fast_ssd;/mnt/remote_dr:bwlimit=10M

5.6 Replicação Criptografada para Dados Sensíveis

Cenário: Os arquivos replicados contêm dados sensíveis que exigem criptografia em repouso.

Solução: Ative a criptografia AES-256-GCM.

target_base=/mnt/secure_replica
encrypt_key=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

6. Instalação

6.1 Pré-requisitos

  • PodHeitor Backup Edition 11.x, 14.x ou 15.x instalado e em execução
  • Storage Daemon em uma distribuição Linux suportada
  • Sistema de arquivos de destino da réplica montado e com permissão de escrita
  • Para modo FIFO: Device Type = Fifo configurado no SD

6.2 Instalação via RPM (RHEL/Rocky/OEL 8-9)

# Install the package
sudo rpm -Uvh podheitor-replica-sd-2.0.0-1.el9.x86_64.rpm

# Verify installation
ls -la /opt/bacula/lib/bacula/plugins/podheitor-replica-sd.so
ls -la /opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend

# Create configuration
sudo cat > /opt/bacula/etc/podheitor-replica-sd.conf << 'EOF'
target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info
EOF

# Set permissions
sudo chown bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf
sudo chmod 640 /opt/bacula/etc/podheitor-replica-sd.conf

# Restart Storage Daemon
sudo systemctl restart bacula-sd

# Verify plugin is loaded
sudo journalctl -u bacula-sd -n 20 | grep -i podheitor

6.3 Instalação via DEB (Debian 11-12 / Ubuntu 22.04+)

# Install the package
sudo dpkg -i podheitor-replica-sd_2.0.0_amd64.deb

# Create configuration (same as RPM)
sudo cat > /opt/bacula/etc/podheitor-replica-sd.conf << 'EOF'
target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info
EOF

# Set permissions
sudo chown bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf
sudo chmod 640 /opt/bacula/etc/podheitor-replica-sd.conf

# Restart Storage Daemon
sudo systemctl restart bacula-sd

6.4 Verificação Pós-instalação

# Check the plugin loads
echo "status storage=MySD" | bconsole | grep -i plugin

# Run a test backup
echo "run job=TestBackup yes" | bconsole

# Verify replicated files
ls -la /mnt/replica_dest/

7. Referência de Configuração

7.1 Arquivo de Configuração

O plugin lê os parâmetros de /opt/bacula/etc/podheitor-replica-sd.conf e da diretiva Plugin= do Bacula no recurso Storage.

Formato do arquivo de configuração: um key=value por linha. Linhas iniciadas com # são comentários.

# PodHeitor BRC Configuration
# /opt/bacula/etc/podheitor-replica-sd.conf

target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
skip_unchanged=yes
bandwidth_limit=100M
log_level=info

7.2 Tabela Completa de Parâmetros — Replicação

Parâmetro Padrão Tipo Descrição
target_base (obrigatório) caminho Caminho de destino para os arquivos replicados
mode mirror enum Modo de replicação: mirror (cópia 1:1) ou retention (versionado)
delete_removed yes bool Remove arquivos órfãos no backup Full (apenas modo mirror)
skip_unchanged no bool Ignora arquivos cujo hash BLAKE3 corresponde à réplica existente
preserve_acl yes bool Preserva as Listas de Controle de Acesso POSIX
preserve_xattr yes bool Preserva atributos estendidos
preserve_sparse yes bool Preserva buracos de arquivos esparsos (seek-based)
bandwidth_limit 0 tamanho Limite de taxa de transferência. 0 = ilimitado. Suporta sufixos K/KB, M/MB, G/GB
exclude_patterns (vazio) csv Padrões glob separados por vírgula a excluir da replicação
log_level info enum Verbosidade do log: debug, info, warn, error
verify_after no bool Executa verificação de integridade BLAKE3 após a conclusão da replicação
delta_enabled no bool Habilita transferência delta em nível de bloco para arquivos grandes

7.3 Tabela Completa de Parâmetros — Modo FIFO

Parâmetro Padrão Tipo Descrição
fifo_path (vazio) caminho Caminho do named pipe para leitura direta de volume. Requer Device Type = Fifo no SD do Bacula
archive_device (alias) caminho Alias para fifo_path — lido automaticamente da configuração do SD
fifo_mode no bool Habilita o modo FIFO na porta de ativação do cdylib

7.4 Tabela Completa de Parâmetros — Retention

Parâmetro Padrão Tipo Descrição
retention_versions 0 int Número de versões históricas de arquivos a manter. Defina > 0 com mode=retention

7.5 Tabela Completa de Parâmetros — Multi-site

Parâmetro Padrão Tipo Descrição
targets (vazio) string Destinos adicionais separados por ponto-e-vírgula. Formato: /caminho ou /caminho:bwlimit=10M

7.6 Tabela Completa de Parâmetros — Snapshot

Parâmetro Padrão Tipo Descrição
snapshot_backend none enum Backend de snapshot pré-replicação: none, lvm, zfs, btrfs

7.7 Tabela Completa de Parâmetros — Consistência e Failover

Parâmetro Padrão Tipo Descrição
consistency_group (vazio) string Nome do grupo para replicação coordenada de múltiplos jobs
healthcheck_cmd (vazio) string Comando externo de verificação de saúde. Saída 0 = saudável
promote_cmd (vazio) string Comando para promover a réplica ao papel primário
demote_cmd (vazio) string Comando para rebaixar o papel primário

7.8 Tabela Completa de Parâmetros — Criptografia

Parâmetro Padrão Tipo Descrição
encrypt_key (vazio) hex Chave de criptografia AES-256-GCM como string hexadecimal de 64 caracteres

7.9 Tabela Completa de Parâmetros — Conformidade

Parâmetro Padrão Tipo Descrição
rpo_report_dir (vazio) caminho Diretório para relatórios de conformidade RPO/RTO. Vazio = /var/lib/podheitor/rpo
sla_rpo_secs 14400 int Limiar de RPO do SLA em segundos (padrão: 4 horas)
sla_rto_secs 3600 int Limiar de RTO do SLA em segundos (padrão: 1 hora)

7.10 Tabela Completa de Parâmetros — Dashboard e Filtro de Job

Parâmetro Padrão Tipo Descrição
dashboard_enabled no bool Gera status JSON do dashboard compatível com Bacularis
job_filter (vazio) string Prefixo do nome do job — o plugin ativa somente para jobs correspondentes (porta cdylib)

Valores Booleanos

Parâmetros booleanos aceitam os seguintes valores:

  • Verdadeiro: yes, true, 1, on
  • Falso: no, false, 0, off (ou qualquer outro valor)

8. Dimensionamento e Requisitos

8.1 Host do Storage Daemon

Recurso Mínimo Recomendado Notas
CPU 4 vCPU 8 vCPU Mais núcleos para cargas de trabalho com criptografia/BLAKE3
RAM 8 GB 16 GB Adicional para operações com arquivos grandes e delta
Disco de SO/log 40 GB 60 GB Inclui espaço de log e relatórios de conformidade
Disco da réplica Volume de origem + 20% Volume de origem + 50% No modo retention: multiplique por retention_versions
Rede 1 Gbps 10 Gbps Crítico para grandes volumes de dados com multi-site

8.2 Fórmula de Dimensionamento de Disco

Disco da réplica (mirror)    = Tamanho dos dados de origem × 1,2
Disco da réplica (retention) = Tamanho dos dados de origem × retention_versions × 1,1
Relatórios de conformidade   = ~50 KB por job por execução

8.3 Dimensionamento de Rede

Cenário Taxa de Variação Diária Rede Recomendada
Pequeno (< 100 GB de origem) 5-10% 1 Gbps
Médio (100 GB – 1 TB) 5-10% 1 Gbps
Grande (1 TB – 10 TB) 2-5% 10 Gbps
Muito Grande (> 10 TB) 1-2% 10 Gbps + throttling

9. Matriz de Compatibilidade

9.1 Versões do Bacula

Versão do Bacula CE Plugin API Status
15.0.x v13 Validado
14.0.x v13 Suportado
11.0.x v13 Suportado

9.2 Sistemas Operacionais

Distribuição Versões Formato do Pacote Status
RHEL 8, 9 RPM Validado
Rocky Linux 8, 9 RPM Validado
Oracle Linux 8, 9 RPM Validado
Debian 11, 12 DEB Suportado
Ubuntu 22.04, 24.04 DEB Suportado

9.3 Sistemas de Arquivos

Sistema de Arquivos ACL xattr Esparso Snapshot Status
ext4 Sim Sim Sim Não Validado
XFS Sim Sim Sim Não Suportado
Btrfs Sim Sim Sim Sim (nativo) Suportado
ZFS Sim Sim Sim Sim (nativo) Suportado
NFS v4 Parcial Parcial Não Não Suportado (destino remoto)

10. Opções de Backup e Restauração

10.1 Suporte a Níveis de Backup

Nível Comportamento Efeito de delete_removed
Full (F) Replica todos os arquivos do conjunto de backup Remove arquivos órfãos da réplica
Incremental (I) Replica somente os arquivos alterados desde o último backup Sem remoção de órfãos
Differential (D) Replica os arquivos alterados desde o último Full Sem remoção de órfãos

10.2 Modos de Replicação

Modo delete_removed Tratamento de Arquivos Ideal Para
mirror yes Cópia 1:1, órfãos removidos no Full DR, recuperação instantânea
mirror no Cópia 1:1, órfãos preservados Replicação conservadora
retention N/A Cópias versionadas (até retention_versions) Recuperação a ponto no tempo

10.3 Procedimentos de Recuperação

Acesso Direto a Arquivos (Sem Necessidade de Restauração)

# Files are already available at the replica target
cp /mnt/replica_dest/path/to/needed/file /restore/location/

# Or create a symlink for applications
ln -s /mnt/replica_dest/app/data /app/data

Restauração Tradicional do Bacula (Ainda Suportada)

O plugin não interfere nas operações normais de restauração do Bacula. Todos os procedimentos padrão de restauração continuam funcionando de forma independente.

*restore
Select job=TestBackup
...

10.4 Procedimento de Recuperação Instantânea

  1. Verifique a integridade da réplica: confira o manifesto e execute a verificação se configurado
  2. Monte/exponha o caminho da réplica para a aplicação
  3. Inicie os serviços apontando para o local da réplica
  4. (Opcional) Execute a restauração do Bacula em segundo plano para reconstruir o armazenamento primário

11. Exemplos de Configuração

11.1 Replicação Mirror Básica

Cenário: Réplica 1:1 simples para recuperação instantânea de arquivos.

Arquivo de configuração (/opt/bacula/etc/podheitor-replica-sd.conf):

target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info

Recurso Device do Bacula SD:

Device {
  Name = FileStorage
  Media Type = File1
  Archive Device = /mnt/bacula/volumes
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
}

11.2 Modo FIFO (Replicação sem Volume)

Cenário: Eliminar o I/O de volume local — os dados fluem diretamente para a réplica.

Arquivo de configuração:

target_base=/mnt/replica_dest
mode=mirror
fifo_path=/tmp/podheitor_fifo
job_filter=Replicate-
log_level=info

Recurso Device do Bacula SD:

Device {
  Name = ReplicaFIFO
  Media Type = FIFO
  Device Type = Fifo
  Archive Device = /tmp/podheitor_fifo
  LabelMedia = yes
  Random Access = no
  AutomaticMount = no
  RemovableMedia = no
  AlwaysOpen = no
  MaximumOpenWait = 60
}

Recurso FileSet do Bacula:

FileSet {
  Name = "ReplicaFileSet"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
    }
    File = /etc
    File = /home
    File = /var/www
  }
  Exclude {
    File = /etc/shadow
    File = *.tmp
  }
}

Recurso Job do Bacula:

Job {
  Name = "Replicate-DailyFiles"
  Type = Backup
  Client = server-fd
  FileSet = "ReplicaFileSet"
  Storage = SD-Replica
  Pool = ReplicaPool
  Schedule = "DailySchedule"
  Messages = Standard
  Priority = 10
}

11.3 Modo Retention com Versionamento

Cenário: Manter 5 versões de cada arquivo para recuperação a ponto no tempo.

Arquivo de configuração:

target_base=/mnt/versioned_replica
mode=retention
retention_versions=5
skip_unchanged=yes
log_level=info

11.4 Fan-out Multi-site com Limites de Bandwidth

Cenário: Replicar para SSD local rápido e DR remoto com throttling.

Arquivo de configuração:

target_base=/mnt/fast_local
targets=/mnt/fast_local;/mnt/remote_dr:bwlimit=10M
mode=mirror
skip_unchanged=yes
bandwidth_limit=100M

11.5 Enterprise: Criptografia + Conformidade + Failover

Cenário: Ambiente regulado que exige réplicas criptografadas, evidências de conformidade e failover automatizado.

Arquivo de configuração:

target_base=/mnt/secure_replica
mode=mirror
delete_removed=yes
skip_unchanged=yes

# Encryption (AES-256-GCM)
encrypt_key=a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

# Compliance reporting
rpo_report_dir=/var/lib/podheitor/compliance
sla_rpo_secs=14400
sla_rto_secs=3600

# Consistency group
consistency_group=critical-data

# Failover automation
healthcheck_cmd=/opt/scripts/check_primary.sh
promote_cmd=/opt/scripts/promote_replica.sh
demote_cmd=/opt/scripts/demote_primary.sh

# Snapshot before replication
snapshot_backend=lvm

# Post-replication integrity check
verify_after=yes

log_level=info

11.6 Configuração de Alto Desempenho

Cenário: Grande volume de dados (> 1 TB) com sobrecarga mínima.

Arquivo de configuração:

target_base=/mnt/fast_nvme/replica
mode=mirror
fifo_path=/tmp/podheitor_fifo
skip_unchanged=yes
delta_enabled=yes
bandwidth_limit=0
preserve_sparse=yes
log_level=warn

11.7 Exemplos de FileSet Orientados à Restauração

Servidor de arquivos geral:

FileSet {
  Name = "FileServer-Full"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
      OneFS = no
    }
    File = /srv/shares
    File = /home
  }
  Exclude {
    File = *.tmp
    File = *.bak
    File = /home/*/.cache
    File = /home/*/Downloads
  }
}

Arquivos de configuração de banco de dados (não os dados):

FileSet {
  Name = "DB-ConfigFiles"
  Include {
    Options {
      Signature = SHA256
      Compression = GZIP
    }
    File = /etc/postgresql
    File = /etc/mysql
    File = /var/lib/pgsql/data/postgresql.conf
    File = /var/lib/pgsql/data/pg_hba.conf
  }
}

Aplicação web:

FileSet {
  Name = "WebApp-Assets"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
    }
    File = /var/www
    File = /etc/nginx
    File = /etc/apache2
  }
  Exclude {
    File = /var/www/*/node_modules
    File = /var/www/*/.git
    File = *.log
  }
}

12. Procedimentos Operacionais

12.1 Iniciando um Job de Replicação

# Via bconsole
echo "run job=Replicate-DailyFiles level=Full yes" | bconsole

# Check status
echo "status dir" | bconsole

12.2 Monitorando a Replicação

# Check backend logs
tail -f /opt/bacula/working/podheitor-replica-sd-backend.log

# Check replicated files
find /mnt/replica_dest -newer /tmp/last_check -type f | wc -l

# Check compliance reports
ls -la /var/lib/podheitor/compliance/
cat /var/lib/podheitor/compliance/*latest*.md

12.3 Verificando a Integridade da Réplica

# If verify_after=yes (automatic)
grep "VERIFY" /opt/bacula/working/podheitor-replica-sd-backend.log

# Manual verification
diff -r /original/path /mnt/replica_dest/original/path

12.4 Procedimento de Failover

  1. Automático (se healthcheck_cmd estiver configurado): o plugin executa a verificação de saúde após cada job. Se o primário estiver com problemas, o promote_cmd é executado automaticamente.
  1. Manual:
# Verify replica is current
stat /mnt/replica_dest/critical/data

# Promote replica
/opt/scripts/promote_replica.sh

# Update application configuration to point to replica
systemctl restart application

13. Segurança

13.1 Criptografia em Repouso

O PodHeitor BRC suporta criptografia AES-256-GCM para todos os arquivos replicados:

  • Algoritmo: AES-256-GCM (criptografia autenticada)
  • Formato da chave: string hexadecimal de 64 caracteres (chave de 256 bits)
  • Implementação: AES-256-GCM com nonce único por arquivo
  • Escopo: somente o conteúdo do arquivo (nomes de arquivos e estrutura de diretórios permanecem visíveis)

Gerenciamento de chaves:

  • Armazene a chave no arquivo de configuração com permissões restritas (chmod 640)
  • Arquivo de configuração de propriedade de bacula:bacula
  • Nunca confirme chaves no controle de versão
  • Faça a rotação das chaves atualizando a configuração e executando um novo backup Full

13.2 Permissões de Arquivos

# Plugin binaries
-rwxr-xr-x root:bacula /opt/bacula/lib/bacula/plugins/podheitor-replica-sd.so
-rwxr-xr-x root:bacula /opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend

# Configuration
-rw-r----- bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf

# Replica target
drwxr-xr-x bacula:bacula /mnt/replica_dest

13.3 Considerações de Rede

  • O plugin opera inteiramente no host do Storage Daemon — sem comunicação de rede além do que o Bacula já utiliza
  • Para destinos de réplica montados via NFS, garanta NFS v4 com Kerberos ou restrinja o acesso por IP
  • Os relatórios de conformidade contêm metadados de jobs — restrinja o acesso ao diretório de relatórios

14. Conformidade e Relatórios

14.1 Relatórios de RPO/RTO

Quando rpo_report_dir está configurado, o plugin gera três formatos de relatório por job:

Formato Arquivo Finalidade
JSONL {job_name}_rpo.jsonl Log de eventos apenas para acréscimo para processamento automatizado
JSON {job_name}_rpo_latest.json Snapshot do estado atual para dashboards
Markdown {job_name}_rpo_report.md Relatório legível por humanos para auditores

14.2 Conteúdo dos Relatórios

Cada relatório inclui:

  • Nome, ID e horário de conclusão do job
  • Nível do backup (Full/Incremental/Differential)
  • Contagem de arquivos e total de bytes replicados
  • Medição de RPO: tempo desde a última replicação bem-sucedida
  • Estimativa de RTO: tempo de recuperação a partir da réplica
  • Status de conformidade com o SLA (aprovado/reprovado em relação aos limiares configurados)
  • Status de criptografia

14.3 Limiares de SLA

Parâmetro Padrão Significado
sla_rpo_secs 14400 (4h) Tempo máximo aceitável entre replicações
sla_rto_secs 3600 (1h) Tempo máximo aceitável de recuperação

Os relatórios indicam claramente APROVADO ou REPROVADO para cada SLA, tornando as revisões de auditoria diretas.

15. Considerações de Desempenho

15.1 Recursos de Otimização

Recurso Impacto Quando Usar
skip_unchanged Reduz gravações em 50-90% em cargas de trabalho incrementais Sempre recomendado para grandes volumes de dados
delta_enabled Reduz a transferência de arquivos grandes com pequenas alterações Arquivos grandes (bancos de dados, VMs)
bandwidth_limit Evita a saturação do armazenamento compartilhado Infraestrutura compartilhada
Modo FIFO Elimina o I/O duplo (gravação de volume + gravação da réplica) Jobs de replicação dedicados
preserve_sparse Mantém a eficiência de arquivos esparsos Discos de VM, bancos de dados

15.2 Dicas de Desempenho

  1. Use o modo FIFO para jobs de replicação dedicados — elimina a sobrecarga de I/O de volume
  2. Habilite skip_unchanged — o hashing BLAKE3 é rápido (~5 GB/s) e evita gravações desnecessárias
  3. Use compressão LZ4 no FileSet — mais rápida que GZIP com boa taxa de compressão
  4. Dimensione o disco da réplica para o padrão de I/O — SSDs recomendados para cargas de acesso aleatório
  5. Defina um bandwidth_limit adequado ao compartilhar armazenamento com cargas de trabalho de produção
  6. Use log_level=warn em produção para reduzir o I/O de log

16. Resolução de Problemas

16.1 Problemas Comuns

Sintoma Causa Solução
Plugin não carrega .so ausente no diretório de plugins Verifique Plugin Directory na configuração do SD
Backend não encontrado Binário não está no caminho esperado Verifique /opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend
Permissão negada Propriedade incorreta na configuração ou no destino chown bacula:bacula na configuração e no destino
Timeout do FIFO Named pipe não criado Garanta Device Type = Fifo e que Archive Device corresponda a fifo_path
ACLs não preservadas Sistema de arquivos montado sem ACL Remonte com mount -o acl ou use acl em /etc/fstab
Alto uso de CPU Hashing BLAKE3 em muitos arquivos Comportamento esperado — desabilite skip_unchanged se inaceitável
Relatório RPO ausente Diretório sem permissão de escrita Verifique as permissões de rpo_report_dir

16.2 Locais dos Logs

Log Caminho Conteúdo
Log do backend /opt/bacula/working/podheitor-replica-sd-backend.log Operações do plugin
Log do SD /opt/bacula/log/bacula-sd.log Mensagens do shim (prefixadas com podheitor:)
Conformidade {rpo_report_dir}/ Relatórios RPO/RTO

16.3 Modo Debug

Habilitar log detalhado:

log_level=debug

Verificar a saída do backend:

tail -f /opt/bacula/working/podheitor-replica-sd-backend.log

17. Evidências Validadas

17.1 Ambiente de Laboratório

Componente Versão Host
Bacula CE 15.0.3 192.168.15.105
SO Oracle Linux 9 192.168.15.105
Plugin PodHeitor BRC 2.0.0 192.168.15.105

17.2 Resultados dos Testes

Teste ID do Job Status Detalhes
Reinstalação de RPM + reinício do serviço — OK Instalação limpa, serviço ativo
Backup Full via FIFO 786 T (Terminado com Sucesso) 3 arquivos, 648 bytes replicados
Geração de relatório de conformidade 786 OK Relatórios JSONL/JSON/MD gerados

17.3 Comandos de Verificação

# Verify package installation
rpm -qa | grep podheitor

# Verify service is running
systemctl status bacula-sd

# Check last job status
echo "list jobs last" | bconsole

# Verify replica files
ls -la /mnt/replica_dest/

18. Roadmap

Recurso Status Meta
Replicação mirror GA v2.0.0
Modo retention GA v2.0.0
Modo FIFO GA v2.0.0
ACL/xattr/esparso GA v2.0.0
BLAKE3 skip-unchanged GA v2.0.0
Criptografia AES-256-GCM GA v2.0.0
Grupos de consistência GA v2.0.0
Automação de failover GA v2.0.0
Conformidade RPO/RTO GA v2.0.0
Pacotes RPM/DEB GA v2.0.0
Dashboard Bacularis Planejado v0.5.0
Federação multi-SD Planejado v0.6.0
Destinos em nuvem (S3/Azure/GCS) Planejado v0.7.0
Conversão ciente de VM Planejado v0.8.0
Suporte ao SD Windows Backlog —

19. Informações Comerciais

Sobre

O PodHeitor BRC é desenvolvido e mantido por Heitor Faria, com profunda expertise no ecossistema Bacula, backup empresarial e soluções de recuperação de desastres.

Licenciamento

O PodHeitor BRC é distribuído sob licença comercial proprietária — por Storage Daemon. Cada contrato inclui licença de produção, acesso a atualizações da versão contratada e suporte técnico por e-mail.

Para organizações que migram de plataformas comerciais (Veeam, Commvault, NetBackup), oferecemos uma proposta comparativa com meta de pelo menos 50% de economia.

Serviços

Serviço Descrição
Licença enterprise Licença de implantação em produção com atualizações
Suporte prioritário Acesso direto ao desenvolvedor para resolução de problemas
Implementação Instalação, configuração e ajuste fino para o seu ambiente
Consultoria em DR Projetos personalizados de recuperação de desastres e arquitetura

Pronto para avaliar?

Entre em contato para iniciar uma prova de conceito em seu ambiente:

Copyright 2026 Heitor Faria — Todos os Direitos Reservados. PodHeitor BRC Plugin para PodHeitor Backup — Versão 2.0.0

Disponível em: pt-brPortuguêsenEnglish (Inglês)esEspañol (Espanhol)

Deixe um comentário