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

Producto: PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula Versión: v0.4.1 Fecha de lanzamiento: 2026-04-24 Autor: Heitor Faria, Fundador de PodHeitor / OpenTechs Clasificación: Confidencial — uso con clientes Copyright © 2026 Heitor Faria — todos los derechos reservados.

Contactos principales (ventas, técnico y comercial):

Correo: heitor@opentechs.lat
Teléfono: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Tráiganos su contrato vigente o cotización de renovación de Bacula Enterprise, Veeam, Commvault o NetBackup — igualamos la lista de funcionalidades y garantizamos un mínimo de 50% de descuento, con muchas capacidades adicionales incluidas.

Tabla de Contenidos

Portada
Resumen Ejecutivo
Planteamiento del Problema
Descripción General del Producto
Casos de Uso
Arquitectura
Procedimiento de Instalación
Configuración y Dimensionamiento (Mínimo Recomendado)
Matriz de Compatibilidad
Opciones de Backup — Tabla de Referencia Completa
Opciones de Restauración — Tabla de Referencia Completa
Ejemplos de Configuración de FileSet
Ejemplos de Configuración de Restauración
Informes de Rendimiento
Evidencia Validada en Producción
Modelo de Seguridad
Manual Operacional
Solución de Problemas — Top-10
Política de Actualización y Cadencia de Releases
Precios y Condiciones Comerciales
Licenciamiento
Conclusión y Llamada a la Acción
Página de Contacto
Apéndice A — Glosario
Apéndice B — Referencias

1. Portada

PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula

Clasificación: Confidencial — uso con clientes

Contactos:

Correo: heitor@opentechs.lat
Teléfono: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Este documento describe las capacidades, la arquitectura, la instalación, la configuración, las prácticas operacionales, las condiciones comerciales y el licenciamiento del PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula, versión v0.4.1. Está preparado para una audiencia mixta de tomadores de decisión de nivel C, administradores de bases de datos, administradores de sistemas y responsables de compras. Todo el contenido es propiedad de Heitor Faria y se distribuye bajo términos de distribución confidencial para clientes.

2. Resumen Ejecutivo

Las empresas que operan MySQL y MariaDB a escala de producción enfrentan una contradicción persistente y costosa. Por un lado, estas bases de datos son la columna vertebral operacional de sistemas OLTP, ERP, ECM, planos de control SaaS, libros contables financieros y cargas de trabajo reguladas. Por otro lado, el mercado de herramientas de backup alrededor de ellas se ha consolidado en un pequeño número de incumbentes — Bacula Enterprise, Veeam, Commvault y Veritas NetBackup — cuyos modelos de licenciamiento, decisiones arquitectónicas y curvas de precios están cada vez más desalineados con las realidades de los entornos modernos de MySQL/MariaDB: clústeres Galera escalados horizontalmente, cargas de trabajo Percona TDE, aprovisionamiento basado en MySQL 8 Clone, MariaDB 11.4 LTS, protección continua de datos estilo CDP vía binlog, y réplicas de recuperación ante desastres geo-distribuidas.

El PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 es un plugin para el File Daemon de Bacula construido específicamente para este propósito — un binario único, implementado en Rust — que entrega 48 de las 48 capacidades documentadas de backup MySQL/MariaDB empresarial en una sola distribución. Está single-licensed bajo PodHeitor-Proprietary, con licenciamiento comercial disponible para clientes que lo necesiten. Está diseñado para integrarse en implementaciones existentes de Bacula Community (15.0.3 como objetivo principal) o Bacula Enterprise sin requerir una migración completa del Director, el Storage Daemon o la infraestructura de catálogo.

PodHeitor v0.4.1 resuelve cuatro problemas concretos a la vez:

Paridad de funcionalidades. Corresponde a la lista documentada de funcionalidades del plugin MySQL empresarial línea por línea, incluyendo volcados lógicos, backup físico Percona XtraBackup y mariabackup completo/incremental/diferencial, coordinación de donor-desync de Galera, aprovisionamiento de réplica agentless vía MySQL 8 CLONE INSTANCE, restauración de tabla única por tablespace transportable, backup físico con soporte al keyring Percona TDE, CDP basado en binlog y — nuevo en la línea 0.x — aprovisionamiento completo de réplica de recuperación ante desastres vía mode=replicate, que levanta una réplica MySQL activa y en sincronización directamente desde un job de restauración de Bacula.

Arquitectura de binario único. El plugin se distribuye como un único binario Rust (podheitor-mysql) invocado a través de un shim metaplugin ligero de Bacula. No hay dependencia de runtime Perl, ninguna cadena de herramientas de segunda lengua, ningún grafo de dependencias de objetos compartidos más allá de libc o musl. Esto reduce drásticamente la superficie de ataque, la huella en la cadena de suministro y la varianza operacional en comparación con los plugins empresariales basados en Perl.

Economía comercial. PodHeitor está deliberadamente posicionado por debajo de los puntos de precio de Bacula Enterprise, Veeam, Commvault y NetBackup. Nuestra oferta comercial permanente es simple e incondicional: tráiganos su contrato vigente o cotización de renovación de cualquiera de esos cuatro proveedores, e igualamos la lista de funcionalidades y garantizamos un mínimo de 50% de descuento, con muchas capacidades adicionales incluidas.

Apalancamiento de código abierto. Source-available con licencia comercial: el código fuente se proporciona bajo NDA y es auditable, inspeccionable y compilable por el cliente — satisfaciendo los procesos de compras y revisión de seguridad más estrictos. Para clientes cuyo modelo de implementación (por ejemplo, redistribución SaaS código cerrado) requieren términos comerciales específicos para ese caso de uso.

Tráiganos su contrato vigente o cotización de renovación de Bacula Enterprise, Veeam, Commvault o NetBackup — igualamos la lista de funcionalidades y garantizamos un mínimo de 50% de descuento, con muchas capacidades adicionales incluidas.

Para iniciar la conversación: escriba a heitor@opentechs.lat, llame al +1 (786) 726-1749 o envíe un mensaje al +55 (61) 98268-4220 por WhatsApp.

3. Planteamiento del Problema

3.1 El desafío moderno del backup MySQL/MariaDB

MySQL y MariaDB se han convertido silenciosamente en la base de datos transaccional predeterminada para la mayoría de las cargas de trabajo de producción fuera de los ecosistemas de mainframe e hyperscaler gestionados. El perfil operacional de esas cargas de trabajo ha cambiado significativamente en los últimos cinco años:

Los conjuntos de datos superan rutinariamente 1 TB por instancia, con muchos excediendo

10 TB.

Los clústeres Galera de 3 a 7 nodos son comunes en topologías de alta disponibilidad.

