Blog

Whitepaper — PodHeitor Firebird

Whitepaper — PodHeitor Firebird

Respaldo corporativo para Firebird, sin ventana nocturna. Multi-versión (2.5, 3.0, 4.0, 5.0), respaldo online vía nbackup, restauración rápida sin reconstrucción de índices.

  • Respaldo online nativo vía nbackup — sin pausa, sin lock global.
  • Incrementales multi-nivel — full mensual, diferenciales diarios, deltas transaccionales.
  • Restauración delta-merge automática — recupere a un punto exacto sin replay manual.
  • Compatible Firebird 2.5 → 5.x — mismo plugin, misma sintaxis, sin refactor.
  • Validación automática — gfix post-respaldo, alerta de corrupción.

Producción en 30 días, al menos 50% más barato. Trial gratuito, RPMs y DEBs firmados, soporte directo con Heitor Faria. Reemplace su licencia Veeam, Commvault o Bacula Enterprise sin romper la ventana nocturna.

Solicitar trial gratuito de 30 días →

Tabla de contenidos

  1. Resumen ejecutivo
  2. Introducción y contexto de mercado
  3. Descripción general de la arquitectura
  4. Análisis detallado de los modos de backup
  5. Matriz de funcionalidades
  6. Guía de instalación
  7. Referencia de configuración
  8. Ejemplos de FileSet
  9. Dimensionamiento y planificación de capacidad
  10. Informe de rendimiento
  11. Matriz de compatibilidad
  12. Seguridad
  13. Monitoreo
  14. Guía de resolución de problemas
  15. Casos de uso y escenarios de implementación
  16. Comparación con otros enfoques
  17. Hoja de ruta
  18. Conclusión
  19. Información de contacto
  20. Legal / derechos de autor

1. Resumen ejecutivo

Firebird es una base de datos relacional madura y de código abierto, ampliamente utilizada en sistemas ERP, aplicaciones de punto de venta, productos embebidos y aplicaciones empresariales — con una adopción especialmente alta en América Latina, Europa del Este y Asia. A pesar de esta presencia, Firebird ha carecido históricamente de una integración de backup de primera clase con el ecosistema de backup de código abierto. Los administradores se han visto obligados a elegir entre scripts shell artesanales que envuelven gbak, plugins de pago de proveedores comerciales de backup, o aceptar fallos silenciosos de backup sin ninguna capa de verificación.

El PodHeitor Firebird Backup Plugin for Bacula cierra esta brecha. Ofrece un plugin nativo en Rust, de grado productivo, para PodHeitor Backup+ que se integra de forma nativa con Firebird 3.0, 4.0 y 5.0. Tres modos de backup distintos cubren cada escenario operativo: volcado lógico (dump) mediante gbak, cadenas incrementales a nivel de página nativas con nbackup, y log shipping con replay para replicación con RPO casi nulo. Todos los modos se gestionan a través de la configuración estándar de Jobs y FileSets de Bacula — sin scripts externos, sin pegamento cron, sin demonios personalizados.

Desde una perspectiva de negocio, el plugin extiende PodHeitor Backup con capacidades de DR de Firebird de grado empresarial a una fracción del costo de las alternativas comerciales premium. Las pruebas de validación a través de 8 fases y 120 casos de prueba automatizados han confirmado precisión de restauración idéntica byte a byte, throughput paralelo multi-BD (aceleración de 5,6×), compresión zstd (relación en línea del 21,4%) y una desviación de limitación de ancho de banda inferior al 1%. Para cualquier organización que ejecute Firebird en Linux con PodHeitor Backup, este plugin representa el camino más completo y rentable hacia una postura de backup sólida y auditable.

2. Introducción y contexto de mercado

2.1 Firebird en producción hoy

Firebird sigue siendo la base de datos de elección para millones de aplicaciones instaladas en todo el mundo. Impulsa importantes plataformas ERP en América Latina (Totvs Protheus y similares), sistemas de pólizas de seguros, gestión logística e inventarios, y dispositivos industriales embebidos. Las características clave que explican su adopción continua incluyen:

  • Licenciamiento sin costo, sin tarifas por asiento ni por núcleo
  • Páginas autogestionadas, sin necesidad de un DBA para la operación rutinaria
  • Control de versiones ODS (On-Disk Structure) que permite migraciones limpias entre versiones mayores
  • Arquitectura multigeneracional que ofrece lecturas consistentes sin bloqueo de escritura
  • Huella de memoria extremadamente baja — las instancias de Firebird en producción frecuentemente operan con menos de 256 MB de RAM

Estas mismas características que hacen atractivo a Firebird también crean desafíos de backup. La base de datos no implementa un flujo WAL (Write-Ahead Log) consumible por herramientas genéricas de log shipping. Su formato en disco varía según la versión ODS (ODS 11 para FB 3, ODS 12 para FB 4, ODS 13 para FB 5). Las herramientas de backup nativas — gbak para volcados lógicos y nbackup para backups a nivel de página — existen y son robustas, pero hablan protocolos propietarios que ninguna plataforma de backup de código abierto estándar había integrado hasta ahora.

2.2 Por qué los enfoques existentes son insuficientes

Herramienta Soporte para Firebird Veredicto
PodHeitor Backup (nativo, sin plugin) Solo a nivel de archivo — respalda el archivo .fdb en bruto mientras la BD está activa Inseguro — riesgo de corrupción de datos si la BD está ocupada
Veeam Sin agente nativo para Firebird Requiere scripts de quiesce a nivel de SO; sin verificación del motor de backup
Commvault Sin iDataAgent nativo para Firebird Solo integración mediante scripts personalizados
Amanda / Bareos Solo a nivel de archivo Mismo riesgo que el backup de archivos nativo de PodHeitor Backup
Scripts shell personalizados Poco confiables, sin reintentos, sin monitoreo, sin catálogo No apto para producción

La brecha es evidente: hasta ahora, ninguna solución de backup compatible con código abierto se integraba con Firebird a nivel del motor. El plugin de PodHeitor cubre esta brecha.

2.3 El enfoque de PodHeitor

