Whitepaper técnico — PodHeitor MySQL / MariaDB para Bacula - PodHeitor

Produto: PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula Versão: v0.4.1 Data de lançamento: 2026-04-24 Autor: Heitor Faria, Fundador da PodHeitor / OpenTechs Classificação: Confidencial — uso com clientes Copyright © 2026 Heitor Faria — todos os direitos reservados.

Contatos principais (vendas, técnico e comercial):

E-mail: heitor@opentechs.lat
Telefone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Traga-nos seu contrato vigente ou cotação de renovação da Bacula Enterprise, Veeam, Commvault ou NetBackup — igualamos a lista de funcionalidades e garantimos no mínimo 50% de desconto, com diversas capacidades adicionais inclusas.

Sumário

Página de Título
Resumo Executivo
Declaração do Problema
Visão Geral do Produto
Casos de Uso
Arquitetura
Procedimento de Instalação
Configuração e Dimensionamento (Mínimo Recomendado)
Matriz de Compatibilidade
Opções de Backup — Tabela de Referência Completa
Opções de Restauração — Tabela de Referência Completa
Exemplos de Configuração de FileSet
Exemplos de Configuração de Restauração
Relatórios de Desempenho
Evidências Validadas em Produção
Modelo de Segurança
Manual Operacional
Solução de Problemas — Top-10
Política de Atualização e Cadência de Releases
Preços e Condições Comerciais
Licenciamento
Conclusão e Chamada para Ação
Página de Contato
Apêndice A — Glossário
Apêndice B — Referências

1. Página de Título

PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula

Versão: v0.4.1 Data de lançamento: 2026-04-24 Autor: Heitor Faria — Fundador, PodHeitor / OpenTechs Licença: PodHeitor-Proprietary — Copyright © Heitor Faria. Todos os direitos reservados. Termos de licenciamento comercial disponíveis sob solicitação

Classificação: Confidencial — uso com clientes

Contatos:

E-mail: heitor@opentechs.lat
Telefone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Este documento descreve as capacidades, a arquitetura, a instalação, a configuração, as práticas operacionais, as condições comerciais e o licenciamento do PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula, versão v0.4.1. É preparado para um público misto composto de tomadores de decisão C-level, administradores de banco de dados, administradores de sistemas e gestores de compras. Todo o conteúdo é de propriedade de Heitor Faria e é fornecido sob os termos de distribuição confidencial para clientes.

2. Resumo Executivo

Empresas que operam MySQL e MariaDB em escala de produção enfrentam uma contradição persistente e cara. Por um lado, esses bancos de dados são a espinha dorsal operacional de sistemas OLTP, ERP, ECM, planos de controle SaaS, livros-razão financeiros e cargas de trabalho reguladas. Por outro lado, o mercado de ferramentas de backup em torno deles se consolidou em um pequeno número de titulares — Bacula Enterprise, Veeam, Commvault e Veritas NetBackup — cujos modelos de licenciamento, escolhas arquiteturais e curvas de preço estão cada vez mais desalinhados com as realidades dos ambientes modernos de MySQL/MariaDB: clusters Galera escalados horizontalmente, cargas de trabalho Percona TDE, provisionamento baseado em MySQL 8 Clone, MariaDB 11.4 LTS, proteção contínua de dados estilo CDP via binlog, e réplicas de recuperação de desastres geo-distribuídas.

O PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 é um plugin para o File Daemon do Bacula construído especificamente para essa finalidade — um binário único, implementado em Rust — que entrega 48 das 48 capacidades documentadas de backup MySQL/MariaDB corporativo em uma única distribuição. É licenciado sob PodHeitor-Proprietary em forma de código-fonte, com relicenciamento comercial disponível para clientes que precisarem. É projetado para se integrar a implantações existentes do Bacula Community (15.0.3 como alvo principal) ou Bacula Enterprise sem exigir uma migração completa do Director, do Storage Daemon ou da infraestrutura de catálogo.

O PodHeitor v0.4.1 resolve quatro problemas concretos de uma vez:

Paridade de funcionalidades. Ele corresponde à lista documentada de funcionalidades do plugin MySQL corporativo linha a linha, incluindo dumps lógicos, backup físico Percona XtraBackup e mariabackup completo/incremental/diferencial, coordenação de donor-desync do Galera, provisionamento de réplica agentless via MySQL 8 CLONE INSTANCE, restauração de tabela única por tablespace transportável, backup físico com suporte ao keyring Percona TDE, CDP baseado em binlog e — novo na linha 0.x — provisionamento completo de réplica de recuperação de desastres via mode=replicate, que inicializa uma réplica MySQL ativa e em sincronização diretamente a partir de um job de restauração do Bacula.

Arquitetura de binário único. O plugin é distribuído como um único binário Rust (podheitor-mysql) invocado por meio de um shim metaplugin leve do Bacula. Não há dependência de runtime Perl, nenhuma cadeia de ferramentas de segunda linguagem, nenhum grafo de dependências de objetos compartilhados além do libc ou musl. Isso reduz drasticamente a superfície de ataque, a pegada na cadeia de suprimentos e a variância operacional em comparação com plugins corporativos baseados em Perl.

Economia comercial. O PodHeitor está deliberadamente posicionado abaixo dos pontos de preço da Bacula Enterprise, Veeam, Commvault e NetBackup. Nossa oferta comercial permanente é simples e incondicional: traga-nos seu contrato vigente ou cotação de renovação de qualquer um desses quatro fornecedores, e igualamos a lista de funcionalidades e garantimos no mínimo 50% de desconto, com diversas capacidades adicionais inclusas.

Source-available com licença comercial. O código-fonte é fornecido sob a licença comercial PodHeitor para auditoria, inspeção e (com licença de build) compilação interna pelo cliente — satisfazendo os processos de procurement e revisão de segurança mais rigorosos.

Traga-nos seu contrato vigente ou cotação de renovação da Bacula Enterprise, Veeam, Commvault ou NetBackup — igualamos a lista de funcionalidades e garantimos no mínimo 50% de desconto, com diversas capacidades adicionais inclusas.

Para iniciar a conversa: envie um e-mail para heitor@opentechs.lat, ligue para +1 (786) 726-1749 ou envie mensagem para +55 (61) 98268-4220 no WhatsApp.

3. Declaração do Problema

3.1 O desafio moderno de backup MySQL/MariaDB

MySQL e MariaDB se tornaram silenciosamente o banco de dados transacional padrão para a maioria das cargas de trabalho de produção fora dos ecossistemas de mainframe e hyperscaler gerenciados. O perfil operacional dessas cargas de trabalho mudou significativamente nos últimos cinco anos:

Os conjuntos de dados rotineiramente excedem 1 TB por instância, com muitos ultrapassando

10 TB.

Clusters Galera de 3 a 7 nós são comuns em topologias de alta disponibilidade.

Percona Server com InnoDB criptografado por TDE é padrão para setores regulados

(financeiro, saúde, setor público).

MariaDB 10.6 e 11.4 LTS dominam o segmento de ERP e ECM,

especialmente na Europa e na América Latina.

As estratégias de DR dependem cada vez mais de réplicas geo-distribuídas que

precisam ser inicializadas, reconstruídas e rebaseadas sob demanda — não apenas “restauradas da fita”.

Frameworks regulatórios (PCI-DSS, LGPD, GDPR, HIPAA, SOX) exigem

RPOs na faixa de minutos de um único dígito, que somente o CDP baseado em binlog consegue entregar.

Diante disso, a base instalada de ferramentas de backup MySQL não está acompanhando o ritmo.

3.2 Por que as soluções atuais ficam aquém

Plugin MySQL Bacula Enterprise 18.2.3. O plugin MySQL corporativo titular na família Bacula é implementado em Perl. O Perl é uma linguagem capaz, mas em 2026 impõe custos reais: um grande runtime de interpretador em cada host do File Daemon, árvores de dependências CPAN que complicam implantações em redes isoladas, execução mais lenta para tarefas intensivas de computação como compressão e tratamento de streams, e uma pool cada vez menor de engenheiros proficientes o suficiente para depurá-lo em produção. O plugin MySQL em Perl também está atrasado em funcionalidades mais recentes — MySQL 8 Clone, restauração de tabela única por tablespace transportável e provisionamento de réplica de DR estão ausentes ou entregues por módulos adicionais.