Percona Server con InnoDB cifrado por TDE es el estándar para sectores regulados

(financiero, salud, sector público).

MariaDB 10.6 y 11.4 LTS dominan el segmento de ERP y ECM,

especialmente en Europa y América Latina.

Las estrategias de DR dependen cada vez más de réplicas geo-distribuidas que

deben levantarse, reconstruirse y rebasarse bajo demanda — no solo «restaurarse desde cinta».

Los marcos regulatorios (PCI-DSS, LGPD, GDPR, HIPAA, SOX) requieren

RPOs en el rango de minutos de un solo dígito, que solo el CDP basado en binlog puede entregar.

Frente a esto, la base instalada de herramientas de backup MySQL no está siguiendo el ritmo.

3.2 Por qué las soluciones actuales se quedan cortas

Plugin MySQL Bacula Enterprise 18.2.3. El plugin MySQL empresarial incumbente de la familia Bacula está implementado en Perl. Perl es un lenguaje capaz, pero en 2026 impone costos reales: un gran runtime de intérprete en cada host del File Daemon, árboles de dependencias CPAN que complican las implementaciones en redes aisladas, ejecución más lenta para tareas intensivas de cómputo como compresión y manejo de streams, y un grupo cada vez menor de ingenieros lo suficientemente fluidos para depurarlo en producción. El plugin MySQL en Perl también está rezagado en funcionalidades más recientes — MySQL 8 Clone, restauración de tabla única por tablespace transportable y aprovisionamiento de réplica de DR están ausentes o se entregan a través de módulos adicionales.

Veeam Backup & Replication. El soporte MySQL de Veeam está implementado como un agente, no como un motor de primera clase. Esto funciona aceptablemente para instancias pequeñas, pero no se integra limpiamente con Galera, no ofrece MySQL 8 Clone agentless y empuja a los clientes hacia la curva de licenciamiento orientada a virtualización de Veeam, que es costosa a escala de bases de datos.

Commvault. Commvault ofrece amplia cobertura de plataformas a un alto costo total de propiedad. El licenciamiento es por capacidad y escala abruptamente; el iDataAgent de MySQL es competente pero no diferenciado, y el TCO para un entorno MySQL de tamaño mediano es rutinariamente 3 a 5× lo que PodHeitor entrega para cobertura equivalente.

Veritas NetBackup. La cobertura MySQL de NetBackup es pesada y está fuertemente acoplada a la arquitectura de media-server y catálogo de NetBackup. Es una opción viable solo para clientes ya estandarizados en NetBackup en toda la empresa; para entornos que priorizan MySQL o Bacula, los costos de licenciamiento y la sobrecarga operacional son desproporcionados.

3.3 La brecha que PodHeitor cierra

PodHeitor v0.4.1 cierra esta brecha entregando capacidades de backup, restauración y replicación MySQL y MariaDB de nivel empresarial como un plugin de primera clase para el File Daemon de Bacula, sin Perl, sin agentes, sin licenciamiento por capacidad y sin dependencia de proveedor. Apunta exactamente a la lista de funcionalidades por las que cobran los cuatro incumbentes — y las iguala — permaneciendo dentro de un único binario Rust autocontenido que un DBA puede auditar, un administrador de sistemas puede implementar y un CISO puede aprobar.

4. Descripción General del Producto

4.1 En resumen

Nombre: PodHeitor MySQL/MariaDB Backup and Replication Plugin for

Bacula

Versión: v0.4.1
Fecha de lanzamiento: 2026-04-24
Lenguaje: Rust (toolchain estable), empaquetado como un único

binario static-pie para uso en redes aisladas y como builds glibc para repositorios RPM y DEB

Licencia: PodHeitor-Proprietary — Copyright © Heitor Faria. Todos los derechos reservados
Superficie de integración: API metaplugin del File Daemon de 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); aprovisionamiento vía replicate/DR

4.2 La afirmación de paridad 48/48

PodHeitor v0.4.1 documenta e implementa 48 capacidades distintas de backup MySQL/MariaDB empresarial, correspondiendo a la lista de funcionalidades publicada del plugin MySQL Bacula Enterprise 18.2.3 línea por línea. Las 48 capacidades abarcan siete grupos funcionales:

Backup lógico (volcado) — 6 capacidades
Backup físico (xtrabackup / mariabackup) — 10 capacidades
Conciencia de clúster y réplica — 7 capacidades
Aprovisionamiento agentless (CLONE INSTANCE) — 4 capacidades
Restauración de tabla única transportable — 3 capacidades
TDE, cifrado y gestión de keyring — 5 capacidades
CDP, streaming de binlog y aprovisionamiento vía replicate/DR — 13

capacidades

Cada capacidad se mapea a una o más opciones del plugin documentadas en las tablas de referencia más adelante en este whitepaper. El mapeo se mantiene en el documento fuente de verdad docs/ENTERPRISE_PARITY.md en el repositorio del producto y está vinculado a la versión v0.4.1.

4.3 Arquitectura de binario único

El plugin se construye y distribuye como un único binario Rust. No tiene dependencia de runtime Perl, Python, Ruby o Go. En plataformas glibc, enlaza solo contra el libc y libssl del sistema; en el build musl static-pie para redes aisladas, es totalmente autocontenido. El shim metaplugin de Bacula (mysql-fd.so) es un cargador C mínimo que reenvía frames PTCOMM hacia y desde el binario Rust — no contiene lógica de negocio.

Esta arquitectura importa por cuatro razones:

Cadena de suministro. La superficie de dependencias se reduce al grafo de crates Rust, auditado con cargo audit y cargo deny en cada release.

Implementación. Las instalaciones en redes aisladas se reducen a copiar un binario

y un archivo de configuración.

Observabilidad. Un binario único significa un único prefijo de log, una única

fuente de métricas, un único objetivo de depuración.

Postura de seguridad. Sin intérprete en disco, sin runtime de

lenguaje auxiliar, sin archivos de script con permiso de lectura global.

4.4 Ventaja source-available + comercial

El plugin es single-licensed bajo PodHeitor-Proprietary (Copyright © Heitor Faria). El código fuente se proporciona a licenciatarios bajo esa misma licencia comercial, ofreciendo cuatro beneficios concretos:

El código fuente es auditable antes de la compra.
El cliente puede recompilar el binario internamente si lo requiere

el departamento de compras.

Las correcciones de errores pueden proponerse upstream o aplicarse localmente.
No hay situación de dependencia de proveedor — si PodHeitor dejara de

existir, el cliente retiene un producto funcional y compilable.

Para implementadores SaaS que necesiten términos OEM, multi-tenant SaaS, o per-organización con tarifa fija, el relicenciamiento comercial está disponible en términos estándar.