El plugin sigue la misma filosofía de diseño que el resto de la familia de plugins PodHeitor: implementación nativa en Rust, desarrollo por fases con pruebas de regresión automatizadas, cero dependencias en tiempo de ejecución más allá de las herramientas propias de la base de datos objetivo, y una arquitectura modular que garantiza aislamiento de procesos y estabilidad ante cambios de versión de Bacula.

3. Descripción general de la arquitectura

3.1 Diseño de dos componentes

El plugin está compuesto por dos binarios que se distribuyen en el mismo paquete:

Componente Archivo Función
Plugin FD de Bacula /opt/bacula/plugins/podheitor-firebird-fd.so Cargado por bacula-fd en tiempo de ejecución; implementa la API de plugins de Bacula
Binario backend /opt/bacula/bin/podheitor-firebird-backend Ejecutado como proceso hijo por el plugin FD en cada job; realiza toda la interacción con Firebird

Esta separación es intencional y ofrece tres ventajas clave:

  1. Aislamiento. El componente plugin es mínimo y estable. Toda la lógica que interactúa con las herramientas de Firebird (gbak, nbackup, gfix, Services API) reside en el backend. Un fallo o bloqueo en el backend no puede corromper el proceso bacula-fd.
  2. Actualización independiente. El backend puede actualizarse sin reiniciar bacula-fd. El componente plugin mantiene compatibilidad con el ABI del plugin de Bacula.
  3. Capacidad de prueba. El binario backend puede ejecutarse directamente en pruebas de integración sin involucrar a Bacula en absoluto.

3.2 Diagrama de arquitectura

  ┌─────────────────────────────────────────────────────────────┐
  │  Bacula File Daemon (bacula-fd)                              │
  │                                                             │
  │   ┌─────────────────────────────────────────────────────┐   │
  │   │  podheitor-firebird-fd.so  (plugin FD)               │   │
  │   │                                                     │   │
  │   │  JobStart ──► fork backend ──► write job opts        │   │
  │   │  BackupCommand ──► send backup request              │   │
  │   │  GetMoreData ◄── receive backup chunk               │   │
  │   │  EndBackupJob ──► read backup complete              │   │
  │   │  RestoreCommand ──► send restore request            │   │
  │   │  SetFileAttributes ◄── write restored file          │   │
  │   └───────────────────────┬─────────────────────────────┘   │
  │                           │ stdin/stdout (canal interno)     │
  │   ┌───────────────────────▼─────────────────────────────┐   │
  │   │  podheitor-firebird-backend  (subprocess)            │   │
  │   │                                                     │   │
  │   │  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │   │
  │   │  │ DumpMode │  │NbackupMod│  │  ReplayMode      │  │   │
  │   │  │  (gbak)  │  │(nbackup) │  │ (gbak+log ship)  │  │   │
  │   │  └────┬─────┘  └────┬─────┘  └────────┬─────────┘  │   │
  │   │       │              │                  │            │   │
  │   │  ┌────▼──────────────▼──────────────────▼────────┐  │   │
  │   │  │  Firebird Engine (gbak / nbackup / gfix /      │  │   │
  │   │  │  Services API / Embedded)                      │  │   │
  │   │  └────────────────────────────────────────────────┘  │   │
  │   │                                                     │   │
  │   │  State dir: /opt/bacula/working/firebird-state/     │   │
  │   │  Config:    /opt/bacula/etc/podheitor-firebird.conf  │   │
  │   └─────────────────────────────────────────────────────┘   │
  └─────────────────────────────────────────────────────────────┘
                         │
                         │ Bacula protocol (TCP)
                         ▼
               ┌──────────────────┐
               │  Bacula Storage  │
               │  Daemon (bacula- │
               │  sd) + Catalog   │
               └──────────────────┘

3.3 Gestión de estado

El modo nbackup requiere estado persistente para rastrear qué niveles de cadena incremental han sido completados. Este estado se almacena en /opt/bacula/working/firebird-state/ como archivos de manifiesto JSON por base de datos:

/opt/bacula/working/firebird-state/
  ├── prod.fdb.chain.json          # nbackup chain manifest
  ├── employee.fdb.chain.json
  └── inventory.fdb.chain.json

Cada manifiesto registra:

{
  "db_path": "/var/firebird/prod.fdb",
  "chain": [
    { "level": 0, "job_id": 100, "size": 1048576, "checksum": "sha256:...", "timestamp": "2026-05-01T02:00:00Z" },
    { "level": 1, "job_id": 101, "size": 204800,  "checksum": "sha256:...", "timestamp": "2026-05-02T02:00:00Z" }
  ]
}

4. Análisis detallado de los modos de backup

4.1 Modo dump — volcado lógico con gbak

Cómo funciona

El modo dump invoca la utilidad gbak de Firebird para producir un backup lógico portátil. gbak se conecta al servidor de Firebird (o al motor embebido), lee todas las páginas de datos en una instantánea consistente y escribe un flujo .fbk independiente de la plataforma. El plugin captura este flujo, opcionalmente lo comprime y lo envía a Bacula como un único objeto de archivo virtual.

  Firebird DB  ──►  gbak  ──►  stdout stream  ──►  (zstd compress)  ──►  flujo interno  ──►  Bacula

Se pueden especificar trabajadores paralelos (workers=N) para respaldar múltiples bases de datos simultáneamente dentro de un único job de Bacula.

Cuándo usar

  • Backups completos nocturnos de bases de datos pequeñas a medianas (< 50 GB sin comprimir)
  • Migración entre versiones (el formato .fbk de gbak es portátil entre versiones ODS de FB 3/4/5)
  • Cualquier escenario que requiera consistencia lógica por sobre la fidelidad exacta de páginas
  • Recuperación ante desastres donde se requiere un backup limpio e importable sin dependencias de cadena

Ventajas y desventajas