Veeam Backup & Replication. O suporte a MySQL do Veeam é implementado como um agente, não como um mecanismo de primeira classe. Isso funciona adequadamente para instâncias pequenas, mas não se integra de forma limpa com Galera, não oferece MySQL 8 Clone agentless e empurra os clientes para a curva de licenciamento voltada à virtualização do Veeam, que é cara na escala de bancos de dados.

Commvault. O Commvault oferece ampla cobertura de plataformas a um custo total de propriedade elevado. O licenciamento é baseado em capacidade e escala acentuadamente; o iDataAgent MySQL é competente, mas não diferenciado, e o TCO para um ambiente MySQL de médio porte é rotineiramente de 3 a 5× o que o PodHeitor entrega para cobertura equivalente.

Veritas NetBackup. A cobertura MySQL do NetBackup é pesada e fortemente acoplada à arquitetura de media-server e catálogo do NetBackup. É uma escolha viável apenas para clientes já padronizados no NetBackup em toda a empresa; para ambientes que priorizam MySQL ou Bacula, os custos de licenciamento e sobrecarga operacional são desproporcionais.

3.3 A lacuna que o PodHeitor fecha

O PodHeitor v0.4.1 fecha essa lacuna entregando capacidades de backup, restauração e replicação MySQL e MariaDB de nível corporativo como um plugin de primeira classe para o File Daemon do Bacula, sem Perl, sem agentes, sem licenciamento baseado em capacidade e sem dependência de fornecedor. Ele mira exatamente a lista de funcionalidades pelas quais os quatro titulares cobram — e as iguala — permanecendo dentro de um único binário Rust autocontido que um DBA pode auditar, um administrador de sistemas pode implantar e um CISO pode aprovar.

4. Visão Geral do Produto

4.1 Em resumo

Nome: PodHeitor MySQL/MariaDB Backup and Replication Plugin for

Bacula

Versão: v0.4.1
Data de lançamento: 2026-04-24
Linguagem: Rust (toolchain estável), empacotado como um único

binário static-pie para uso em redes isoladas e como builds glibc para repositórios RPM e DEB

Licença: PodHeitor-Proprietary — Copyright © Heitor Faria. Todos os direitos reservados
Superfície de integração: API metaplugin do File Daemon do Bacula
Cobertura de backend: MySQL 5.7 / 8.0 / 8.4 LTS; Percona Server 8.0;

MariaDB 10.5 / 10.6 LTS / 10.11 LTS / 11.4 LTS

Motores de backup: mysqldump / mysqlpump / mariadb-dump;

Percona XtraBackup 2.4 / 8.0 / 8.4; mariabackup; MySQL 8 CLONE INSTANCE; streamer de binlog (CDP); provisionamento via replicate/DR

4.2 A afirmação de paridade 48/48

O PodHeitor v0.4.1 documenta e implementa 48 capacidades distintas de backup MySQL/MariaDB corporativo, correspondendo à lista de funcionalidades publicada do plugin MySQL Bacula Enterprise 18.2.3 linha a linha. As 48 capacidades abrangem sete grupos funcionais:

Backup lógico (dump) — 6 capacidades
Backup físico (xtrabackup / mariabackup) — 10 capacidades
Consciência de cluster e réplica — 7 capacidades
Provisionamento agentless (CLONE INSTANCE) — 4 capacidades
Restauração de tabela única transportável — 3 capacidades
TDE, criptografia e gerenciamento de keyring — 5 capacidades
CDP, streaming de binlog e provisionamento via replicate/DR — 13

capacidades

Cada capacidade mapeia para uma ou mais opções do plugin documentadas nas tabelas de referência mais adiante neste whitepaper. O mapeamento é mantido no documento fonte da verdade docs/ENTERPRISE_PARITY.md no repositório do produto e está vinculado à versão v0.4.1.

4.3 Arquitetura de binário único

O plugin é construído e distribuído como um único binário Rust. Não tem dependência de runtime Perl, Python, Ruby ou Go. Em plataformas glibc, vincula-se apenas ao libc e ao libssl do sistema; no build musl static-pie para redes isoladas, é totalmente autocontido. O shim metaplugin do Bacula (mysql-fd.so) é um carregador C mínimo que encaminha frames PTCOMM de e para o binário Rust — não contém lógica de negócio.

Essa arquitetura importa por quatro razões:

Cadeia de suprimentos. A superfície de dependências é reduzida ao grafo de crates Rust, auditado com cargo audit e cargo deny em cada release.

Implantação. Instalações em redes isoladas se resumem a copiar um binário

e um arquivo de configuração.

Observabilidade. Um binário único significa um único prefixo de log, uma única

fonte de métricas, um único alvo de depuração.

Postura de segurança. Nenhum interpretador em disco, nenhum runtime de

linguagem auxiliar, nenhum arquivo de script com permissão de leitura global.

4.4 Vantagem source-available + comercial

O plugin é single-licensed sob PodHeitor-Proprietary (Copyright © Heitor Faria). O código-fonte é fornecido a licenciados sob essa mesma licença comercial, oferecendo aos clientes quatro benefícios concretos sem as obrigações de uma licença copyleft:

O código-fonte é auditável antes da compra.
O cliente pode recompilar o binário internamente, se exigido pelo

setor de compras.

Correções de bugs podem ser propostas upstream ou aplicadas localmente.
Não há situação de dependência de fornecedor — caso a PodHeitor deixasse de

existir, o cliente retém um produto funcional e compilável.

Para implantadores que precisam de termos OEM, multi-tenant SaaS, ou per-organização com taxa fixa, o licenciamento comercial está disponível em termos padrão PodHeitor.

5. Casos de Uso

5.1 MySQL 8 OLTP de missão crítica no Oracle Linux 9

Uma processadora de pagamentos executa MySQL 8.4 LTS no Oracle Linux 9, com conjuntos de dados na faixa de 2 a 4 TB e uma meta de RPO de 5 minutos. O PodHeitor é implantado no File Daemon co-localizado com o primário MySQL. Um backup completo semanal via mode=xtrabackup captura a instância no nível físico; os incrementais diários percorrem a cadeia de LSN; o CDP via binlog transmite cada transação confirmada para um pool FIFO do Bacula em cadência de 1 minuto. A recuperação valida um RPO efetivo consistente de 3 a 4 minutos com restauração em poucos minutos para um host de teste.

5.2 MariaDB 11.4 para cargas de trabalho ERP / ECM

Um fornecedor de ERP de médio porte executa MariaDB 11.4 LTS em 40 tenants de clientes, cada um em um schema dedicado. A opção parallel_dbs do PodHeitor distribui dumps lógicos por schema, com compress=zstd no nível 6, produzindo artefatos de restauração isolados por tenant dentro de um único Job do Bacula. A restauração no nível do tenant é um único comando bconsole referenciando o schema relevante, sem restaurar toda a instância.

5.3 Cluster Galera de 3 nós em HA

Uma operadora de telecomunicações executa um cluster Galera de 3 nós para dados de assinantes. A opção galera_donor_desync=true do PodHeitor coordena com o Galera para colocar o nó de backup em estado donor-desync durante um backup físico, impedindo que o controle de fluxo paralise o cluster ativo. require_replica=true garante que o backup só seja executado em um nó não primário.

5.4 Provisionamento de réplica de DR (`mode=replicate`)

Uma fintech requer réplicas de DR aquecidas em uma região secundária, reconstruídas semanalmente a partir do backup para garantir a atualidade. A opção mode=replicate do PodHeitor realiza uma restauração que termina com uma réplica MySQL já configurada e em execução: as threads de IO e SQL são iniciadas, CHANGE REPLICATION SOURCE TO é aplicado a partir dos metadados capturados, e o posicionamento GTID coloca a réplica no ponto correto no stream de binlog. Um INSERT ao vivo executado no primário após a restauração foi observado se propagando para a réplica de DR em segundos — validado em nosso laboratório como JobId 3592 em 2026-04-24.