5. Casos de Uso

5.1 MySQL 8 OLTP de misión crítica en Oracle Linux 9

Un procesador de pagos ejecuta MySQL 8.4 LTS en Oracle Linux 9, con conjuntos de datos en el rango de 2 a 4 TB y un objetivo de RPO de 5 minutos. PodHeitor se implementa en el File Daemon co-localizado con el primario MySQL. Un backup completo semanal vía mode=xtrabackup captura la instancia a nivel físico; los incrementales diarios recorren la cadena de LSN; el CDP vía binlog transmite cada transacción confirmada a un pool FIFO de Bacula en cadencia de 1 minuto. La recuperación valida un RPO efectivo consistente de 3 a 4 minutos con restauración en pocos minutos a un host de prueba.

5.2 MariaDB 11.4 para cargas de trabajo ERP / ECM

Un proveedor de ERP de tamaño mediano ejecuta MariaDB 11.4 LTS en 40 inquilinos clientes, cada uno en un esquema dedicado. La opción parallel_dbs de PodHeitor distribuye volcados lógicos por esquema, con compress=zstd en nivel 6, produciendo artefactos de restauración aislados por inquilino dentro de un único Job de Bacula. La restauración a nivel de inquilino es un único comando bconsole referenciando el esquema relevante, sin restaurar toda la instancia.

5.3 Clúster Galera de 3 nodos en HA

Un operador de telecomunicaciones ejecuta un clúster Galera de 3 nodos para datos de suscriptores. La opción galera_donor_desync=true de PodHeitor coordina con Galera para poner el nodo de backup en estado donor-desync durante un backup físico, evitando que el control de flujo detenga el clúster activo. require_replica=true asegura que el backup solo se ejecute en un nodo no primario.

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

Una fintech requiere réplicas de DR en caliente en una región secundaria, reconstruidas semanalmente desde el backup para garantizar su vigencia. La opción mode=replicate de PodHeitor realiza una restauración que termina con una réplica MySQL ya configurada y en ejecución: los hilos de IO y SQL se inician, CHANGE REPLICATION SOURCE TO se aplica desde los metadatos capturados, y el posicionamiento GTID coloca la réplica en el punto correcto del stream de binlog. Un INSERT en vivo ejecutado en el primario después de la restauración fue observado propagándose a la réplica de DR en segundos — validado en nuestro laboratorio como JobId 3592 el 2026-04-24.

5.5 CDP (Protección Continua de Datos) para cargas de trabajo financieras

Un bróker regulado requiere RPO a nivel de transacción. El servicio auxiliar de binlog de PodHeitor transmite logs binarios continuamente a un pool FIFO dedicado de Bacula, con binlog_interval_sec=60 y binlog_mode=stream. La restauración combina el último backup completo, la cadena de incrementales y la cola del binlog para recuperación point-in-time en cualquier transacción confirmada.

5.6 SaaS multi-inquilino con programación por base de datos

Un plano de control SaaS separa los inquilinos por base de datos. Las opciones database y exclude_dbs de PodHeitor permiten Jobs de Bacula por inquilino con retención, programación y pool de almacenamiento independientes — todo desde el mismo binario del plugin. La restauración con ámbito de cliente, la eliminación con ámbito de cliente y la retención legal con ámbito de cliente se derivan de los primitivos estándar de Bacula.

5.7 InnoDB cifrado por TDE en Percona

Un proveedor de salud ejecuta Percona Server 8.0 con InnoDB cifrado por TDE. La opción keyring_path de PodHeitor captura el archivo de keyring junto con el stream de backup físico, de modo que la restauración produce una instancia criptográficamente consistente. El keyring se transmite por el mismo stream de Bacula y está cubierto por la misma política de retención del catálogo que la propia base de datos.

5.8 Restauración rápida de tabla única vía tablespaces transportables

La tabla orders de una plataforma de comercio minorista se trunca accidentalmente. La opción restore_table=orders de PodHeitor, combinada con el flujo de trabajo de tablespace transportable, restaura solo esa tabla — no la instancia completa de 3 TB. Validado en laboratorio como JobId 3470 el 2026-04-24 con una restauración limpia de 3 de 3 filas.

6. Arquitectura

6.1 Componentes

Bacula Director — sin cambios. Emite inicio de Job, programación,

retención y actualizaciones de catálogo.

Bacula File Daemon (FD) — sin cambios. Aloja el plugin PodHeitor

a través de la interfaz metaplugin estándar.

Shim metaplugin (mysql-fd.so) — cargador C mínimo. Reenvía

frames PTCOMM entre el FD y el backend Rust.

Backend Rust PodHeitor (podheitor-mysql) — binario Rust único.

Implementa toda la lógica de backup, restauración, replicación, CDP y verificación.

Servidor MySQL / MariaDB — sin cambios. Contactado vía socket local

o TCP, autenticado vía extra_file.

Bacula Storage Daemon (SD) — sin cambios. Recibe el stream de backup.

6.2 Flujo de datos — backup

*Flujo de backup de PodHeitor MySQL (diagrama de secuencia)*

6.3 Flujo de datos — replicate (aprovisionamiento de DR)

*Flujo de restauración con replicación para DR (diagrama de secuencia)*

6.4 Cadena de LSN incremental

*Cadena incremental de PodHeitor MySQL — flujo de LSN de xtrabackup*

6.5 Invariantes arquitectónicos

El plugin nunca se ejecuta dentro del proceso del servidor MySQL. Toda la

sobrecarga está en el host del FD.

PTCOMM es el único acoplamiento entre el backend Rust y el FD.
Ninguna credencial se pasa en la línea de comandos o en variables de entorno;

toda la autenticación MySQL se realiza vía extra_file en disco con modo 0640.

El stream de backup es opaco para el FD; todo el encuadrado específico de MySQL

reside dentro del binario Rust.

7. Procedimiento de Instalación

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

El paquete instala:

/opt/bacula/plugins/mysql-fd.so — shim metaplugin
/opt/bacula/bin/podheitor-mysql — backend Rust
/opt/bacula/etc/podheitor-mysql.conf.example — configuración plantilla
/usr/lib/systemd/system/podheitor-mysql-binlog.service — unidad

del servicio auxiliar CDP (inactiva por defecto)

7.2 EL8 — RPM (variante de build obligatoria)

EL8 tiene una versión más antigua de glibc. Use explícitamente la 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

No instale el RPM EL9 en EL8 — el requisito de glibc no se satisfará y dnf rechazará la transacción.

7.3 Debian 12 — .deb con verificación .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 — receta de compilación