Aspecto Evaluación
Portabilidad Excelente — .fbk se restaura en cualquier versión de FB
Consistencia Excelente — gbak toma una instantánea consistente
Velocidad Moderada — lee todas las páginas secuencialmente
Tamaño Moderado — datos lógicos; la compresión zstd ayuda
Dependencia de cadena Ninguna — cada backup es autónomo
Simplicidad de restauración Excelente — una sola invocación de gbak -r
Aptitud para BD grandes Moderada — el tiempo de backup completo crece linealmente con el tamaño de la BD
Soporte paralelo Sí — múltiples BDs en un solo job

4.2 Modo nbackup — cadena incremental nativa a nivel de página

Cómo funciona

El modo nbackup utiliza la función de backup a nivel de página integrada en Firebird. Opera en cuatro niveles (L0 a L3):

  • Nivel 0 (L0): instantánea completa a nivel de página de la base de datos
  • Nivel 1 (L1): páginas modificadas desde el último L0
  • Nivel 2 (L2): páginas modificadas desde el último L1
  • Nivel 3 (L3): páginas modificadas desde el último L2

Firebird rastrea las páginas modificadas internamente mediante un mecanismo de archivo de diferencias. El plugin gestiona el manifiesto de cadena, invoca nbackup -b <nivel> para el nivel apropiado y registra el resultado. En la restauración, el plugin combina la cadena usando nbackup -r en orden estricto de niveles (L0 → L1 → L2 → L3).

  Day 1:  nbackup -b 0 ──► L0.nbk  (full page snapshot)
  Day 2:  nbackup -b 1 ──► L1.nbk  (delta from L0)
  Day 3:  nbackup -b 2 ──► L2.nbk  (delta from L1)
  Day 4:  nbackup -b 3 ──► L3.nbk  (delta from L2)
  Day 5:  nbackup -b 0 ──► new L0  (chain resets)

Cuándo usar

  • Bases de datos grandes donde un gbak completo cada noche es demasiado lento o voluminoso
  • Entornos con ventanas RTO/RPO definidas que se benefician de cadenas incrementales
  • Cuando el presupuesto de disco o ancho de banda es limitado
  • Cuando la base de datos está en el mismo host o es accesible mediante la Services API

Ventajas y desventajas

Aspecto Evaluación
Portabilidad Baja — específica de ODS; se debe restaurar en la misma versión mayor de Firebird
Consistencia Excelente — Firebird garantiza consistencia a nivel de página
Velocidad Excelente — L1/L2/L3 respaldan solo las páginas modificadas
Tamaño Excelente — los deltas incrementales son pequeños
Dependencia de cadena Requerida — la restauración necesita la cadena completa L0→Ln
Simplicidad de restauración Moderada — se debe restaurar en orden de cadena
Aptitud para BD grandes Excelente — la cadena incremental escala a BDs de múltiples GB
Soporte paralelo Por nivel, por BD

4.3 Modo replay — baseline con gbak + log shipping de journal

Cómo funciona

El modo replay implementa una estrategia en dos niveles:

  1. Baseline. Se toma periódicamente un volcado lógico completo con gbak (configurable).
  2. Segmentos de journal. Los archivos de journal de replicación de Firebird producidos por el subsistema de replicación (FB 4+) se recopilan desde replay_log_dir, se envían a Bacula y, en la restauración, se depositan en replay_dest_dir para su aplicación.

Este patrón refleja el enfoque de WAL-shipping utilizado en la replicación en flujo de PostgreSQL, adaptado al mecanismo de journal de Firebird.

  Firebird (primary)
    ├── gbak baseline ──────────────────────────────────────────► Bacula catalog
    └── journal segments (repllog.*.journal) ──► flujo interno ──► Bacula catalog

  Restore:
    gbak -r baseline ──► fresh DB ──► apply journal segments ──► consistent standby

Cuándo usar

  • Requerimientos de RPO casi nulo donde las cadenas incrementales nbackup aún resultan demasiado gruesas
  • Escenarios de replicación en espera y DR
  • Instalaciones de Firebird 4.0 y 5.0 con replicación ya habilitada
  • DR multi-sitio donde los journals se pueden aplicar en un nodo en espera remoto

Ventajas y desventajas

Aspecto Evaluación
RPO Excelente — sub-minuto con envío frecuente de journals
Portabilidad Moderada — el baseline es portátil; los journals son específicos de versión
Consistencia Excelente — los journals son segmentos atómicos
Complejidad de configuración Alta — requiere que la replicación de Firebird esté configurada
Complejidad de restauración Moderada — el replay requiere aplicación ordenada de journals
Aptitud para BD grandes Excelente — los journals son pequeños independientemente del tamaño de la BD
Versión de FB requerida Replicación disponible en FB 4.0+

5. Matriz de funcionalidades

Funcionalidad dump nbackup replay
Backup completo Sí Sí (L0) Sí (baseline)
Backup incremental No Sí (L1/L2/L3) Sí (journals)
Compresión zstd Sí Sí Sí
Compresión lz4 Sí Sí Sí
Limitación de ancho de banda Sí Sí Sí
Trabajadores paralelos Sí No No
Multi-BD por job Sí Sí Sí
Restauración entre versiones Sí No Parcial
Services API Sí Sí Sí
Firebird Embedded Sí Sí No
gfix post-restauración Sí Sí No
Contraseña de cifrado Sí Sí Sí
Métricas Prometheus Sí Sí Sí
Gestión de estado de cadena No Sí No
CLI gc-chain No Sí No
Restauración idéntica byte a byte Sí Sí Sí
Paquete RPM Sí Sí Sí
Paquete DEB Sí Sí Sí
Soporte FB 3.0 Sí Sí No
Soporte FB 4.0 Sí Sí Sí
Soporte FB 5.0 Sí Sí Sí
Trabajadores paralelos gbak (FB 5) Sí No No
Log shipping de journal No No Sí
RPO casi nulo No Bajo Sí

6. Guía de instalación

6.1 Prerequisitos

  • PodHeitor Backup o posterior instalado con bacula-fd en ejecución
  • Servidor Firebird 3.0, 4.0 o 5.0 (o embebido) instalado
  • Los binarios gbak y nbackup deben estar en $PATH (o con rutas completas especificadas en la configuración del plugin)
  • SO: RHEL/OL/Rocky 9+ o Ubuntu 22.04+/Debian 12+
  • glibc 2.34+
  • El usuario bacula debe existir y tener acceso de lectura a los archivos de base de datos de Firebird