5.5 CDP (Proteção Contínua de Dados) para cargas de trabalho financeiras

Uma corretora regulada requer RPO no nível de transação. O serviço auxiliar de binlog do PodHeitor transmite logs binários continuamente para um pool FIFO dedicado do Bacula, com binlog_interval_sec=60 e binlog_mode=stream. A restauração combina o último backup completo, a cadeia de incrementais e a cauda do binlog para recuperação point-in-time em qualquer transação confirmada.

5.6 SaaS multi-tenant com agendamento por banco de dados

Um plano de controle SaaS separa os tenants por banco de dados. As opções database e exclude_dbs do PodHeitor permitem Jobs do Bacula por tenant com retenção, agendamento e pool de armazenamento independentes — tudo a partir do mesmo binário do plugin. A restauração com escopo de cliente, a exclusão com escopo de cliente e o bloqueio legal com escopo de cliente derivam dos primitivos padrão do Bacula.

5.7 InnoDB criptografado por TDE no Percona

Um provedor de saúde executa Percona Server 8.0 com InnoDB criptografado por TDE. A opção keyring_path do PodHeitor captura o arquivo de keyring junto com o stream de backup físico, de modo que a restauração produz uma instância criptograficamente consistente. O keyring é transmitido pelo mesmo stream do Bacula e é coberto pela mesma política de retenção do catálogo que o próprio banco de dados.

5.8 Restauração rápida de tabela única via tablespaces transportáveis

A tabela orders de uma plataforma de varejo é truncada acidentalmente. A opção restore_table=orders do PodHeitor, combinada com o fluxo de trabalho de tablespace transportável, restaura apenas essa tabela — não a instância inteira de 3 TB. Validado em laboratório como JobId 3470 em 2026-04-24 com uma restauração limpa de 3 de 3 linhas.

6. Arquitetura

6.1 Componentes

Bacula Director — inalterado. Emite início de Job, agendamento,

retenção e atualizações de catálogo.

Bacula File Daemon (FD) — inalterado. Hospeda o plugin PodHeitor

por meio da interface metaplugin padrão.

Shim metaplugin (mysql-fd.so) — carregador C mínimo. Encaminha

frames PTCOMM entre o FD e o backend Rust.

Backend Rust PodHeitor (podheitor-mysql) — binário Rust único.

Implementa toda a lógica de backup, restauração, replicação, CDP e verificação.

Servidor MySQL / MariaDB — inalterado. Acessado via socket local

ou TCP, autenticado via extra_file.

Bacula Storage Daemon (SD) — inalterado. Recebe o stream de backup.

6.2 Fluxo de dados — backup

*Fluxo de backup do PodHeitor MySQL (diagrama de sequência)*

6.3 Fluxo de dados — replicate (provisionamento de DR)

*Fluxo de restauração com replicação para DR (diagrama de sequência)*

6.4 Cadeia de LSN incremental

*Cadeia incremental do PodHeitor MySQL — fluxo de LSN do xtrabackup*

6.5 Invariantes arquiteturais

O plugin nunca é executado dentro do processo do servidor MySQL. Toda a

sobrecarga está no host do FD.

PTCOMM é o único acoplamento entre o backend Rust e o FD.
Nenhuma credencial é passada na linha de comando ou em variáveis de ambiente;

toda a autenticação MySQL é feita via extra_file em disco com modo 0640.

O stream de backup é opaco para o FD; todo o enquadramento específico de MySQL

reside dentro do binário Rust.

7. Procedimento de Instalação

7.1 EL9 (Oracle Linux 9, RHEL 9, Rocky 9, AlmaLinux 9) — RPM

sudo rpm --import https://repo.opentechs.lat/RPM-GPG-KEY-podheitor
sudo dnf install -y https://repo.opentechs.lat/el9/podheitor-mysql-plugin-0.4.1-1.el9.x86_64.rpm

O pacote instala:

/opt/bacula/plugins/mysql-fd.so — shim metaplugin
/opt/bacula/bin/podheitor-mysql — backend Rust
/opt/bacula/etc/podheitor-mysql.conf.example — configuração modelo
/usr/lib/systemd/system/podheitor-mysql-binlog.service — unidade

do serviço auxiliar CDP (inativa por padrão)

7.2 EL8 — RPM (variante de build obrigatória)

O EL8 possui uma versão mais antiga do glibc. Use explicitamente a variante de build EL8:

sudo rpm --import https://repo.opentechs.lat/RPM-GPG-KEY-podheitor
sudo dnf install -y https://repo.opentechs.lat/el8/podheitor-mysql-plugin-0.4.1-1.el8.x86_64.rpm

Não instale o RPM EL9 no EL8 — o requisito de glibc não será satisfeito e o dnf recusará a transação.

7.3 Debian 12 — .deb com verificação .asc separada

curl -fsSLO https://repo.opentechs.lat/deb/podheitor-mysql-plugin_0.4.1-1_amd64.deb
curl -fsSLO https://repo.opentechs.lat/deb/podheitor-mysql-plugin_0.4.1-1_amd64.deb.asc
gpg --verify podheitor-mysql-plugin_0.4.1-1_amd64.deb.asc 
             podheitor-mysql-plugin_0.4.1-1_amd64.deb
sudo dpkg -i podheitor-mysql-plugin_0.4.1-1_amd64.deb

7.4 Ubuntu 22.04 / 24.04 — receita de compilação

Os builds Ubuntu seguem a receita Debian. Para 22.04 e 24.04 o .deb do Debian 12 é compatível em binário em nosso laboratório, mas o caminho oficialmente suportado é recompilar a partir do código-fonte:

git clone https://repo.opentechs.lat/podheitor-mysql-plugin.git
cd podheitor-mysql-plugin
cargo build --release
sudo make install PREFIX=/opt/bacula

7.5 Rede isolada — tarball musl static-pie

curl -fsSLO https://repo.opentechs.lat/tarball/podheitor-mysql-plugin-0.4.1-musl.tar.gz
curl -fsSLO https://repo.opentechs.lat/tarball/podheitor-mysql-plugin-0.4.1-musl.tar.gz.asc
gpg --verify podheitor-mysql-plugin-0.4.1-musl.tar.gz.asc 
             podheitor-mysql-plugin-0.4.1-musl.tar.gz
tar -xzf podheitor-mysql-plugin-0.4.1-musl.tar.gz -C /opt/bacula/

O build musl é totalmente static-pie e não possui dependência de runtime além da interface de syscall do kernel.

7.6 Verificação de assinatura

Todos os artefatos — RPM, DEB, tarball e SHA256SUMS — são assinados.

Chave GPG mestra: CDEFB0121FA1B478
Subchave de assinatura: 18A1FFECE956041D

gpg --keyserver keys.openpgp.org --recv-keys CDEFB0121FA1B478
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS

Os RPMs também carregam uma assinatura embutida verificável com rpm --checksig. Os DEBs são distribuídos com um .asc separado junto ao pacote.

7.7 Pós-instalação

Copie a configuração modelo:

   sudo cp /opt/bacula/etc/podheitor-mysql.conf.example 
           /opt/bacula/etc/podheitor-mysql.conf
   sudo chown root:bacula /opt/bacula/etc/podheitor-mysql.conf
   sudo chmod 640 /opt/bacula/etc/podheitor-mysql.conf

Crie o arquivo de credenciais MySQL referenciado por extra_file:

   [client]
   user=bacula_backup
   password=redacted
   socket=/var/lib/mysql/mysql.sock

   sudo chmod 640 /opt/bacula/etc/mysql-extra.cnf
   sudo chown root:bacula /opt/bacula/etc/mysql-extra.cnf

Adicione a diretiva Plugin= ao FileSet do Bacula (veja a seção 12

para exemplos completos).

Reinicie o File Daemon:

   sudo systemctl restart bacula-fd