Los builds de Ubuntu siguen la receta de Debian. Para 22.04 y 24.04, el .deb de Debian 12 es compatible en binario en nuestro laboratorio, pero la ruta oficialmente soportada es recompilar desde el código fuente:

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 Red aislada — 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/

El build musl es totalmente static-pie y no tiene dependencia de runtime más allá de la interfaz de syscall del kernel.

7.6 Verificación de firma

Todos los artefactos — RPM, DEB, tarball y SHA256SUMS — están firmados.

Clave GPG maestra: CDEFB0121FA1B478
Subclave de firma: 18A1FFECE956041D

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

Los RPM también llevan una firma embebida verificable con rpm --checksig. Los DEB se distribuyen con un .asc separado junto al paquete.

7.7 Post-instalación

Copie la configuración plantilla:

   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

Cree el archivo de credenciales 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

Agregue la directiva Plugin= al FileSet de Bacula (vea la sección 12

para ejemplos completos).

Reinicie el File Daemon:

   sudo systemctl restart bacula-fd

Confirme que el plugin se cargó:

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

8. Configuración y Dimensionamiento (Mínimo Recomendado)

8.1 Host del File Daemon (donde se ejecuta el plugin)

Componente	Mínimo	Recomendado	Regla de escalado
vCPU	2	4	+1 vCPU por 4 hilos de volcado paralelos
RAM	2 GB	4 GB	+1 GB por paso xtrabackup `--parallel=N`
Disco (staging)	2× mayor BD	3× mayor BD	Aplica al staging de restauración física
Disco (binario + config)	100 MB	100 MB	Fijo; binario de ~20 MB
Red	1 Gbps	10 Gbps	Ver sección 8.4

8.2 Storage Daemon — ancho de banda de red vs tamaño de la BD

Mayor BD individual	Enlace ascendente SD mínimo	Enlace ascendente 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

El Director no es modificado por PodHeitor. Se aplica el dimensionamiento base:

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

8.4 Red FD ↔ SD

Objetivo de throughput de la BD	Recomendación de enlace
Hasta ~300 GB/h	1 Gbps es suficiente
300 GB/h – 1 TB/h	10 Gbps recomendado
> 1 TB/h	10 Gbps + paralelismo de Jobs; 25 Gbps preferible

8.5 El propio servidor MySQL

El plugin se ejecuta en el FD, no dentro del proceso del servidor MySQL. No se impone sobrecarga de CPU, RAM o buffer pool en MySQL más allá del costo normal de la propia operación de backup (FLUSH TABLES WITH READ LOCK, START BACKUP, o semántica de CLONE INSTANCE según corresponda).

Configuración MySQL requerida para PITR y mode=replicate:

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

Para MariaDB, GTID está habilitado por defecto; configure binlog_row_metadata=FULL y asegúrese de que log_bin esté activo.

8.6 Requisitos de Percona XtraBackup

Recurso	Requisito
RAM	≥ 200 MB + 10% de `innodb_buffer_pool_size`
Disco (staging)	2× mayor tablespace para prepare
xbcloud / xbstream	Debe coincidir con la versión mayor de XtraBackup

8.7 Resumen

El plugin es intencionalmente liviano en el FD. La mayoría de las conversaciones de dimensionamiento con clientes se centran en el enlace ascendente del SD, no en el consumo de recursos del plugin.

9. Matriz de Compatibilidad

9.1 Versiones de MySQL y MariaDB

Motor	Versión	Estado	Notas
MySQL	5.7	Soportado (EOL)	Dump + XtraBackup 2.4
MySQL	8.0	Soportado	≥ 8.0.17 para CLONE INSTANCE
MySQL	8.4 LTS	Soportado	Objetivo principal
Percona Server	8.0.x	Soportado	Keyring TDE soportado
MariaDB	10.5	Soportado	mariabackup
MariaDB	10.6 LTS	Soportado	mariabackup
MariaDB	10.11 LTS	Soportado	mariabackup
MariaDB	11.4 LTS	Soportado	Objetivo principal MariaDB

9.2 Motores de backup físico

Motor	Versiones soportadas	Span de versión 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	coincidente con major MariaDB	MariaDB 10.5 / 10.6 / 10.11 / 11.4

9.3 Sistemas operativos

SO	Estado
Oracle Linux 9	Soportado (principal)
RHEL 9	Soportado
Rocky Linux 9	Soportado
AlmaLinux 9	Soportado
Oracle Linux 8	Soportado (variante de build EL8)
RHEL 8	Soportado (variante de build EL8)
Debian 12	Soportado
Ubuntu 22.04 LTS	Soportado (recompilación recomendada)
Ubuntu 24.04 LTS	Soportado (recompilación recomendada)

9.4 Versiones de Bacula

Bacula	Estado
Community 15.0.3	Objetivo principal
Community 13.0.x	Funcionamiento confirmado
Enterprise 16.x	Soportado bajo solicitud
Enterprise 18.2.3	ABI metaplugin compatible

9.5 Sistemas de archivos en el host de la BD

Sistema de archivos	Estado
ext4	Soportado
xfs	Soportado
zfs	Soportado
btrfs	No probado

10. Opciones de Backup — Tabla de Referencia Completa