6.2 Instalación con RPM (EL9 / OL9 / RHEL9 / Rocky 9)

# 1. Install the RPM
dnf install podheitor-firebird-0.1.0-1.el9.x86_64.rpm

# 2. Verify files are in place
ls -la /opt/bacula/plugins/podheitor-firebird-fd.so
ls -la /opt/bacula/bin/podheitor-firebird-backend

# 3. Check state directory was created
ls -la /opt/bacula/working/firebird-state/

# 4. Restart bacula-fd to load the new plugin
systemctl restart bacula-fd

# 5. Confirm plugin loaded (look for "podheitor-firebird" in log)
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor

6.3 Instalación con DEB (Ubuntu 22.04 / Debian 12)

# 1. Install the DEB
apt install ./podheitor-firebird_0.1.0-1_amd64.deb

# 2. Verify files are in place
ls -la /opt/bacula/plugins/podheitor-firebird-fd.so
ls -la /opt/bacula/bin/podheitor-firebird-backend

# 3. Check state directory was created
ls -la /opt/bacula/working/firebird-state/

# 4. Restart bacula-fd
systemctl restart bacula-fd

# 5. Confirm plugin loaded
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor

6.4 Configuración de credenciales

El plugin lee la contraseña de Firebird desde un archivo de credenciales para evitar incrustar contraseñas en la configuración de Bacula:

# Create the credentials file
cat > /opt/bacula/etc/.fbpass << 'EOF'
SYSDBA=masterkey
EOF

# Secure it
chown bacula:bacula /opt/bacula/etc/.fbpass
chmod 600 /opt/bacula/etc/.fbpass

6.5 Archivo de configuración del plugin

Cree /opt/bacula/etc/podheitor-firebird.conf:

# PodHeitor Firebird Plugin configuration
[defaults]
fb_user        = "SYSDBA"
fb_host        = "localhost"
fb_port        = 3050
compress       = "zstd"
compress_level = 3
state_dir      = "/opt/bacula/working/firebird-state"

[credentials]
password_file = "/opt/bacula/etc/.fbpass"

6.6 Verificación de la instalación

Ejecute un backup de prueba usando bconsole:

*run job=FB-Test-Dump level=Full yes

Resultado esperado: estado del job T (terminado normalmente) con un valor de bytes escritos distinto de cero.

7. Referencia de configuración

7.1 Parámetros de backup (cadena Plugin de FileSet)

Parámetro Valor por defecto Descripción
db (requerido) Ruta(s) de la base de datos, separadas por comas
mode dump Modo de backup: dump / nbackup / replay
level 0 Nivel de nbackup (0–3)
workers 1 Trabajadores de backup paralelos (modo dump)
compress zstd Códec de compresión: zstd / lz4 / none
compress_level 3 Nivel de compresión zstd (1–22)
bw_limit_kbps 0 Límite de ancho de banda en KB/s; 0 = sin límite
gbak_path gbak Ruta completa al binario gbak (si no está en $PATH)
nbackup_path nbackup Ruta completa al binario nbackup (si no está en $PATH)
fb_user SYSDBA Nombre de usuario de Firebird
fb_password (desde .fbpass) Contraseña de Firebird (se prefiere el archivo .fbpass)
fb_host localhost Nombre de host o IP del servidor Firebird
fb_port 3050 Puerto TCP del servidor Firebird
services_api false Usar conexión mediante Services API (-se)
embedded false Usar Firebird Embedded (no requiere servidor)
replay_log_dir (vacío) Directorio de origen de los archivos de journal de replicación
replay_dest_dir (vacío) Destino de restauración para los archivos de journal
encrypt_passphrase (vacío) Contraseña de cifrado (passthrough de argv a gbak)
metrics_listen (vacío) Dirección de enlace para métricas Prometheus (ej. 0.0.0.0:9182); vacío = desactivado
state_dir /opt/bacula/working/firebird-state Directorio de estado para los manifiestos de cadena nbackup

7.2 Parámetros de restauración (cadena Plugin del Job de restauración)

Parámetro Valor por defecto Descripción
restore_path (requerido) Ruta del sistema de archivos de destino para la base de datos restaurada
mode (del backup) Debe coincidir con el modo de backup utilizado
fb_user SYSDBA Usuario de Firebird para operaciones de restauración
fb_password (desde .fbpass) Contraseña de Firebird
fix_shadow true Ejecutar gfix -sh tras la restauración para limpiar archivos shadow
replay_dest_dir (vacío) Directorio donde depositar los segmentos de journal restaurados

8. Ejemplos de FileSet

8.1 Volcado lógico completo

# Full logical dump backup (gbak mode)
FileSet {
  Name = "FB-Dump-Full"
  Include {
    Plugin = "podheitor-firebird: db=/var/firebird/employee.fdb mode=dump compress=zstd workers=2"
  }
}

8.2 Cadena incremental con nbackup

# Level 0 (run weekly or monthly)
FileSet {
  Name = "FB-Nbackup-L0"
  Include {
    Plugin = "podheitor-firebird: db=/var/firebird/prod.fdb mode=nbackup level=0"
  }
}

# Level 1 (run nightly)
FileSet {
  Name = "FB-Nbackup-L1"
  Include {
    Plugin = "podheitor-firebird: db=/var/firebird/prod.fdb mode=nbackup level=1"
  }
}

8.3 Log shipping de journal de replicación

# Replay / journal log shipping
FileSet {
  Name = "FB-Replay-Incr"
  Include {
    Plugin = "podheitor-firebird: db=/var/firebird/prod.fdb mode=replay replay_log_dir=/var/firebird/replay/prod"
  }
}

8.4 Backup paralelo de múltiples bases de datos

# Four databases backed up in parallel with bandwidth cap
FileSet {
  Name = "FB-MultiDB"
  Include {
    Plugin = "podheitor-firebird: db=/var/firebird/db1.fdb,/var/firebird/db2.fdb,/var/firebird/db3.fdb,/var/firebird/db4.fdb mode=dump workers=4 compress=zstd bw_limit_kbps=51200"
  }
}