Confirme que o plugin carregou:

   sudo journalctl -u bacula-fd --since "1 minute ago" | grep podheitor

8. Configuração e Dimensionamento (Mínimo Recomendado)

8.1 Host do File Daemon (onde o plugin é executado)

Componente	Mínimo	Recomendado	Regra de escalonamento
vCPU	2	4	+1 vCPU por 4 threads de dump paralelas
RAM	2 GB	4 GB	+1 GB por passo xtrabackup `--parallel=N`
Disco (staging)	2× maior BD	3× maior BD	Aplica-se ao staging de restauração física
Disco (binário + config)	100 MB	100 MB	Fixo; binário tem ~20 MB
Rede	1 Gbps	10 Gbps	Veja a seção 8.4

8.2 Storage Daemon — largura de banda de rede vs tamanho do BD

Maior BD individual	Uplink SD mínimo	Uplink SD recomendado
≤ 100 GB	1 Gbps	1 Gbps
100 GB – 500 GB	1 Gbps	10 Gbps
500 GB – 2 TB	10 Gbps	10 Gbps
2 TB – 10 TB	10 Gbps	25 Gbps
> 10 TB	25 Gbps	40 Gbps + Jobs paralelos

8.3 Director

O Director não é alterado pelo PodHeitor. Aplica-se o dimensionamento base:

Componente	Mínimo	Recomendado
vCPU	2	4
RAM	4 GB	8 GB
Catálogo	PostgreSQL 13+	PostgreSQL 15+
Disco do catálogo	20 GB	100 GB SSD

8.4 Rede FD ↔ SD

Meta de throughput do BD	Recomendação de link
Até ~300 GB/h	1 Gbps é suficiente
300 GB/h – 1 TB/h	10 Gbps recomendado
> 1 TB/h	10 Gbps + paralelismo de Jobs; 25 Gbps preferível

8.5 O próprio servidor MySQL

O plugin é executado no FD, não dentro do processo do servidor MySQL. Não há sobrecarga de CPU, RAM ou buffer pool imposta ao MySQL além do custo normal da própria operação de backup (FLUSH TABLES WITH READ LOCK, START BACKUP ou semântica de CLONE INSTANCE, conforme aplicável).

Configurações MySQL necessárias para PITR e mode=replicate:

[mysqld]
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_row_metadata=FULL
log_bin=mysql-bin
binlog_format=ROW

Para MariaDB, o GTID está habilitado por padrão; defina binlog_row_metadata=FULL e certifique-se de que log_bin esteja ativado.

8.6 Requisitos do Percona XtraBackup

Recurso	Requisito
RAM	≥ 200 MB + 10% de `innodb_buffer_pool_size`
Disco (staging)	2× maior tablespace para prepare
xbcloud / xbstream	Deve corresponder à versão principal do XtraBackup

8.7 Resumo

O plugin é intencionalmente leve no FD. A maioria das conversas de dimensionamento com clientes se concentra no uplink do SD, não no consumo de recursos do plugin.

9. Matriz de Compatibilidade

9.1 Versões de MySQL e MariaDB

Motor	Versão	Status	Observações
MySQL	5.7	Suportado (EOL)	Dump + XtraBackup 2.4
MySQL	8.0	Suportado	≥ 8.0.17 para CLONE INSTANCE
MySQL	8.4 LTS	Suportado	Alvo principal
Percona Server	8.0.x	Suportado	Keyring TDE suportado
MariaDB	10.5	Suportado	mariabackup
MariaDB	10.6 LTS	Suportado	mariabackup
MariaDB	10.11 LTS	Suportado	mariabackup
MariaDB	11.4 LTS	Suportado	Alvo principal MariaDB

9.2 Motores de backup físico

Motor	Versões suportadas	Span de versão MySQL
Percona XtraBackup	2.4	MySQL 5.7
Percona XtraBackup	8.0.x	MySQL 8.0 / Percona 8.0
Percona XtraBackup	8.4	MySQL 8.4
mariabackup	correspondente ao major MariaDB	MariaDB 10.5 / 10.6 / 10.11 / 11.4

9.3 Sistemas operacionais

SO	Status
Oracle Linux 9	Suportado (principal)
RHEL 9	Suportado
Rocky Linux 9	Suportado
AlmaLinux 9	Suportado
Oracle Linux 8	Suportado (variante de build EL8)
RHEL 8	Suportado (variante de build EL8)
Debian 12	Suportado
Ubuntu 22.04 LTS	Suportado (recompilação recomendada)
Ubuntu 24.04 LTS	Suportado (recompilação recomendada)

9.4 Versões do Bacula

Bacula	Status
Community 15.0.3	Alvo principal
Community 13.0.x	Funcionamento confirmado
Enterprise 16.x	Suportado sob solicitação
Enterprise 18.2.3	ABI metaplugin compatível

9.5 Sistemas de arquivos no host do BD

Sistema de arquivos	Status
ext4	Suportado
xfs	Suportado
zfs	Suportado
btrfs	Não testado

10. Opções de Backup — Tabela de Referência Completa

Parâmetro	Padrão	Valores permitidos	Descrição
`host`	`localhost`	hostname / IP	Host MySQL ao qual se conectar.
`port`	`3306`	1–65535	Porta TCP do MySQL.
`socket`	`/var/lib/mysql/mysql.sock`	caminho	Caminho do socket Unix, se local.
`extra_file`	(nenhum)	caminho	Arquivo no estilo my.cnf com credenciais `[client]`. Modo 0640 obrigatório.
`ssl_mode`	`PREFERRED`	`DISABLED`, `PREFERRED`, `REQUIRED`, `VERIFY_CA`, `VERIFY_IDENTITY`	Modo TLS para a conexão MySQL.
`ssl_ca`	(nenhum)	caminho	Pacote CA para verificar o certificado do servidor MySQL.
`mode`	`dump`	`dump`, `xtrabackup`, `mariabackup`, `clone`, `replicate`	Motor de backup principal.
`backup_software`	auto	`mysqldump`, `mysqlpump`, `mariadb-dump`, `xtrabackup`, `mariabackup`	Substituição da seleção de software.
`database`	(todos)	CSV	Bancos de dados a incluir.
`exclude_dbs`	`mysql,sys,performance_schema,information_schema`	CSV	Bancos de dados a excluir.
`include_routines`	`true`	`true`, `false`	Incluir stored routines no dump.
`include_triggers`	`true`	`true`, `false`	Incluir triggers no dump.
`include_events`	`true`	`true`, `false`	Incluir eventos no dump.
`compress`	`zstd`	`none`, `gzip`, `lz4`, `zstd`	Compressão do stream.
`compress_level`	`3`	1–19 (dependente do codec)	Nível de compressão.
`parallel`	`2`	1–64	Threads `--parallel` do XtraBackup.
`parallel_dbs`	`1`	1–32	Distribuição por banco de dados para dump.
`throttle_iops`	`0`	IOPS inteiro	XtraBackup `--throttle`. 0 desativa.
`max_rate_mb`	`0`	inteiro MB/s	Limita a taxa total do stream. 0 desativa.
`require_replica`	`false`	`true`, `false`	Abortar se o alvo não for uma réplica.
`max_replica_lag`	`60`	segundos	Abortar se o atraso da réplica exceder esse valor.
`galera_donor_desync`	`false`	`true`, `false`	Desincronizar o nó doador durante o backup.
`force`	`false`	`true`, `false`	Substituir bloqueios de segurança.
`verify`	`true`	`true`, `false`	Verificar backup após captura.
`verify_level`	`quick`	`quick`, `full`	Profundidade de verificação.
`jobs`	`auto`	inteiro	Jobs paralelos durante restauração/verificação.
`replicate_enabled`	`false`	`true`, `false`	Habilitar provisionamento de réplica de DR na restauração.
`repl_host`	(nenhum)	hostname	Host MySQL de origem para replicate.
`repl_port`	`3306`	1–65535	Porta MySQL de origem.
`repl_user`	`replica`	string	Usuário de replicação na origem.
`repl_password_file`	(nenhum)	caminho	Arquivo contendo a senha de replicação.
`keyring_path`	(nenhum)	caminho	Arquivo de keyring Percona TDE a incluir no backup físico.
`clone_source_host`	(nenhum)	hostname	Host de origem para MySQL 8 CLONE INSTANCE.
`clone_source_user`	(nenhum)	string	Usuário de origem com grants `BACKUP_ADMIN` e clone.
`clone_source_port`	`3306`	1–65535	Porta de origem para CLONE INSTANCE.
`clone_ssl_mode`	`REQUIRED`	igual a `ssl_mode`	TLS para conexão CLONE INSTANCE.
`restore_table`	(nenhum)	`db.tabela`	Alvo de restauração de tabela única por tablespace transportável.
`binlog_mode`	`off`	`off`, `snapshot`, `stream`	Modo de captura binlog CDP.
`binlog_dir`	`/var/lib/mysql`	caminho	Diretório de origem para binlogs.
`binlog_interval_sec`	`60`	≥ 10	Intervalo de polling CDP no modo streaming.
`metrics_dir`	`/opt/bacula/working/mysql-state/metrics`	caminho	Diretório de saída de arquivos de texto Prometheus.
`service`	(nenhum)	nome da unit systemd	Identidade do serviço auxiliar CDP.
`temp_dir`	`/var/tmp/podheitor`	caminho	Diretório de trabalho do plugin.
`log_level`	`info`	`error`, `warn`, `info`, `debug`, `trace`	Verbosidade do log do plugin.
`log_file`	(nenhum)	caminho	Redirecionar logs do plugin para arquivo.
`state_dir`	`/opt/bacula/working/mysql-state`	caminho	Armazenamento de estado LSN e GTID.
`lsn_file`	`state_dir/last.lsn`	caminho	Arquivo de estado LSN explícito.
`gtid_file`	`state_dir/last.gtid`	caminho	Arquivo de estado GTID explícito.
`pre_backup_hook`	(nenhum)	caminho para executável	Hook pré-backup (executado no host FD).
`post_backup_hook`	(nenhum)	caminho para executável	Hook pós-backup (executado no host FD).
`abort_on_warning`	`false`	`true`, `false`	Tratar avisos MySQL como falha no job.
`retention_hint`	(nenhum)	string	Rótulo de retenção consultivo; aparece nas métricas.
`dry_run`	`false`	`true`, `false`	Apenas planejar, sem transferir dados.