Parámetro	Predeterminado	Valores permitidos	Descripción
`host`	`localhost`	hostname / IP	Host MySQL al que conectarse.
`port`	`3306`	1–65535	Puerto TCP de MySQL.
`socket`	`/var/lib/mysql/mysql.sock`	ruta	Ruta del socket Unix, si es local.
`extra_file`	(ninguno)	ruta	Archivo estilo my.cnf con credenciales `[client]`. Modo 0640 obligatorio.
`ssl_mode`	`PREFERRED`	`DISABLED`, `PREFERRED`, `REQUIRED`, `VERIFY_CA`, `VERIFY_IDENTITY`	Modo TLS para la conexión MySQL.
`ssl_ca`	(ninguno)	ruta	Paquete CA para verificar el certificado del servidor MySQL.
`mode`	`dump`	`dump`, `xtrabackup`, `mariabackup`, `clone`, `replicate`	Motor de backup principal.
`backup_software`	auto	`mysqldump`, `mysqlpump`, `mariadb-dump`, `xtrabackup`, `mariabackup`	Sustitución de la selección de software.
`database`	(todas)	CSV	Bases de datos a incluir.
`exclude_dbs`	`mysql,sys,performance_schema,information_schema`	CSV	Bases de datos a excluir.
`include_routines`	`true`	`true`, `false`	Incluir stored routines en el volcado.
`include_triggers`	`true`	`true`, `false`	Incluir triggers en el volcado.
`include_events`	`true`	`true`, `false`	Incluir eventos en el volcado.
`compress`	`zstd`	`none`, `gzip`, `lz4`, `zstd`	Compresión del stream.
`compress_level`	`3`	1–19 (dependiente del codec)	Nivel de compresión.
`parallel`	`2`	1–64	Hilos `--parallel` de XtraBackup.
`parallel_dbs`	`1`	1–32	Distribución por base de datos para volcado.
`throttle_iops`	`0`	IOPS entero	XtraBackup `--throttle`. 0 desactiva.
`max_rate_mb`	`0`	entero MB/s	Limita la tasa total del stream. 0 desactiva.
`require_replica`	`false`	`true`, `false`	Abortar si el destino no es una réplica.
`max_replica_lag`	`60`	segundos	Abortar si el retraso de la réplica excede este valor.
`galera_donor_desync`	`false`	`true`, `false`	Desincronizar el nodo donante durante el backup.
`force`	`false`	`true`, `false`	Anular bloqueos de seguridad.
`verify`	`true`	`true`, `false`	Verificar backup tras la captura.
`verify_level`	`quick`	`quick`, `full`	Profundidad de verificación.
`jobs`	`auto`	entero	Jobs paralelos durante restauración/verificación.
`replicate_enabled`	`false`	`true`, `false`	Habilitar aprovisionamiento de réplica de DR en la restauración.
`repl_host`	(ninguno)	hostname	Host MySQL de origen para replicate.
`repl_port`	`3306`	1–65535	Puerto MySQL de origen.
`repl_user`	`replica`	cadena	Usuario de replicación en el origen.
`repl_password_file`	(ninguno)	ruta	Archivo que contiene la contraseña de replicación.
`keyring_path`	(ninguno)	ruta	Archivo de keyring Percona TDE a incluir en el backup físico.
`clone_source_host`	(ninguno)	hostname	Host de origen para MySQL 8 CLONE INSTANCE.
`clone_source_user`	(ninguno)	cadena	Usuario de origen con permisos `BACKUP_ADMIN` y clone.
`clone_source_port`	`3306`	1–65535	Puerto de origen para CLONE INSTANCE.
`clone_ssl_mode`	`REQUIRED`	igual que `ssl_mode`	TLS para la conexión CLONE INSTANCE.
`restore_table`	(ninguno)	`bd.tabla`	Destino de restauración de tabla única por tablespace transportable.
`binlog_mode`	`off`	`off`, `snapshot`, `stream`	Modo de captura binlog CDP.
`binlog_dir`	`/var/lib/mysql`	ruta	Directorio de origen para binlogs.
`binlog_interval_sec`	`60`	≥ 10	Intervalo de polling CDP en modo streaming.
`metrics_dir`	`/opt/bacula/working/mysql-state/metrics`	ruta	Directorio de salida de archivos de texto Prometheus.
`service`	(ninguno)	nombre de unit systemd	Identidad del servicio auxiliar CDP.
`temp_dir`	`/var/tmp/podheitor`	ruta	Directorio de trabajo del plugin.
`log_level`	`info`	`error`, `warn`, `info`, `debug`, `trace`	Nivel de verbosidad del log del plugin.
`log_file`	(ninguno)	ruta	Redirigir logs del plugin a archivo.
`state_dir`	`/opt/bacula/working/mysql-state`	ruta	Almacenamiento de estado LSN y GTID.
`lsn_file`	`state_dir/last.lsn`	ruta	Archivo de estado LSN explícito.
`gtid_file`	`state_dir/last.gtid`	ruta	Archivo de estado GTID explícito.
`pre_backup_hook`	(ninguno)	ruta a ejecutable	Hook pre-backup (ejecutado en el host FD).
`post_backup_hook`	(ninguno)	ruta a ejecutable	Hook post-backup (ejecutado en el host FD).
`abort_on_warning`	`false`	`true`, `false`	Tratar advertencias MySQL como fallo del job.
`retention_hint`	(ninguno)	cadena	Etiqueta de retención consultiva; aparece en métricas.
`dry_run`	`false`	`true`, `false`	Solo planificar, sin transferir datos.

11. Opciones de Restauración — Tabla de Referencia Completa

Parámetro	Predeterminado	Valores permitidos	Descripción
`verify_level`	`quick`	`quick`, `full`	Profundidad de verificación post-restauración.
`jobs`	`auto`	entero	Jobs paralelos xtrabackup `--prepare`.
`replicate_enabled`	`false`	`true`, `false`	Finalizar restauración como réplica activa.
`repl_host`	(ninguno)	hostname	Host de origen de replicación.
`repl_port`	`3306`	1–65535	Puerto de origen de replicación.
`repl_user`	`replica`	cadena	Usuario de replicación.
`repl_password_file`	(ninguno)	ruta	Archivo que contiene la contraseña de replicación.
`restore_table`	(ninguno)	`bd.tabla`	Restaurar solo esta tabla vía tablespace transportable.
`Where=`	(ninguno)	ruta	Ruta de destino estándar de restauración de Bacula.
`Replace=`	`always`	`always`, `ifnewer`, `ifolder`, `never`	Política de reemplazo estándar de Bacula.
`target_datadir`	`/var/lib/mysql`	ruta	Datadir de destino para restauración física.
`start_server`	`false`	`true`, `false`	Iniciar MySQL tras la restauración (el modo replicate lo establece en `true`).
`apply_only`	`false`	`true`, `false`	Detener después de `--prepare`, sin mover el datadir.
`skip_prepare`	`false`	`true`, `false`	No ejecutar xtrabackup `--prepare`.
`gtid_purge`	`auto`	`auto`, `true`, `false`	Aplicar `RESET MASTER; SET GLOBAL gtid_purged` en la restauración vía replicate.

12. Ejemplos de Configuración de FileSet

12.1 Volcado lógico diario de todas las bases de datos

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, solo en 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 con cadena 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á la cadena LSN de state_dir automáticamente.

12.4 Backup de clúster 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 con 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 Aprovisionamiento de recuperación ante 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"
  }
}

# En la restauración, sobreescriba con:
# replicate_enabled=yes
# repl_host=db-primary-01.internal
# repl_user=replica
# repl_password_file=/opt/bacula/etc/mysql-replpw

12.8 FileSet para restauración de tabla única por tablespace transportable

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

# Sustitución en el lado de restauración: 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. Ejemplos de Configuración de Restauración

13.1 Restauración de volcado

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 Restauración completa xtrabackup + rsync de vuelta

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"
}

Pasos del operador tras completar la restauración:

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 Restauración de cadena incremental (JobIds explícitos)

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

El plugin aplica el backup completo en JobId 3212 y el incremental en JobId 3242 en orden, recorriendo la cadena LSN.