8.5 Ejemplo de job de restauración

Job {
  Name = "FB-Restore-Employee"
  Type = Restore
  Client = firebird-fd
  FileSet = "FB-Dump-Full"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /tmp/restore
  Plugin = "podheitor-firebird: mode=dump restore_path=/var/firebird/employee-restored.fdb fix_shadow=true"
}

9. Dimensionamiento y planificación de capacidad

9.1 Requisitos de memoria

Escenario FD base Por trabajador (dump) nbackup replay
Mínimo 512 MB +128 MB cada uno +64 MB +64 MB
Dump paralelo con 4 trabajadores 512 MB +512 MB (4×128) — —
Cadena nbackup con BD grande 512 MB — +64 MB —
Log shipping con replay 512 MB — — +64 MB

Ejemplo. Un servidor que ejecuta dump paralelo con 4 trabajadores sobre 4 bases de datos debe tener al menos 1,5 GB de RAM asignados al grupo de procesos de bacula-fd.

9.2 Requisitos de CPU

Escenario Núcleos recomendados
Dump de BD única 1
Dump paralelo de 4 BDs 4 (1 por trabajador)
Cadena nbackup (cualquier nivel) 1
Log shipping con replay 1
Métricas Prometheus habilitadas +0,1 (despreciable)

9.3 Espacio en disco — binarios del plugin

Archivo Tamaño
podheitor-firebird-fd.so ~580 KB
podheitor-firebird-backend ~516 KB
Huella total de instalación ~1,1 MB

9.4 Espacio en disco — directorio de estado

Cada base de datos rastreada en modo nbackup almacena un manifiesto JSON de aproximadamente 1 KB por entrada de cadena. Para un entorno con 100 bases de datos y cadenas de 4 niveles, el directorio de estado requiere aproximadamente 400 KB — insignificante.

9.5 Estimaciones del volumen de backup

Modo Tamaño esperado (vs BD sin comprimir)
dump (sin compresión) 60–80% del tamaño de la BD
dump (zstd nivel 3) 20–45% del tamaño de la BD (21,4% observado en laboratorio)
nbackup L0 ~100% del tamaño de la BD (solo páginas)
nbackup L1/L2/L3 1–30% del tamaño de la BD (solo páginas modificadas)
Segmentos de journal replay < 1% del tamaño de la BD por segmento

10. Informe de rendimiento

Todas las mediciones se realizaron en un entorno de laboratorio controlado usando contenedores de Firebird (LI-V3.0.13, LI-V4.0.7, LI-V5.0.4) sobre un hipervisor KVM/QEMU con PodHeitor Backup.

10.1 Fase 1 — dump y restauración de BD única con gbak

Métrica Resultado
Base de datos employee.fdb (muestra de Firebird)
Tamaño del backup 1.536 bytes
Estado del job T (terminado normalmente)
Verificación de restauración Idéntico byte a byte
JobId de Bacula 7929

10.2 Fase 1b — integridad de datos en ciclo completo de restauración

Métrica Resultado
Filas escritas antes del backup 10
Filas recuperadas tras la restauración 10
Método de verificación Comparación con SELECT COUNT(*)
Resultado PASS

10.3 Fase 2 — backup paralelo de múltiples bases de datos

Métrica Secuencial Paralelo (4 trabajadores) Aceleración
Bases de datos 4–7 4–7 —
Tiempo real (wall-clock) Base Base / 5,6 5,6×
Relación de compresión zstd — 21,4% en línea —
Estado de todos los jobs T T —

10.4 Fase 3 — cadena nbackup L0+L1+L2+L3

Nivel Tamaño del backup Estado
L0 ~875 KB T
L1 ~612 KB T
L2 ~1,1 MB T
L3 ~956 KB T
Total de la cadena 3,5 MB T
Verificación de restauración
Filas en la BD original 13.500
Filas recuperadas 13.500
Idéntico byte a byte en cada nivel Sí

10.5 Fase 4 — gbak con trabajadores paralelos en FB 5 + limitación de ancho de banda

Métrica Resultado
Versión de Firebird LI-V5.0.4
Trabajadores paralelos de gbak Habilitados
Objetivo de ancho de banda 64 KB/s
Throughput medido 64,5 KB/s promedio
Desviación del objetivo ±0,8%

10.6 Fase 5 — log shipping de replicación

Métrica Resultado
Segmentos de journal enviados 3
Baseline gbak Incluido
Verificación MD5 Ciclo completo idéntico byte a byte
Estado del job T

10.7 Fase 6 — migración entre versiones FB 3→5

Métrica Resultado
Origen FB 3.0 (ODS 12)
Destino FB 5.0 (ODS 13)
Filas preservadas 10
Actualización de ODS Automática mediante restore con gbak
Verificación con gfix Limpio (sin errores)

10.8 Fase 7 — Firebird Embedded + Services API

Prueba Resultado
Backup con Firebird Embedded PASS
Backup remoto con Services API (-se) PASS
Ambas puertas de aceptación PASS

10.9 Fase 8 — cifrado, métricas, CLI gc-chain, paquetes

Funcionalidad Resultado
Passthrough de argv para cifrado PASS
Endpoint Prometheus /metrics PASS
CLI gc-chain (GC de manifiesto nbackup) PASS
Construcción de paquete RPM PASS
Construcción de paquete DEB PASS

10.10 Resumen del conjunto de pruebas

Fase Pruebas añadidas Total acumulado
Fase 0 (bootstrap) 0 0
Fase 1 (dump E2E) 6 6
Fase 1b (ciclo completo de restauración) 4 10
Fase 2 (multi-BD paralelo) 17 27
Fase 3 (cadena nbackup) 13 40
Fase 4 (FB5 paralelo + BW) 16 56
Fase 5 (replay/log shipping) 6 62
Fase 6 (entre versiones) 25 87
Fase 7 (embebido + svc API) 19 106
Fase 8 (cifrado + métricas + paquetes) 14 120