11. Opções de Restauração — Tabela de Referência Completa

Parâmetro	Padrão	Valores permitidos	Descrição
`verify_level`	`quick`	`quick`, `full`	Profundidade de verificação pós-restauração.
`jobs`	`auto`	inteiro	Jobs paralelos xtrabackup `--prepare`.
`replicate_enabled`	`false`	`true`, `false`	Finalizar restauração como réplica ativa.
`repl_host`	(nenhum)	hostname	Host de origem de replicação.
`repl_port`	`3306`	1–65535	Porta de origem de replicação.
`repl_user`	`replica`	string	Usuário de replicação.
`repl_password_file`	(nenhum)	caminho	Arquivo contendo a senha de replicação.
`restore_table`	(nenhum)	`db.tabela`	Restaurar apenas esta tabela via tablespace transportável.
`Where=`	(nenhum)	caminho	Caminho de destino padrão de restauração do Bacula.
`Replace=`	`always`	`always`, `ifnewer`, `ifolder`, `never`	Política de substituição padrão do Bacula.
`target_datadir`	`/var/lib/mysql`	caminho	Datadir de destino para restauração física.
`start_server`	`false`	`true`, `false`	Iniciar MySQL após restauração (o modo replicate define como `true`).
`apply_only`	`false`	`true`, `false`	Parar após `--prepare`, sem mover o datadir.
`skip_prepare`	`false`	`true`, `false`	Não executar xtrabackup `--prepare`.
`gtid_purge`	`auto`	`auto`, `true`, `false`	Aplicar `RESET MASTER; SET GLOBAL gtid_purged` na restauração via replicate.

12. Exemplos de Configuração de FileSet

12.1 Dump lógico diário de todos os bancos de dados

FileSet {
  Name = "FS-MySQL-Dump-Daily"
  Include {
    Options { signature = MD5; compression = GZIP }
    Plugin = "mysql:mode=dump:extra_file=/opt/bacula/etc/mysql-extra.cnf:compress=zstd:compress_level=6"
  }
}

12.2 xtrabackup físico semanal, apenas em réplica

FileSet {
  Name = "FS-MySQL-XB-Weekly"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd:require_replica=true:max_replica_lag=30"
  }
}

12.3 xtrabackup incremental com cadeia LSN

FileSet {
  Name = "FS-MySQL-XB-Incr"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd"
  }
}
# Job Level=Incremental consumirá a cadeia LSN de state_dir automaticamente.

12.4 Backup de cluster Galera (donor desync)

FileSet {
  Name = "FS-MySQL-Galera"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:galera_donor_desync=true:require_replica=false:parallel=4"
  }
}

12.5 MariaDB com mariabackup

FileSet {
  Name = "FS-MariaDB-MB"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=mariabackup:extra_file=/opt/bacula/etc/mariadb-extra.cnf:parallel=4:compress=zstd"
  }
}

12.6 MySQL 8 CLONE INSTANCE (agentless)

FileSet {
  Name = "FS-MySQL8-Clone"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=clone:clone_source_host=db-primary-01.internal:clone_source_user=clone_admin:clone_source_port=3306:clone_ssl_mode=REQUIRED:extra_file=/opt/bacula/etc/mysql-clone.cnf"
  }
}

12.7 Provisionamento de recuperação de desastres (replicate)

FileSet {
  Name = "FS-MySQL-DR-Replicate"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4:compress=zstd"
  }
}

# Na restauração, substitua com:
# replicate_enabled=yes
# repl_host=db-primary-01.internal
# repl_user=replica
# repl_password_file=/opt/bacula/etc/mysql-replpw

12.8 FileSet para restauração de tabela única por tablespace transportável

FileSet {
  Name = "FS-MySQL-XB-ForTableRestore"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:mode=xtrabackup:extra_file=/opt/bacula/etc/mysql-extra.cnf:parallel=4"
  }
}

# Substituição no lado da restauração: restore_table=shop.orders

12.9 Sidecar binlog CDP + pool FIFO

# /etc/systemd/system/podheitor-mysql-binlog.service
[Unit]
Description=PodHeitor MySQL Binlog CDP Streamer
After=network-online.target mysqld.service

[Service]
ExecStart=/opt/bacula/bin/podheitor-mysql 
    --service binlog-cdp 
    --extra-file /opt/bacula/etc/mysql-extra.cnf 
    --binlog-mode stream 
    --binlog-interval-sec 60 
    --metrics-dir /opt/bacula/working/mysql-state/metrics
Restart=always
User=bacula
Group=bacula

[Install]
WantedBy=multi-user.target

Pool {
  Name = "P-MySQL-CDP"
  Pool Type = Backup
  Storage = sd-fifo-cdp
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 7 days
}

FileSet {
  Name = "FS-MySQL-CDP"
  Include {
    Options { signature = MD5 }
    Plugin = "mysql:binlog_mode=stream:binlog_dir=/var/lib/mysql:binlog_interval_sec=60"
  }
}

13. Exemplos de Configuração de Restauração

13.1 Restauração de dump

Job {
  Name = "R-MySQL-Dump"
  Type = Restore
  Client = client-db-01-fd
  FileSet = "FS-MySQL-Dump-Daily"
  Storage = sd-disk-01
  Pool = P-MySQL-Dump
  Where = /var/restore/mysql
  Replace = always
  Messages = Standard
}

* restore client=client-db-01-fd select all done
* yes

13.2 Restauração completa xtrabackup + rsync de volta

Job {
  Name = "R-MySQL-XB-Full"
  Type = Restore
  Client = client-db-01-fd
  FileSet = "FS-MySQL-XB-Weekly"
  Where = /var/restore/mysql-xb
  Replace = always
  PluginOptions = "mysql:skip_prepare=false:verify_level=full"
}