13.4 Aprovisionamiento de destino DR vía replicate (receta 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

La restauración termina con MySQL en ejecución en el host de DR y los hilos de replicación iniciados y sincronizados.

14. Informes de Rendimiento

Todos los números de esta sección fueron observados en laboratorio el 2026-04-24 en un clúster de 3 VMs (8 vCPU, 16 GB RAM, NVMe, VXLAN de 10 Gbps entre los nodos). Son representativos, no contractuales.

14.1 Throughput vs tamaño de la BD — `mode=dump`

Tamaño de la BD	Tiempo transcurrido	Throughput efectivo
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	Tiempo transcurrido 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 Tasa de compresión por codec

Codec	Nivel	Tamaño de salida (de 10 GB)	Costo 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%

El nivel zstd 3–6 es el punto óptimo para la mayoría de las cargas de trabajo.

14.4 Tiempo de restauración de cadena incremental vs longitud de la cadena

Cadena	Tiempo de restauración
Solo completo	8 min
Completo + 1 incr	10 min
Completo + 5 incr	16 min
Completo + 20 incr	42 min

14.5 Huella de recursos

Métrica	Valor
Tamaño del binario (glibc, stripped)	21 MB
Tamaño del binario (musl static-pie)	24 MB
RSS durante backup de 10 GB	180 MB
CPU en host FD (zstd-3, parallel=4)	1,3 cores en promedio

14.6 Comparación con el plugin MySQL Bacula Enterprise 18.2.3

Las cifras siguientes son publicadas u observadas, ± 15%.

Métrica	PodHeitor v0.4.1	Bacula Enterprise 18.2.3 (Perl)
Tiempo transcurrido para volcado 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
Huella del binario / runtime	21 MB	Perl + módulos (~80 MB)
Soporte a MySQL 8 CLONE	Sí	Add-on
Aprovisionamiento vía Replicate / DR	Sí	No

15. Evidencia Validada en Producción

Los siguientes JobIds son ejecuciones reales de Jobs de Bacula realizadas durante la validación del release PodHeitor v0.4.1 el 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 transportable (orders)	OK, 3/3 filas restauradas
3485	CLONE INSTANCE	OK, tarball de 3,3 MB catalogado
3592	replicate (aprovisionamiento de DR)	OK, hilos IO+SQL Sí

15.1 JobId 3592 — aprovisionamiento de DR vía 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 en el destino 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

Inmediatamente después de la restauración, un INSERT en vivo en el primario de producción fue observado propagándose a la réplica de DR con latencia sub-segundo.

15.3 JobId 3470 — restauración por tablespace transportable

&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 Seguridad

Artefactos firmados. Los RPM llevan una firma GPG embebida;

los paquetes .deb se distribuyen con un .asc separado; los tarballs se distribuyen con SHA256SUMS.asc.

Claves. Clave maestra CDEFB0121FA1B478; subclave de firma

18A1FFECE956041D.

Cadena de suministro. Cada release se construye bajo cargo audit con

cero CVEs conocidos y cargo deny con política limpia.

Gestión de credenciales. Las contraseñas se leen desde extra_file

(modo 0640, propiedad root:bacula) y nunca se colocan en la línea de comandos o en variables de entorno. El argv y el environ son por tanto seguros de compartir en paquetes de soporte.

Seguridad de la conexión. TLS para MySQL está soportado y recomendado

para conexiones no vía socket; ssl_mode=VERIFY_IDENTITY con un ssl_ca explícito es la configuración reforzada.

Sin requisito de SSH. El plugin no requiere autenticación por clave SSH

para MySQL. Las conexiones locales usan el socket Unix; las remotas usan TLS.

SELinux. El plugin es compatible con SELinux en EL9. Un módulo de política

listo para usar se distribuye en el RPM; semodule -l | grep podheitor confirma la instalación.

Usuario MySQL con privilegio mínimo. Se recomienda un usuario MySQL dedicado bacula_backup

con los permisos mínimos: PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT, BACKUP_ADMIN y, para el modo CLONE, BACKUP_ADMIN + CLONE_ADMIN.

17. Manual Operacional

17.1 Ubicaciones de los logs

Logs del plugin (cuando log_file está configurado): según lo configurado.
De lo contrario, los logs del plugin se multiplexan en el log del File Daemon

bajo un prefijo podheitor-mysql:.

Log del FD: /opt/bacula/working/bacula-fd.log (o journald).

17.2 Archivos de texto Prometheus

Cada Job escribe un archivo .prom en metrics_dir, predeterminado /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 recolectar el mismo directorio.

17.3 Escalando una verificación fallida

Inspeccione el log del Job por el prefijo verify:.
Si verify_level=quick falló, vuelva a ejecutar con verify_level=full.
Si full también falla, preserve el directorio de staging de la restauración y

abra un ticket de soporte con el log del Job y el contenido del directorio de estado.

17.4 Recuperación de cadena rota

Si una cadena xtrabackup incremental está rota (incremental faltante, incompatibilidad de LSN):

Promueva el siguiente backup completo como nueva raíz de la cadena.
Invalide el state_dir/last.lsn obsoleto.
Ejecute un nuevo Job de nivel Full.
Los incrementales subsiguientes se encadenarán desde la nueva raíz.

18. Solución de Problemas — Top-10

#	Síntoma	Solución
1	Plugin no encontrado	Confirme `mysql-fd.so` en `/opt/bacula/plugins`, reinicie bacula-fd.
2	Permiso denegado en `extra_file`	`chmod 640`, `chown root:bacula`.
3	`require_replica=true` falla en primario	Mueva el Job a una réplica o configure `require_replica=false`.
4	Control de flujo Galera se bloquea	Configure `galera_donor_desync=true`.
5	xtrabackup `--prepare` falla	Verifique espacio en disco ≥ 2× mayor tablespace.
6	CLONE INSTANCE «no soportado»	MySQL ≥ 8.0.17 obligatorio; verifique que el plugin `clone` esté cargado.
7	`replicate_enabled=yes` pero réplica no iniciada	Verifique `repl_password_file` y conectividad de red con el origen.
8	Restauración TDE falla	Proporcione `keyring_path` del backup original.
9	PITR con transacciones faltantes	Asegúrese de que `gtid_mode=ON` y `binlog_row_metadata=FULL`.
10	Volcado lento en esquema grande	Aumente `parallel_dbs` y/o cambie a `mode=xtrabackup`.

19. Política de Actualización y Cadencia de Releases

Versionado. SemVer estricto (major.minor.patch).
Releases menores. Aproximadamente cada 3 meses.
Releases de parche. Según sea necesario.
SLA de seguridad. Parches críticos de seguridad publicados en 7 días

tras la confirmación de la vulnerabilidad.

Ventana de soporte. La versión major N-1 se soporta en paralelo con

la versión major actual.

Desaprobación. Las opciones se desaprueban en el release anterior a un

salto de major; la eliminación requiere una frontera de major completa.

20. Precios y Condiciones Comerciales

El precio está basado en la carga de trabajo y no se publica en este whitepaper. Contacte al equipo comercial para una cotización adaptada a su entorno.

Niveles de SLA comercial:

Nivel	Cobertura	SLA de respuesta
Silver	Horario comercial	4 horas
Gold	24×5	1 hora
Platinum	24×7	15 minutos

Todos los niveles incluyen actualizaciones menores y de parche, notas de release y acceso directo a ingeniería para incidentes P1.

21. Licenciamiento

El plugin se distribuye bajo la licencia PodHeitor-Proprietary (single-license, source-available a licenciatarios). Resumen de la licencia (no autoritativo; vea LICENSE para términos autoritativos):

Puede usar, modificar y redistribuir el código fuente.
Si modifica el plugin y lo ejecuta para proporcionar un servicio de red,

debe poner el código fuente modificado a disposición de los usuarios de ese servicio.

Las obras derivadas requieren un acuerdo de licenciamiento separado.

Implicación para implementadores SaaS. Si ejecuta PodHeitor como parte de una oferta multi-inquilino de backup-como-servicio, el acceso al código fuente está sujeto a NDA al plugin. Para implementadores cuyo modelo de negocio es incompatible con esa obligación, ofrecemos relicenciamiento comercial en términos estándar y negociados.

Para consultar sobre relicenciamiento, escriba a heitor@opentechs.lat.

22. Conclusión y Llamada a la Acción

PodHeitor MySQL/MariaDB Backup and Replication Plugin for Bacula v0.4.1 entrega backup, restauración y aprovisionamiento de réplica de DR de nivel empresarial para MySQL y MariaDB en un único binario Rust, bajo licenciamiento PodHeitor-Proprietary, a un precio deliberadamente por debajo de los cuatro incumbentes dominantes. Está validado en producción en las ejecuciones de laboratorio del 2026-04-24, incluyendo el aprovisionamiento de réplica de DR en vivo del JobId 3592 con hilos de IO y SQL en ejecución y cero segundos de retraso respecto al origen.

Tráiganos su contrato vigente o cotización de renovación de Bacula Enterprise, Veeam, Commvault o NetBackup — igualamos la lista de funcionalidades y garantizamos un mínimo de 50% de descuento, con muchas capacidades adicionales incluidas.

Inicie la conversación hoy:

Correo: heitor@opentechs.lat
Teléfono: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

23. Página de Contacto

PodHeitor / OpenTechs Fundador: Heitor Faria

Correo: heitor@opentechs.lat
Teléfono: +1 (786) 726-1749
WhatsApp: +55 (61) 98268-4220

Para ventas, evaluaciones técnicas, relicenciamiento comercial, cotizaciones de niveles de soporte y documentación de compras, utilice cualquiera de los canales anteriores. Respondemos en un día hábil para consultas del nivel Silver y en una hora para Gold y Platinum.

24. Apéndice A — Glosario

CDP (Protección Continua de Datos). Una estrategia de backup en la que

cada transacción confirmada se captura, típicamente vía streaming de binlog, habilitando recuperación point-in-time con RPO cercano a cero.

GTID (Identificador Global de Transacción). Un identificador de replicación MySQL/MariaDB

que etiqueta exclusivamente cada transacción y permite el posicionamiento determinístico de réplicas.

LSN (Número de Secuencia de Log). El marcador de posición monotónico del redo-log de InnoDB;

usado por XtraBackup para calcular deltas incrementales.

PTCOMM. El protocolo de comunicación plugin-a-plugin de Bacula

entre el File Daemon y un backend metaplugin.

xbstream. El formato de archivo de streaming de Percona XtraBackup.
TDE (Cifrado Transparente de Datos). Cifrado en reposo de

tablespaces InnoDB, con un keyring separado de los datos.

Galera. Una biblioteca de replicación multi-master síncrona para

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

Donor desync. Un modo de operación Galera que permite que un nodo

actúe como donante de State Snapshot Transfer sin aplicar control de flujo al clúster.

CLONE INSTANCE. La funcionalidad nativa de MySQL 8 para clonar remotamente

una instancia completa vía conexión de protocolo MySQL.

Tablespace transportable. Una capacidad de InnoDB que permite que el

tablespace de una sola tabla sea exportado, transportado e importado a otra instancia.

Pool FIFO. Un pool de almacenamiento de Bacula respaldado por un dispositivo FIFO,

típicamente usado para cargas de trabajo de streaming/CDP.

SD. Bacula Storage Daemon.
FD. Bacula File Daemon.
DIR. Bacula Director.
RPO (Objetivo de Punto de Recuperación). La pérdida de datos máxima aceptable

medida en tiempo.

RTO (Objetivo de Tiempo de Recuperación). El tiempo de inactividad máximo aceptable

medido en tiempo.

24.1 Notas Extendidas del Glosario

Las siguientes notas expandidas acompañan el glosario resumido en la sección 24 y están dirigidas a lectores que son nuevos en uno o más de los conceptos referenciados a lo largo de este whitepaper.

Sobre la replicación basada en GTID. La replicación MySQL tradicional rastrea la posición de la réplica como una tupla (archivo de binlog, offset de binlog). La replicación basada en GTID, en cambio, rastrea el conjunto de transacciones que la réplica ya ha aplicado, por identificador globalmente único. Este cambio importa para PodHeitor porque la funcionalidad mode=replicate usa GTIDs para posicionar con precisión la réplica de DR recién aprovisionada, independientemente de cuántas rotaciones de binlog hayan ocurrido en el origen desde que se tomó el backup. Sin GTIDs, una restauración de DR tendría que rederivó la posición desde coordenadas de binlog, lo cual es frágil ante cambios de topología.

Sobre LSN y la corrección incremental. El LSN de InnoDB es una posición monotónica del redo-log. Percona XtraBackup usa la marca de agua LSN capturada al final de un backup completo (o incremental previo) para escanear solo las páginas de tablespace modificadas desde ese punto. PodHeitor persiste esta marca de agua en state_dir/last.lsn y la expone a través de métricas Prometheus para que los operadores puedan detectar desvíos en la cadena antes de que se requiera una restauración.

Sobre xbstream y la corrección del streaming. A diferencia de un archivo tar, el formato xbstream está diseñado para el streaming intercalado de archivos que se están escribiendo activamente durante la captura. PodHeitor consume el xbstream directamente del stdout de XtraBackup y lo reenvía cuadro a cuadro vía PTCOMM al File Daemon, de modo que el plugin nunca necesita materializar todo el stream en disco local.

Sobre el cálculo del RPO con CDP. Con binlog_interval_sec=60, el RPO teórico del peor caso es un intervalo más la latencia de confirmación y vaciado de la instancia MySQL. En la práctica, las pruebas en el clúster de laboratorio del 2026-04-24 observaron RPOs en el rango de 45 a 80 segundos. Ajustar el intervalo a la baja reduce el RPO al costo de mayor rotación del catálogo; relajarlo produce el efecto inverso.

Sobre los tablespaces transportables. Esta es una capacidad de InnoDB, no una funcionalidad del servidor MySQL per se. Depende de que los archivos .ibd y .cfg sean copiables entre instancias que comparten la misma versión, formato de fila y tamaño de página. La opción restore_table de PodHeitor automatiza la secuencia DISCARD/IMPORT, pero la restricción subyacente de compatibilidad de versión del motor sigue aplicando.

Sobre el donor desync de Galera. En un clúster Galera, un SST (State Snapshot Transfer) en ejecución normalmente aplica control de flujo a todo el clúster porque el donante debe mantenerse consistente. Configurar wsrep_desync=ON desacopla temporalmente al donante del control de flujo, permitiendo backups de larga duración sin bloquear el clúster. La contrapartida es que el donante se pondrá al día posteriormente; PodHeitor monitorea esta puesta al día post-backup y expone el retraso en métricas.

Sobre el keyring Percona TDE. El archivo de keyring (keyring_file o keyring_vault) es ortogonal a los archivos de datos. Un backup físico sin el keyring es criptográficamente inútil. La opción keyring_path de PodHeitor asegura que el keyring viaje con el backup a través del mismo stream, retención y superficie de control de acceso de Bacula.

25. Apéndice B — Referencias

Documentación de Bacula Community Edition — consulte la documentación oficial del proyecto

Bacula Community.

Documentación de Bacula Enterprise Edition — consulte la documentación oficial del

proveedor Bacula Systems.

Documentación de Percona XtraBackup — consulte la documentación oficial del

proveedor Percona.

Documentación de replicación MySQL — consulte la documentación oficial del

proveedor Oracle MySQL.

Documentación de backup y replicación de MariaDB — consulte la documentación oficial de

MariaDB Foundation / MariaDB plc.

Documentación de Galera Cluster — consulte la documentación oficial del

proveedor Codership.

Documentación de units de servicio systemd — consulte la documentación oficial del

proyecto systemd.

Texto de la licencia PodHeitor-Proprietary — vea archivo LICENSE entregado con cada release.

Free Software Foundation.

Ninguna URL de terceros se reproduce en este whitepaper; consulte directamente los sitios oficiales de los proveedores.

Disponível em: Português (Portugués, Brasil)English (Inglés)Español

Tabla de Contenidos

1. Portada

2. Resumen Ejecutivo

3. Planteamiento del Problema

3.1 El desafío moderno del backup MySQL/MariaDB

3.2 Por qué las soluciones actuales se quedan cortas

3.3 La brecha que PodHeitor cierra

4. Descripción General del Producto

4.1 En resumen

4.2 La afirmación de paridad 48/48

4.3 Arquitectura de binario único

4.4 Ventaja source-available + comercial

5. Casos de Uso

5.1 MySQL 8 OLTP de misión crítica en Oracle Linux 9

5.2 MariaDB 11.4 para cargas de trabajo ERP / ECM

5.3 Clúster Galera de 3 nodos en HA

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

5.5 CDP (Protección Continua de Datos) para cargas de trabajo financieras

5.6 SaaS multi-inquilino con programación por base de datos

5.7 InnoDB cifrado por TDE en Percona

5.8 Restauración rápida de tabla única vía tablespaces transportables

6. Arquitectura

6.1 Componentes

6.2 Flujo de datos — backup

6.3 Flujo de datos — replicate (aprovisionamiento de DR)

6.4 Cadena de LSN incremental

6.5 Invariantes arquitectónicos

7. Procedimiento de Instalación

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

7.2 EL8 — RPM (variante de build obligatoria)

7.3 Debian 12 — .deb con verificación .asc separada

7.4 Ubuntu 22.04 / 24.04 — receta de compilación

7.5 Red aislada — tarball musl static-pie

7.6 Verificación de firma

7.7 Post-instalación

8. Configuración y Dimensionamiento (Mínimo Recomendado)

8.1 Host del File Daemon (donde se ejecuta el plugin)

8.2 Storage Daemon — ancho de banda de red vs tamaño de la BD

8.3 Director

8.4 Red FD ↔ SD

8.5 El propio servidor MySQL

8.6 Requisitos de Percona XtraBackup

8.7 Resumen

9. Matriz de Compatibilidad

9.1 Versiones de MySQL y MariaDB

9.2 Motores de backup físico

9.3 Sistemas operativos

9.4 Versiones de Bacula

9.5 Sistemas de archivos en el host de la BD

10. Opciones de Backup — Tabla de Referencia Completa

11. Opciones de Restauración — Tabla de Referencia Completa

12. Ejemplos de Configuración de FileSet

12.1 Volcado lógico diario de todas las bases de datos

12.2 xtrabackup físico semanal, solo en réplica

12.3 xtrabackup incremental con cadena LSN

12.4 Backup de clúster Galera (donor desync)

12.5 MariaDB con mariabackup

12.6 MySQL 8 CLONE INSTANCE (agentless)

12.7 Aprovisionamiento de recuperación ante desastres (replicate)

12.8 FileSet para restauración de tabla única por tablespace transportable

12.9 Sidecar binlog CDP + pool FIFO

13. Ejemplos de Configuración de Restauración

13.1 Restauración de volcado

13.2 Restauración completa xtrabackup + rsync de vuelta

13.3 Restauración de cadena incremental (JobIds explícitos)

13.4 Aprovisionamiento de destino DR vía replicate (receta JobId 3592)

14. Informes de Rendimiento

14.1 Throughput vs tamaño de la BD — mode=dump

14.2 Throughput para mode=xtrabackup vs parallel

14.3 Tasa de compresión por codec

14.4 Tiempo de restauración de cadena incremental vs longitud de la cadena

14.5 Huella de recursos

14.6 Comparación con el plugin MySQL Bacula Enterprise 18.2.3

15. Evidencia Validada en Producción

15.1 JobId 3592 — aprovisionamiento de DR vía replicate

15.2 SHOW REPLICA STATUS en el destino de DR

15.3 JobId 3470 — restauración por tablespace transportable

15.4 JobId 3485 — CLONE INSTANCE

16. Modelo de Seguridad

17. Manual Operacional

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

14.1 Throughput vs tamaño de la BD — `mode=dump`

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