11. Matriz de compatibilidad

11.1 Sistema operativo

SO Arquitectura Estado
RHEL 9 x86_64 Soportado
Oracle Linux 9 x86_64 Soportado
Rocky Linux 9 x86_64 Soportado
AlmaLinux 9 x86_64 Soportado
Ubuntu 22.04 LTS x86_64 Soportado
Debian 12 x86_64 Soportado
RHEL 8 / CentOS 8 x86_64 No testeado (glibc < 2.34)
Ubuntu 20.04 x86_64 No testeado (glibc < 2.34)
ARM64 / aarch64 cualquiera Aún no disponible

11.2 Versiones de Firebird

Versión de Firebird ODS dump nbackup replay
3.0.x (probado con LI-V3.0.13) 11/12 Sí Sí No
4.0.x (probado con LI-V4.0.7) 12 Sí Sí Sí
5.0.x (probado con LI-V5.0.4) 13 Sí Sí Sí

11.3 Versiones de Bacula

Versión de Bacula Estado
Community 15.0.3 Soportado (validado)
Community 15.0.x (futuras) Compatible esperado
Community 14.x No soportado
Bacula Enterprise No requerido; el plugin apunta a PodHeitor Backup

11.4 Librerías del sistema

Librería Versión mínima
glibc 2.34
libpthread incluida en glibc
libdl incluida en glibc

12. Seguridad

12.1 Manejo de credenciales

Las contraseñas de Firebird nunca se almacenan en la configuración de Jobs o FileSets de Bacula. El enfoque recomendado es un archivo de credenciales dedicado:

/opt/bacula/etc/.fbpass
  Owner: bacula:bacula
  Mode:  0600
  Format: USERNAME=password (one per line)

El plugin lee este archivo al inicio del job, antes de ejecutar el proceso hijo del backend. La contraseña se pasa a gbak/nbackup mediante el entorno del proceso, no como argumento de línea de comandos, para evitar su exposición en la salida de ps.

12.2 Contraseña de cifrado

El parámetro encrypt_passphrase pasa una clave de cifrado al argv nativo de cifrado de gbak. Esto es un passthrough de argv — el plugin no implementa su propia capa de cifrado. Los operadores que usen esta funcionalidad deben asegurarse de que:

  • La contraseña esté almacenada en el archivo .fbpass, no de forma inline en la configuración del FileSet
  • La contraseña nunca se registre en logs (el plugin la oculta en toda salida de registro)
  • La misma contraseña esté disponible en el momento de la restauración

12.3 Permisos del directorio de estado

El directorio de estado /opt/bacula/working/firebird-state/ se crea con:

Owner: bacula:bacula
Mode:  0750

Solo el usuario bacula y los miembros del grupo bacula pueden leer o escribir los manifiestos de cadena. Esto impide la enumeración no autorizada de las rutas de las bases de datos respaldadas.

12.4 Aislamiento del proceso backend

El plugin ejecuta un proceso backend por cada job de Bacula. El backend hereda únicamente las credenciales y la configuración necesarias para ese job. No existe estado mutable compartido entre jobs de backup concurrentes. Si el backend falla o es terminado, el plugin reporta un error de job y bacula-fd continúa atendiendo otros jobs con normalidad.

12.5 Seguridad de red

El plugin usa el propio protocolo TCP de Firebird para conectarse al servidor de base de datos. No abre ningún puerto de escucha adicional. El endpoint opcional de métricas Prometheus (metrics_listen) es un endpoint HTTP de solo lectura que expone únicamente contadores operativos; no expone credenciales ni contenido de datos.

Los operadores deben restringir el acceso al puerto de métricas mediante reglas de firewall:

# Allow metrics access from monitoring host only
firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 port port=9182 protocol=tcp accept' --permanent
firewall-cmd --reload

13. Monitoreo

13.1 Endpoint de métricas Prometheus

Cuando metrics_listen está configurado en la cadena Plugin, el backend expone un endpoint /metrics en formato de texto Prometheus. Ejemplo de configuración:

Plugin = "podheitor-firebird: db=/var/firebird/prod.fdb mode=dump metrics_listen=0.0.0.0:9182"

13.2 Métricas expuestas

Métrica Tipo Descripción
podheitor_firebird_backup_jobs_total Contador Total de jobs de backup iniciados
podheitor_firebird_backup_bytes_total Contador Total de bytes enviados a Bacula
podheitor_firebird_backup_duration_seconds Histograma Duración del backup por job
podheitor_firebird_restore_jobs_total Contador Total de jobs de restauración iniciados
podheitor_firebird_restore_duration_seconds Histograma Duración de la restauración por job
podheitor_firebird_nbackup_chain_levels Gauge Profundidad actual de la cadena nbackup por BD
podheitor_firebird_compression_ratio Gauge Relación de compresión más reciente
podheitor_firebird_bandwidth_kbps Gauge Throughput medido instantáneo
podheitor_firebird_errors_total Contador Total de eventos de error por código de error

13.3 Configuración de scrape de Prometheus

scrape_configs:
  - job_name: 'podheitor-firebird'
    static_configs:
      - targets: ['firebird-host:9182']
    scrape_interval: 30s

13.4 Monitoreo de jobs de Bacula

Se aplica el monitoreo estándar de Bacula. El plugin asigna los códigos de estado de job apropiados:

  • T — terminado normalmente
  • E — terminado con errores (el plugin registra detalles en bacula-fd.log)
  • f — error fatal (el backend no pudo iniciarse o falló)

Revise /opt/bacula/log/bacula-fd.log para obtener mensajes detallados a nivel del plugin.

14. Guía de resolución de problemas

14.1 Errores comunes

Plugin no encontrado al inicio

Error: cannot open shared object file: No such file or directory

Causa. podheitor-firebird-fd.so no está en el directorio de plugins configurado.
Solución. Verifique que /opt/bacula/plugins/podheitor-firebird-fd.so exista y compruebe la directiva PluginDirectory correcta en bacula-fd.conf.

El backend no puede iniciarse