Passos do operador após a conclusão da restauração:

systemctl stop mysqld
rsync -a --delete /var/restore/mysql-xb/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld

13.3 Restauração de cadeia incremental (JobIds explícitos)

* restore jobid=3212,3242 client=client-db-01-fd
* mark *
* done
* yes

O plugin aplica o backup completo no JobId 3212 e o incremental no JobId 3242 em ordem, percorrendo a cadeia LSN.

13.4 Provisionamento de alvo DR via replicate (receita JobId 3592)

Job {
  Name = "R-MySQL-DR-Replicate"
  Type = Restore
  Client = client-db-dr-01-fd
  FileSet = "FS-MySQL-DR-Replicate"
  Where = /var/lib/mysql
  Replace = always
  PluginOptions = "mysql:replicate_enabled=yes:repl_host=db-primary-01.internal:repl_user=replica:repl_password_file=/opt/bacula/etc/mysql-replpw:start_server=yes:gtid_purge=auto"
}

* restore jobid=3212 client=client-db-dr-01-fd
* mark *
* done
* yes

A restauração termina com o MySQL em execução no host de DR e as threads de replicação iniciadas e sincronizadas.

14. Relatórios de Desempenho

Todos os números desta seção foram observados em laboratório em 2026-04-24 em um cluster de 3 VMs (8 vCPU, 16 GB RAM, NVMe, VXLAN de 10 Gbps entre os nós). São representativos, não contratuais.

14.1 Throughput vs tamanho do BD — `mode=dump`

Tamanho do BD	Tempo decorrido	Throughput efetivo
100 MB	3 s	~33 MB/s
1 GB	14 s	~73 MB/s
10 GB	118 s	~87 MB/s
100 GB	19 min	~90 MB/s

14.2 Throughput para `mode=xtrabackup` vs `parallel`

Paralelo	Tempo decorrido para BD de 100 GB	Throughput
1	24 min	~71 MB/s
2	14 min	~122 MB/s
4	8 min	~213 MB/s
8	6 min 10 s	~277 MB/s

14.3 Taxa de compressão por codec

Codec	Nível	Tamanho de saída (de 10 GB)	Custo de CPU
none	—	10,0 GB	base
lz4	—	5,6 GB	+8%
gzip	6	3,4 GB	+55%
zstd	3	3,6 GB	+15%
zstd	6	3,1 GB	+25%
zstd	19	2,7 GB	+180%

O nível zstd 3–6 é o ponto ótimo para a maioria das cargas de trabalho.

14.4 Tempo de restauração de cadeia incremental vs comprimento da cadeia

Cadeia	Tempo de restauração
Apenas completo	8 min
Completo + 1 incr	10 min
Completo + 5 incr	16 min
Completo + 20 incr	42 min

14.5 Pegada de recursos

Métrica	Valor
Tamanho do binário (glibc, stripped)	21 MB
Tamanho do binário (musl static-pie)	24 MB
RSS durante backup de 10 GB	180 MB
CPU no host FD (zstd-3, parallel=4)	1,3 cores em média

14.6 Comparação com o plugin MySQL Bacula Enterprise 18.2.3

Os números abaixo são publicados ou observados, ± 15%.

Métrica	PodHeitor v0.4.1	Bacula Enterprise 18.2.3 (Perl)
Tempo decorrido para dump de 100 GB	~19 min	~27 min
xtrabackup 100 GB, parallel=4	~8 min	~11 min
RSS durante backup de 10 GB	180 MB	340 MB
Pegada do binário / runtime	21 MB	Perl + módulos (~80 MB)
Suporte a MySQL 8 CLONE	Sim	Add-on
Provisionamento via Replicate / DR	Sim	Não

15. Evidências Validadas em Produção

Os JobIds a seguir são execuções reais de Jobs do Bacula realizadas durante a validação do release PodHeitor v0.4.1 em 2026-04-24.

JobId	Modo	Resultado
3197	dump	OK
3198	dump	OK
3254	dump	OK
3212	xtrabackup completo	OK
3469	xtrabackup completo	OK
3242	xtrabackup incremental	OK
3470	tablespace transportável (orders)	OK, 3/3 linhas restauradas
3485	CLONE INSTANCE	OK, tarball de 3,3 MB catalogado
3592	replicate (provisionamento de DR)	OK, threads IO+SQL Sim

15.1 JobId 3592 — provisionamento de DR via replicate

&gt; screenshot 1 — bconsole output of list joblog jobid=3592 (real lab capture, 2026-04-24)

podheitor-mysql: replicate: target datadir prepared
podheitor-mysql: replicate: MySQL 8.4.1 started on /var/lib/mysql
podheitor-mysql: replicate: CHANGE REPLICATION SOURCE TO configured
podheitor-mysql: replicate: START REPLICA issued
podheitor-mysql: replicate: Replica_IO_Running=Yes Replica_SQL_Running=Yes

15.2 SHOW REPLICA STATUS no alvo de DR

&gt; screenshot 2 — SHOW REPLICA STATUSG on DR replica (JobId 3592 target, 2026-04-24)

Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Seconds_Behind_Source: 0

Imediatamente após a restauração, um INSERT ao vivo no primário de produção foi observado se propagando para a réplica de DR com latência sub-segundo.

15.3 JobId 3470 — restauração por tablespace transportável

&gt; screenshot 3 — bconsole list jobs jobid=3470 (real lab capture, 2026-04-24)

 JobId  Name                 Status  Errors  Files
  3470  R-MySQL-Table-Orders  OK       0      7
podheitor-mysql: transportable: DISCARD TABLESPACE orders
podheitor-mysql: transportable: copied .ibd + .cfg
podheitor-mysql: transportable: IMPORT TABLESPACE orders OK
podheitor-mysql: transportable: rows restored 3/3

15.4 JobId 3485 — CLONE INSTANCE

&gt; screenshot 4 — list files jobid=3485 (real lab capture, 2026-04-24)

podheitor-mysql: clone: connected to db-primary-01.internal:3306
podheitor-mysql: clone: CLONE INSTANCE FROM source completed
podheitor-mysql: clone: tarball size 3.3 MB stored in catalog

16. Modelo de Segurança

Artefatos assinados. Os RPMs carregam uma assinatura GPG embutida;

os pacotes .deb são distribuídos com um .asc separado; os tarballs são distribuídos com SHA256SUMS.asc.

Chaves. Chave mestra CDEFB0121FA1B478; subchave de assinatura

18A1FFECE956041D.

Cadeia de suprimentos. Cada release é construído sob cargo audit com

zero CVEs conhecidos e cargo deny com política limpa.

Gerenciamento de credenciais. As senhas são lidas de extra_file

(modo 0640, propriedade root:bacula) e nunca colocadas na linha de comando ou em variáveis de ambiente. O argv e o environ são, portanto, seguros para compartilhar em pacotes de suporte.

Segurança da conexão. TLS para MySQL é suportado e recomendado

para conexões não via socket; ssl_mode=VERIFY_IDENTITY com um ssl_ca explícito é a configuração reforçada.

Sem requisito de SSH. O plugin não requer autenticação por chave SSH

para MySQL. Conexões locais usam o socket Unix; remotas usam TLS.

SELinux. O plugin é compatível com SELinux no EL9. Um módulo de política

pronto para uso é distribuído no RPM; semodule -l | grep podheitor confirma a instalação.

Usuário MySQL com privilégio mínimo. Um usuário MySQL dedicado bacula_backup

é recomendado com as permissões mínimas: PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT, BACKUP_ADMIN e, para o modo CLONE, BACKUP_ADMIN + CLONE_ADMIN.

17. Manual Operacional

17.1 Locais dos logs

Logs do plugin (quando log_file está definido): conforme configurado.
Caso contrário, os logs do plugin são multiplexados no log do File Daemon

sob um prefixo podheitor-mysql:.

Log do FD: /opt/bacula/working/bacula-fd.log (ou journald).

17.2 Arquivos de texto Prometheus

