Blog

Plugin commercial-grade Rust para Firebird 3/4/5 sobre Bacula Community 15.0.3+, cerrando una laguna real: Bacula Enterprise no incluye un plugin Firebird. Tres modos (gbak dump, nbackup chain L0..LN, FB ≥4 replication-log shipping), cross-version migration, FB 5 parallel workers (gbak -par), encryption-at-rest passthrough.

Documento técnico complementario a la página del plugin PodHeitor Firebird.

1. El white space — Firebird sin plugin nativo

Bacula Enterprise 18.2.3 incluye plugins para PostgreSQL y MySQL, pero no incluye un plugin Firebird. En mercados como Brasil/LatAm, eso es una laguna concreta: Firebird todavía domina ERPs legacy (TOTVS Protheus, sistemas de gestión pública), EMR/HIS, y aplicaciones embedded. Sin plugin, el camino actual de backup es:

• gbak ad-hoc a archivo + Bacula backup del archivo (dos pasos, sin coordinación).
• nbackup manual sin chain management — Bacula no correlaciona levels.
• FS-level snapshot del .fdb (corre riesgo de DB inconsistente si el lock file no se respeta).

El PodHeitor Firebird Plugin es el primer plugin nativo y el único en la familia PodHeitor que cierra la laguna completamente — tres modos cubriendo todos los tradeoffs de ventana vs granularidad vs RPO.

2. Arquitectura — cdylib + standalone backend, patrón PodHeitor

┌──────────────────────────────────────────────────────────────┐
│  Bacula File Daemon (FD) — bacula-fd 15.0.3+                 │
│  loads /opt/bacula/plugins/podheitor-firebird-fd.so          │
│         (Rust cdylib, ~600 KB)                               │
└──────────────────────────────┬───────────────────────────────┘
                               │ fork+exec (PTCOMM via stdin/stdout)
                               ▼
┌──────────────────────────────────────────────────────────────┐
│  /opt/bacula/bin/podheitor-firebird-backend  (Rust binary)   │
│                                                              │
│  ┌─────────────────────┐ ┌─────────────────────┐             │
│  │ DumpEngine          │ │ NbackupEngine       │             │
│  │ (gbak, FB5 -par)    │ │ (chain L0..LN)      │             │
│  └─────────────────────┘ └─────────────────────┘             │
│  ┌─────────────────────┐ ┌─────────────────────┐             │
│  │ ReplayEngine        │ │ RestoreEngine       │             │
│  │ (FB4 log shipping)  │ │ (in-place chain)    │             │
│  └─────────────────────┘ └─────────────────────┘             │
│  ┌─────────────────────────────────────────────┐             │
│  │ FirebirdAdapter — services API + libfbclient │             │
│  │ Local: spawn gbak/nbackup     Remote: TCP    │             │
│  └─────────────────────────────────────────────┘             │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐                  │
│  │ Parallel │ │ Compress │ │ Throttle /   │                  │
│  │ Executor │ │ (zstd…)  │ │ BW shaper    │                  │
│  └──────────┘ └──────────┘ └──────────────┘                  │
└──────────────────────────────────────────────────────────────┘

Mismo patrón de los plugins podheitor-postgresql / podheitor-mssql / podheitor-oracle: cdylib Rust dlopen-ado por bacula-fd, fork+exec del backend standalone, comunicación PTCOMM (length-tagged framing en stdin/stdout). Crash isolation; AGPLv3 license firewall; ningún source de Bacula vinculado estáticamente.

3. Tres modos — mapeo natural a Firebird

3.1 Mapping a Bacula levels

4. Versiones Firebird soportadas

4.1 Detección de versión

• Probe vía isql -z -q -i /dev/null (imprime version line) o gbak -z.
• Connect-time: query MON$DATABASE.MON$SERVER_VERSION.
• Auto-enable gbak -par cuando FB ≥5 detectado.
• Auto-enable mode=replay solo cuando FB ≥4 detectado.
• Rechaza start en FB ≤2.x con mensaje claro apuntando a la matrix.

5. Architecture awareness — SuperServer / Classic / SuperClassic

Firebird tiene tres architectures distintas con características operacionales opuestas:

Detección vía MON$ATTACHMENTS.MON$SERVER_PID cardinality + firebird.conf::ServerMode. En Classic, el plugin auto-throttle conexiones para evitar agotar el pool en DBs con muchos clients activos.

6. Cross-version migration

El plugin soporta upgrade ODS (On-Disk Structure) durante restore: backup hecho en FB 3 puede restaurarse en FB 4 o FB 5. Camino típico:

1. Backup mode=dump en FB 3 (ODS 12.0).
2. Cliente migra a FB 5 (ODS 13.1).
3. Restore mode=dump apunta al servidor FB 5.
4. gbak -r reconoce la ODS source y la upgrade-a in-flight.

No soportado: downgrade (FB 5 → FB 3 perdería features).

7. Embedded Firebird — backup sin servidor corriendo

Para aplicaciones que usan Firebird embedded (single-file .fdb, sin daemon Firebird corriendo), mode=dump con embedded=true usa libfbembed para abrir el archivo directo. Caso de uso típico: aplicaciones desktop, ERPs de pequeño porte, dispositivos embebidos.

8. Verificación de integridad

El backend corre gfix -v antes y después de cada backup, y smoke-query a RDB$RELATIONS. En DBs corruptos, el gfix -v reporta páginas inconsistentes — el plugin marca el job como «warning» en Bacula (no fatal), genera reporte, y sigue.

9. Observabilidad — Prometheus opcional

Sidecar Prometheus expone métricas:

• firebird_backup_duration_seconds{mode, db}
• firebird_backup_bytes_total{mode, db}
• firebird_nbackup_chain_depth{db} (gauge — alerte si > 30)
• firebird_replay_lag_seconds{db} (gauge — RPO observado)
• firebird_gfix_warnings_total{db}

10. Anti-patterns documentados

• No corra mode=nbackup en DB < 50 GB. El overhead de chain management (lock file, level tracking) supera la ganancia. Use dump.
• No deje que la chain nbackup crezca muy profunda. Restore in-place necesita replay todos los levels. Tome un Full (L0) fresco cada N=7-14 días.
• No corra mode=replay en FB 3. Replication log es FB ≥4. El plugin lo rechaza en runtime.
• No corra parallel workers (gbak -par) en hardware sin cores ociosos. El FB 5 parallel acelera proporcional a CPU libre; saturar CPU degrada DB live ops.
• No confunda crash-consistent con application-consistent. FS snapshot del .fdb es crash-consistent — válido pero puede exigir gfix -v en el restore. Para application-consistent, use los modes dump/nbackup que conversan con el engine.

11. License posture

El plugin se distribuye bajo LicenseRef-PodHeitor-Proprietary. El cdylib runtime declara license = "Bacula AGPLv3" solo para satisfacer el gate ABI del FD loader; ningún source de Bacula es vinculado estáticamente. El backend es binario Rust standalone, no toca ABI de Bacula.

¿Listo para evaluar?

Trial gratuito de 30 días para servidores Firebird 3/4/5. Garantizamos al menos 50% de descuento vs alternativas comerciales (Bacula Enterprise no cubre Firebird, Veeam no cubre Firebird, Commvault tiene soporte limitado). Soporte exclusivo para el ecosistema Firebird brasileño.

Heitor Faria — Fundador, PodHeitor International
✉ [email protected]
☎ +1 (789) 726-1749 · +55 (61) 98268-4220 (WhatsApp)
🔗 Página del plugin PodHeitor Firebird

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