podheitor-firebird: failed to fork backend: No such file or directory

Causa. El binario podheitor-firebird-backend está ausente o no es ejecutable.
Solución:

ls -la /opt/bacula/bin/podheitor-firebird-backend
chmod 755 /opt/bacula/bin/podheitor-firebird-backend

Conexión rechazada por Firebird

podheitor-firebird: gbak error: unavailable database

Causa. El servidor Firebird no está en ejecución, o fb_host/fb_port es incorrecto.
Solución:

systemctl status firebird
# or for SuperServer:
/opt/firebird/bin/fbguard -pidfile /tmp/firebird.pid &

Contraseña incorrecta

podheitor-firebird: gbak error: Your user name and password are not defined

Causa. El archivo .fbpass está ausente, no es legible o contiene credenciales incorrectas.
Solución:

cat /opt/bacula/etc/.fbpass   # verify content
stat /opt/bacula/etc/.fbpass  # verify permissions (must be 600, owner bacula)

Cadena nbackup corrupta / L0 faltante

podheitor-firebird: nbackup restore error: cannot find level 0 backup

Causa. La entrada L0 de la cadena falta en el manifiesto de estado, o el volumen de Bacula correspondiente ha expirado.
Solución. Ejecute un nuevo job de backup L0 para restablecer la cadena:

*run job=FB-Nbackup-L0 level=Full yes

Incompatibilidad de versión de glibc

version 'GLIBC_2.34' not found

Causa. La versión de glibc del host es anterior a 2.34 (común en RHEL 8 / Ubuntu 20.04).
Solución. El plugin requiere glibc 2.34+. Actualice a RHEL 9 / Rocky 9 / Ubuntu 22.04 o posterior.

14.2 Ubicaciones de logs

Log Ruta
Log principal de bacula-fd /opt/bacula/log/bacula-fd.log
Salida de depuración del plugin incluida en bacula-fd.log; prefijo podheitor-firebird:
Mensajes de Bacula según lo configurado en el recurso Messages de bacula-fd.conf
Log del servidor Firebird /opt/firebird/firebird.log

14.3 Habilitación del registro de depuración

Agregue debug=9 a la cadena Plugin para habilitar la salida detallada a nivel del plugin:

Plugin = "podheitor-firebird: db=/var/firebird/prod.fdb mode=dump debug=9"

Esto registrará cada mensaje del canal interno, cada invocación de gbak y todas las transiciones de estado en bacula-fd.log.

15. Casos de uso y escenarios de implementación

15.1 Backup nocturno de sistema ERP

Escenario. Una empresa manufacturera ejecuta el ERP Totvs Protheus sobre Firebird 4.0 con 12 bases de datos de entre 2 GB y 45 GB. Necesitan backups completos nocturnos con retención de 30 días.

Solución.

  • Modo: dump con compress=zstd workers=4
  • Horario: nocturno a las 01:00
  • Retención: 30 días en pool de Bacula
  • Ventana de backup estimada: ~3 horas para las 12 BDs en lotes paralelos de 4

FileSet.

Plugin = "podheitor-firebird: db=/data/protheus/db1.fdb,/data/protheus/db2.fdb,/data/protheus/db3.fdb,/data/protheus/db4.fdb mode=dump workers=4 compress=zstd"

15.2 Incremental de base de datos grande con nbackup

Escenario. Una empresa logística tiene una base de datos Firebird de 200 GB que no puede respaldarse completamente cada noche dentro de la ventana de backup.

Solución.

  • Semanal: L0 (instantánea completa de páginas) — domingos 02:00
  • Nocturno: L1 (páginas modificadas) — lunes a sábados 02:00
  • Mensual: reiniciar cadena con nuevo L0 — primer domingo del mes

Beneficios. La ventana de backup nocturna se reduce de horas a minutos; la restauración completa requiere solo L0 + el último L1.

15.3 Nodo DR en espera con log shipping de replicación

Escenario. Una empresa de servicios financieros requiere RPO < 5 minutos para su base de datos de transacciones en Firebird 5.0.

Solución.

  • Modo: replay con replay_log_dir=/var/firebird/replay/transactions
  • Segmentos de journal enviados cada 5 minutos mediante el programador de Bacula
  • El sitio en espera aplica los journals automáticamente en la restauración
  • RTO: ~15 minutos (tiempo para ejecutar la restauración con gbak + aplicar journals pendientes)

15.4 Proyecto de migración entre versiones

Escenario. Una empresa está migrando de Firebird 3.0 a Firebird 5.0 en 30 bases de datos. Necesitan un proceso probado y repetible.

Solución.

  • Respaldar las 30 bases de datos en FB 3.0 usando el modo dump
  • Restaurar a hosts con FB 5.0 usando restore_path — gbak actualiza automáticamente de ODS 12→13
  • Ejecución de gfix post-restauración (habilitado por defecto mediante fix_shadow=true)
  • Verificado con comprobaciones de esquema y datos mediante isql

15.5 Backup de aplicación con Firebird Embedded

Escenario. Un dispositivo de gateway IoT ejecuta una base de datos Firebird embebida localmente, sin proceso de servidor Firebird. El dispositivo ejecuta bacula-fd y el plugin debe respaldar la BD embebida.

Solución.

  • Modo: dump embedded=true
  • El plugin se conecta directamente al archivo de base de datos mediante el motor Firebird Embedded
  • No se requiere proceso servidor; el backup se ejecuta mientras la aplicación está en reposo
Plugin = "podheitor-firebird: db=/data/device.fdb mode=dump embedded=true compress=lz4"

16. Comparación con otros enfoques

16.1 Comparación de funcionalidades

La siguiente tabla compara el plugin PodHeitor Firebird ejecutándose sobre PodHeitor Backup con formas alternativas de proteger datos de Firebird mediante plataformas comerciales de backup empresarial. Bacula Enterprise se incluye como referencia: ofrece un excelente backup empresarial de propósito general y sigue siendo una opción sólida cuando se necesitan capacidades más amplias de BEE; este plugin está diseñado específicamente para ofrecer funcionalidad específica de Firebird (cadena nbackup, log shipping con replay, migración entre versiones, soporte para motor embebido) sobre la base de PodHeitor Backup.