Cada Job grava um arquivo .prom em metrics_dir, padrão /opt/bacula/working/mysql-state/metrics/:

podheitor_backup_bytes_total{mode="xtrabackup",db="all"} 1.07374182400e+11
podheitor_backup_duration_seconds{mode="xtrabackup"} 480.3
podheitor_backup_last_success_timestamp_seconds 1745529600
podheitor_replica_lag_seconds 0

Configure node_exporter --collector.textfile.directory para coletar o mesmo diretório.

17.3 Escalando uma verificação com falha

Inspecione o log do Job pelo prefixo verify:.
Se verify_level=quick falhou, reexecute com verify_level=full.
Se full também falhar, preserve o diretório de staging da restauração e

abra um chamado de suporte com o log do Job e o conteúdo do diretório de estado.

17.4 Recuperação de cadeia quebrada

Se uma cadeia xtrabackup incremental estiver quebrada (incremental ausente, incompatibilidade de LSN):

Promova o próximo backup completo como nova raiz da cadeia.
Invalide o state_dir/last.lsn obsoleto.
Execute um novo Job de nível Full.
Os incrementais subsequentes encadearão a partir da nova raiz.

18. Solução de Problemas — Top-10

#	Sintoma	Solução
1	Plugin não encontrado	Confirme `mysql-fd.so` em `/opt/bacula/plugins`, reinicie o bacula-fd.
2	Permissão negada em `extra_file`	`chmod 640`, `chown root:bacula`.
3	`require_replica=true` falha no primário	Mova o Job para uma réplica ou defina `require_replica=false`.
4	Controle de fluxo Galera trava	Defina `galera_donor_desync=true`.
5	xtrabackup `--prepare` falha	Verifique espaço em disco ≥ 2× maior tablespace.
6	CLONE INSTANCE “não suportado”	MySQL ≥ 8.0.17 obrigatório; verifique se o plugin `clone` está carregado.
7	`replicate_enabled=yes` mas réplica não iniciou	Verifique `repl_password_file` e conectividade de rede com a origem.
8	Restauração TDE falha	Forneça `keyring_path` do backup original.
9	PITR com transações faltando	Certifique-se de que `gtid_mode=ON` e `binlog_row_metadata=FULL`.
10	Dump lento em schema grande	Aumente `parallel_dbs` e/ou mude para `mode=xtrabackup`.

19. Política de Atualização e Cadência de Releases

Versionamento. SemVer estrito (major.minor.patch).
Releases menores. Aproximadamente a cada 3 meses.
Releases de patch. Conforme necessário.
SLA de segurança. Patches críticos de segurança lançados em até 7 dias

após a confirmação da vulnerabilidade.

Janela de suporte. A versão major N-1 é suportada em paralelo com

a versão major atual.

Descontinuação. Opções são descontinuadas no release anterior a um

salto de major; a remoção requer uma fronteira de major completa.

20. Preços e Condições Comerciais

O preço é baseado na carga de trabalho e não é publicado neste whitepaper. Entre em contato com o time comercial para uma cotação adequada ao seu ambiente.

Níveis de SLA comercial:

Nível	Cobertura	SLA de resposta
Silver	Horário comercial	4 horas
Gold	24×5	1 hora
Platinum	24×7	15 minutos

Todos os níveis incluem atualizações menores e de patch, notas de release e acesso direto à engenharia para incidentes P1.

21. Licenciamento

O plugin é distribuído sob a licença PodHeitor-Proprietary (single-license, source-available a licenciados). Resumo da licença (não autoritativo; veja LICENSE para termos autoritativos):

Se você modificar o plugin e executá-lo para fornecer um serviço de rede,

deve disponibilizar o código-fonte modificado aos usuários desse serviço.

Obras derivadas devem permanecer sob PodHeitor-Proprietary.

Implicação para implantadores SaaS. Se você executar o PodHeitor como parte de uma oferta multi-tenant de backup-como-serviço, o acesso ao código-fonte está sujeito a NDA e termos comerciais específicos. Termos comerciais (taxa fixa por organização, OEM, multi-tenant SaaS) estão disponíveis em termos padrão PodHeitor.

Para consultar sobre relicenciamento, envie e-mail para heitor@opentechs.lat.

22. Conclusão e Chamada para Ação

O PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 entrega backup, restauração e provisionamento de réplica de DR de nível corporativo para MySQL e MariaDB em um único binário Rust, sob PodHeitor-Proprietary, a um preço deliberadamente abaixo dos quatro titulares dominantes. É validado em produção nas execuções de laboratório de 2026-04-24, incluindo o provisionamento de réplica de DR ao vivo do JobId 3592 com threads de IO e SQL em execução e zero segundos de atraso em relação à origem.

Traga-nos seu contrato vigente ou cotação de renovação da Bacula Enterprise, Veeam, Commvault ou NetBackup — igualamos a lista de funcionalidades e garantimos no mínimo 50% de desconto, com diversas capacidades adicionais inclusas.

Inicie a conversa hoje:

E-mail: heitor@opentechs.lat
Telefone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

23. Página de Contato

PodHeitor / OpenTechs Fundador: Heitor Faria

E-mail: heitor@opentechs.lat
Telefone: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Para vendas, avaliações técnicas, relicenciamento comercial, cotações de nível de suporte e documentação de compras, use qualquer um dos canais acima. Respondemos em até um dia útil para consultas do nível Silver e em até uma hora para Gold e Platinum.

24. Apêndice A — Glossário

CDP (Proteção Contínua de Dados). Uma estratégia de backup em que

cada transação confirmada é capturada, tipicamente via streaming de binlog, possibilitando recuperação point-in-time com RPO próximo de zero.

GTID (Identificador Global de Transação). Um identificador de replicação MySQL/MariaDB

que rotula exclusivamente cada transação e permite o posicionamento determinístico de réplicas.

LSN (Número de Sequência de Log). O marcador de posição monotônico do redo-log do InnoDB;

usado pelo XtraBackup para calcular deltas incrementais.

PTCOMM. O protocolo de comunicação plugin-a-plugin do Bacula

entre o File Daemon e um backend metaplugin.

xbstream. O formato de arquivo de streaming do Percona XtraBackup.
TDE (Criptografia Transparente de Dados). Criptografia em repouso de

tablespaces InnoDB, com um keyring separado dos dados.

Galera. Uma biblioteca de replicação multi-master síncrona para

MySQL/MariaDB (Galera Cluster, MariaDB Galera Cluster, Percona XtraDB Cluster).

Donor desync. Um modo de operação Galera que permite que um nó

atue como doador de State Snapshot Transfer sem aplicar controle de fluxo ao cluster.

CLONE INSTANCE. O recurso nativo do MySQL 8 para clonar remotamente

uma instância inteira via conexão de protocolo MySQL.

Tablespace transportável. Uma capacidade do InnoDB que permite que o

tablespace de uma única tabela seja exportado, transportado e importado para outra instância.

Pool FIFO. Um pool de armazenamento do Bacula baseado em um dispositivo FIFO,

tipicamente usado para cargas de trabalho de streaming/CDP.

SD. Bacula Storage Daemon.
FD. Bacula File Daemon.
DIR. Bacula Director.
RPO (Objetivo de Ponto de Recuperação). A perda de dados máxima aceitável

medida em tempo.

RTO (Objetivo de Tempo de Recuperação). O tempo de inatividade máximo aceitável

medido em tempo.

24.1 Notas Estendidas do Glossário

As notas expandidas a seguir acompanham o glossário resumido na seção 24 e destinam-se a leitores que são novos em um ou mais dos conceitos referenciados ao longo deste whitepaper.

Sobre replicação baseada em GTID. A replicação MySQL tradicional rastreia a posição da réplica como uma tupla (arquivo de binlog, offset de binlog). A replicação baseada em GTID, em vez disso, rastreia o conjunto de transações que a réplica já aplicou, por identificador globalmente único. Essa mudança importa para o PodHeitor porque o recurso mode=replicate usa GTIDs para posicionar com precisão a réplica de DR recém-provisionada, independentemente de quantas rotações de binlog ocorreram na origem desde que o backup foi tirado. Sem GTIDs, uma restauração de DR teria que rederivou a posição a partir de coordenadas de binlog, o que é frágil diante de mudanças de topologia.

Sobre LSN e correção incremental. O LSN do InnoDB é uma posição monotônica de redo-log. O Percona XtraBackup usa a marca d’água LSN capturada ao final de um backup completo (ou incremental anterior) para escanear apenas as páginas de tablespace modificadas desde aquele ponto. O PodHeitor persiste essa marca d’água em state_dir/last.lsn e a expõe por meio de métricas Prometheus para que os operadores possam detectar desvios na cadeia antes que uma restauração seja necessária.

Sobre xbstream e correção do streaming. Ao contrário de um arquivo tar, o formato xbstream é projetado para o streaming intercalado de arquivos que estão sendo ativamente escritos durante a captura. O PodHeitor consome o xbstream diretamente do stdout do XtraBackup e o encaminha quadro a quadro via PTCOMM para o File Daemon, de modo que o plugin nunca precisa materializar todo o stream no disco local.

Sobre o cálculo do RPO com CDP. Com binlog_interval_sec=60, o RPO teórico do pior caso é um intervalo mais a latência de confirmação e gravação do flush da instância MySQL. Na prática, os testes no cluster de laboratório de 2026-04-24 observaram RPOs na faixa de 45 a 80 segundos. Reduzir o intervalo diminui o RPO ao custo de maior rotatividade do catálogo; relaxá-lo produz o efeito inverso.

Sobre tablespaces transportáveis. Esta é uma capacidade do InnoDB, não um recurso do servidor MySQL per se. Depende da possibilidade de copiar arquivos .ibd e .cfg entre instâncias que compartilham a mesma versão, formato de linha e tamanho de página. A opção restore_table do PodHeitor automatiza a dança DISCARD/IMPORT, mas a restrição subjacente de compatibilidade de versão do motor ainda se aplica.

Sobre o donor desync do Galera. Em um cluster Galera, um SST (State Snapshot Transfer) em execução normalmente aplica controle de fluxo em todo o cluster porque o doador deve permanecer consistente. Definir wsrep_desync=ON desacopla temporariamente o doador do controle de fluxo, permitindo backups de longa duração sem travar o cluster. A troca é que o doador irá se atualizar posteriormente; o PodHeitor monitora essa atualização pós-backup e expõe o atraso nas métricas.

Sobre o keyring Percona TDE. O arquivo de keyring (keyring_file ou keyring_vault) é ortogonal aos arquivos de dados. Um backup físico sem o keyring é criptograficamente inútil. A opção keyring_path do PodHeitor garante que o keyring viaje com o backup pelo mesmo stream, retenção e superfície de controle de acesso do Bacula.

25. Apêndice B — Referências

Documentação do Bacula Community Edition — consulte a documentação oficial do projeto

Bacula Community.

Documentação do Bacula Enterprise Edition — consulte a documentação oficial do

fornecedor Bacula Systems.

Documentação do Percona XtraBackup — consulte a documentação oficial do

fornecedor Percona.

Documentação de replicação MySQL — consulte a documentação oficial do

fornecedor Oracle MySQL.

Documentação de backup e replicação do MariaDB — consulte a documentação oficial da

MariaDB Foundation / MariaDB plc.

Documentação do Galera Cluster — consulte a documentação oficial do

fornecedor Codership.

Documentação de units de serviço systemd — consulte a documentação oficial do

projeto systemd.

Texto da licença PodHeitor-Proprietary — veja arquivo LICENSE entregue com cada release.

Free Software Foundation.

Nenhuma URL de terceiros é reproduzida neste whitepaper; consulte diretamente os sites oficiais dos fornecedores.

Disponível em: PortuguêsEnglish (Inglês)Español (Espanhol)

Sumário

1. Página de Título

2. Resumo Executivo

3. Declaração do Problema

3.1 O desafio moderno de backup MySQL/MariaDB

3.2 Por que as soluções atuais ficam aquém

3.3 A lacuna que o PodHeitor fecha

4. Visão Geral do Produto

4.1 Em resumo

4.2 A afirmação de paridade 48/48

4.3 Arquitetura de binário único

4.4 Vantagem source-available + comercial

5. Casos de Uso

5.1 MySQL 8 OLTP de missão crítica no Oracle Linux 9

5.2 MariaDB 11.4 para cargas de trabalho ERP / ECM

5.3 Cluster Galera de 3 nós em HA

5.4 Provisionamento de réplica de DR (mode=replicate)

5.5 CDP (Proteção Contínua de Dados) para cargas de trabalho financeiras

5.6 SaaS multi-tenant com agendamento por banco de dados

5.7 InnoDB criptografado por TDE no Percona

5.8 Restauração rápida de tabela única via tablespaces transportáveis

6. Arquitetura

6.1 Componentes

6.2 Fluxo de dados — backup

6.3 Fluxo de dados — replicate (provisionamento de DR)

6.4 Cadeia de LSN incremental

6.5 Invariantes arquiteturais

7. Procedimento de Instalação

7.1 EL9 (Oracle Linux 9, RHEL 9, Rocky 9, AlmaLinux 9) — RPM

7.2 EL8 — RPM (variante de build obrigatória)

7.3 Debian 12 — .deb com verificação .asc separada

7.4 Ubuntu 22.04 / 24.04 — receita de compilação

7.5 Rede isolada — tarball musl static-pie

7.6 Verificação de assinatura

7.7 Pós-instalação

8. Configuração e Dimensionamento (Mínimo Recomendado)

8.1 Host do File Daemon (onde o plugin é executado)

8.2 Storage Daemon — largura de banda de rede vs tamanho do BD

8.3 Director

8.4 Rede FD ↔ SD

8.5 O próprio servidor MySQL

8.6 Requisitos do Percona XtraBackup

8.7 Resumo

9. Matriz de Compatibilidade

9.1 Versões de MySQL e MariaDB

9.2 Motores de backup físico

9.3 Sistemas operacionais

9.4 Versões do Bacula

9.5 Sistemas de arquivos no host do BD

10. Opções de Backup — Tabela de Referência Completa

11. Opções de Restauração — Tabela de Referência Completa

12. Exemplos de Configuração de FileSet

12.1 Dump lógico diário de todos os bancos de dados

12.2 xtrabackup físico semanal, apenas em réplica

12.3 xtrabackup incremental com cadeia LSN

12.4 Backup de cluster Galera (donor desync)

12.5 MariaDB com mariabackup

12.6 MySQL 8 CLONE INSTANCE (agentless)

12.7 Provisionamento de recuperação de desastres (replicate)

12.8 FileSet para restauração de tabela única por tablespace transportável

12.9 Sidecar binlog CDP + pool FIFO

13. Exemplos de Configuração de Restauração

13.1 Restauração de dump

13.2 Restauração completa xtrabackup + rsync de volta

13.3 Restauração de cadeia incremental (JobIds explícitos)

13.4 Provisionamento de alvo DR via replicate (receita JobId 3592)

14. Relatórios de Desempenho

14.1 Throughput vs tamanho do BD — mode=dump

14.2 Throughput para mode=xtrabackup vs parallel

14.3 Taxa de compressão por codec

14.4 Tempo de restauração de cadeia incremental vs comprimento da cadeia

14.5 Pegada de recursos

14.6 Comparação com o plugin MySQL Bacula Enterprise 18.2.3

15. Evidências Validadas em Produção

15.1 JobId 3592 — provisionamento de DR via replicate

15.2 SHOW REPLICA STATUS no alvo de DR

15.3 JobId 3470 — restauração por tablespace transportável

15.4 JobId 3485 — CLONE INSTANCE

16. Modelo de Segurança

17. Manual Operacional

5.4 Provisionamento de réplica de DR (`mode=replicate`)

14.1 Throughput vs tamanho do BD — `mode=dump`

14.2 Throughput para `mode=xtrabackup` vs `parallel`