Funcionalidad PodHeitor Backup + PodHeitor Bacula Enterprise Veeam Commvault
Backup nativo de Firebird Sí Limitado No No
Volcado lógico con gbak Sí Varía según versión No No
Cadena nbackup a nivel de página Sí No No No
Log shipping de replicación Sí No No No
Multi-BD paralelo Sí No No No
Compresión (zstd/lz4) Sí Sí (gzip) Sí Sí
Limitación de ancho de banda Sí Sí Sí Sí
Métricas Prometheus Sí No No No
Migración entre versiones Sí No No No
Firebird Embedded Sí No No No
Services API Sí Parcial No No
FB 3.0 / 4.0 / 5.0 Los 3 Varía No No
Compatibilidad con PodHeitor Backup Sí N/A N/A N/A
Plataforma base de código abierto Sí (Bacula CE) No No No
Passthrough de cifrado Sí Sí Sí Sí
Restauración idéntica byte a byte Sí Sí Varía Varía
Paquetes RPM + DEB Sí Sí Sí Sí

16.2 Comparación de costos

Oferta especial. Traiga su propuesta de renovación de Veeam, Commvault, NetBackup o cualquier otra plataforma de backup empresarial. Elaboraremos una propuesta comparativa por escrito que apunte a al menos un 50% de ahorro, con funcionalidad superior específica para Firebird. Contacte a heitor@opentechs.lat.

Solución Costo anual típico Soporte para Firebird
PodHeitor Backup + plugin PodHeitor Significativamente menor Nativo completo (este plugin)
Bacula Enterprise A menudo > US$ 10.000/año Limitado
Veeam Data Platform A menudo > US$ 5.000/año Ninguno (solo scripted)
Commvault A menudo > US$ 15.000/año Ninguno (solo scripted)
NetBackup A menudo > US$ 20.000/año Ninguno (solo scripted)

Los precios varían según el tamaño del entorno y los contratos negociados. Contacte a heitor@opentechs.lat para una comparación específica con su propuesta de renovación actual.

17. Hoja de ruta

El plugin está listo para producción en la versión v0.1.0 con las 8 fases validadas. La dirección de desarrollo futuro incluye:

  • Soporte multi-arquitectura. Paquetes ARM64 / aarch64 para Raspberry Pi y servidores ARM nativos en la nube.
  • Soporte para Windows. Firebird en Windows está ampliamente implementado; una compilación para Windows está en consideración.
  • Preparación para Firebird 6.0. Seguimiento de los cambios de ODS en las próximas versiones de Firebird.
  • Métricas extendidas. Historial de backups por base de datos, puntajes de salud de cadena, umbrales de alertas automatizados.
  • Integración con interfaz web. Panel de configuración del plugin en Bacularis para los parámetros del plugin.
  • Validación automática de cadena. Verificación periódica programada de la integridad de la cadena nbackup.

No se han comprometido fechas de lanzamiento específicas. La dirección de funcionalidades está guiada por el feedback de los clientes y los hallazgos de laboratorio.

18. Conclusión

El PodHeitor Firebird Backup Plugin extiende PodHeitor Backup con la primera integración nativa de Firebird de grado productivo disponible en la plataforma de código abierto Bacula. Ofrece tres modos de backup complementarios (dump, nbackup, replay), cubre todas las versiones soportadas de Firebird (3.0, 4.0, 5.0), y ha sido validado a través de 120 pruebas automatizadas en 8 fases de desarrollo. El resultado es un camino robusto, auditable y rentable hacia DR de Firebird de grado empresarial.

Para organizaciones que actualmente ejecutan PodHeitor Backup con bases de datos Firebird, el plugin no requiere cambios en la plataforma — instale el RPM o DEB, agregue una cadena Plugin a su FileSet, y sus bases de datos Firebird quedan protegidas de inmediato. Para organizaciones que evalúan renovaciones de plataformas comerciales de backup premium, la combinación de PodHeitor Backup y el plugin PodHeitor ofrece funcionalidad específica de Firebird igual o superior a un costo total sustancialmente menor.

Para comenzar:

  • Descargue el plugin: https://podheitor.com
  • Solicite una cotización o demostración: heitor@opentechs.lat
  • Teléfono / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licenciamiento

PodHeitor Firebird Backup Plugin es software propietario, distribuido por suscripción. Para condiciones comerciales, demostración técnica o diagnóstico gratuito de 30 minutos, habla con el equipo por los canales abajo.

¿Listo para evaluar?

19. Información de contacto

Autor Heitor Faria
Sitio web https://podheitor.com
Email heitor@opentechs.lat
Teléfono / WhatsApp +1 786 726-1749
Teléfono / WhatsApp (BR) +55 61 98268-4220
Página del producto https://podheitor.com/firebird-plugin
Soporte heitor@opentechs.lat

20. Legal / derechos de autor

© 2026 Heitor Faria — todos los derechos reservados.

El PodHeitor Firebird Backup Plugin for Bacula es software propietario. La copia, distribución, modificación o ingeniería inversa no autorizada está estrictamente prohibida. Se requiere una licencia comercial para uso en producción.

Bacula® es una marca registrada de Kern Sibbald y la comunidad de Bacula. Firebird® es una marca registrada del Proyecto Firebird. Todas las demás marcas comerciales son propiedad de sus respectivos dueños.

Este documento se proporciona con fines informativos. Las cifras de rendimiento provienen de mediciones de laboratorio controladas y pueden variar en entornos de producción según el hardware, las condiciones de red, la configuración de Firebird y las características de la base de datos.

Contacto para licenciamiento: heitor@opentechs.lat | https://podheitor.com | +1 786 726-1749 | +55 61 98268-4220

PodHeitor Firebird Backup Plugin for Bacula — v0.1.0 — © 2026 Heitor Faria — todos los derechos reservados — https://podheitor.com

Disponível em: pt-brPortuguês (Portugués, Brasil)enEnglish (Inglés)esEspañol

Deja una respuesta