Blog

Plugin commercial-grade Rust para Firebird 3/4/5 sobre Bacula Community 15.0.3+, fechando uma lacuna real: Bacula Enterprise não ships um plugin Firebird. Três 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 complementar à página do plugin PodHeitor Firebird.

1. O white space — Firebird sem plugin nativo

Bacula Enterprise 18.2.3 ships plugins para PostgreSQL e MySQL, mas não ships um plugin Firebird. Em mercados como Brasil/LatAm, isso é uma lacuna concreta: Firebird ainda domina ERPs legacy (TOTVS Protheus, sistemas de gestão pública), EMR/HIS, e aplicações embedded. Sem plugin, o caminho de backup atual é:

• gbak ad-hoc para arquivo + Bacula backup do arquivo (duas etapas, sem coordenação).
• nbackup manual sem chain management — o Bacula não sabe correlacionar levels.
• FS-level snapshot do .fdb (corre risco de DB inconsistente se o lock file não for respeitado).

O PodHeitor Firebird Plugin é o primeiro plugin nativo, e o único na família PodHeitor que cobre o gap completamente — três modos cobrindo todos os tradeoffs de janela vs granularidade vs RPO.

2. Arquitetura — cdylib + standalone backend, padrão 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    │                  │
│  └──────────┘ └──────────┘ └──────────────┘                  │
└──────────────────────────────────────────────────────────────┘

Mesmo padrão dos plugins podheitor-postgresql / podheitor-mssql / podheitor-oracle: cdylib Rust dlopen-ado pelo bacula-fd, fork+exec do backend standalone, comunicação PTCOMM (length-tagged framing em stdin/stdout). Crash isolation; AGPLv3 license firewall; nenhum source do Bacula vinculado estaticamente.

3. Três modos — mapeamento natural ao Firebird

3.1 Mapping para Bacula levels

4. Versões Firebird suportadas

4.1 Detecção de versão

• Probe via isql -z -q -i /dev/null (imprime version line) ou gbak -z.
• Connect-time: query MON$DATABASE.MON$SERVER_VERSION.
• Auto-enable gbak -par quando FB ≥5 detectado.
• Auto-enable mode=replay apenas quando FB ≥4 detectado.
• Recusa start em FB ≤2.x com mensagem clara apontando à matrix.

5. Architecture awareness — SuperServer / Classic / SuperClassic

Firebird tem três architectures distintas com características operacionais opostas:

Detecção via MON$ATTACHMENTS.MON$SERVER_PID cardinality + firebird.conf::ServerMode. Em Classic, o plugin auto-throttle conexões para evitar exhaustar o connection pool em DBs com muitos clients ativos.

6. Cross-version migration

O plugin suporta upgrade ODS (On-Disk Structure) durante restore: backup feito em FB 3 pode ser restaurado em FB 4 ou FB 5. Caminho típico:

1. Backup mode=dump em FB 3 (ODS 12.0).
2. Cliente migra para FB 5 (ODS 13.1).
3. Restore mode=dump aponta para servidor FB 5.
4. gbak -r reconhece a ODS source e upgrade-a in-flight.

Não suportado: downgrade (FB 5 → FB 3 perderia features).

7. Embedded Firebird — backup sem servidor rodando

Para aplicações que usam Firebird embedded (single-file .fdb, sem daemon Firebird rodando), mode=dump com embedded=true usa libfbembed para abrir o arquivo direto. Caso de uso típico: aplicações desktop, ERPs de pequeno porte, dispositivos embarcados.

8. Verificação de integridade

O backend roda gfix -v antes e depois de cada backup, e smoke-query a RDB$RELATIONS. Em DBs corruptos, o gfix -v reporta páginas inconsistentes — o plugin marca o job como “warning” no Bacula (não fatal), gera relatório, e segue.

9. Observabilidade — Prometheus opcional

Sidecar Prometheus expõe métricas:

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

10. Anti-patterns documentados

• Não rode mode=nbackup em DB < 50 GB. O overhead de chain management (lock file, level tracking) supera o ganho. Use dump.
• Não deixe a chain nbackup ficar profunda demais. Restore in-place precisa replay todos os levels. Faça Full (L0) novo a cada N=7-14 dias.
• Não rode mode=replay em FB 3. Replication log é FB ≥4. O plugin recusa em runtime.
• Não rode parallel workers (gbak -par) em hardware sem cores ociosos. O FB 5 parallel acelera proporcional a CPU livre; saturar CPU degrada DB live ops.
• Não confunda crash-consistent com application-consistent. FS snapshot do .fdb é crash-consistent — válido mas pode exigir gfix -v no restore. Para application-consistent, use os modes dump/nbackup com gbak/nbackup que falam com o engine.

11. License posture

Plugin distribui sob LicenseRef-PodHeitor-Proprietary. O cdylib runtime declara license = "Bacula AGPLv3" apenas para satisfazer o gate ABI do FD loader; nenhum source do Bacula é vinculado estaticamente. Backend é binário Rust standalone, não toca ABI do Bacula.

Pronto para avaliar?

Trial gratuito de 30 dias para servidores Firebird 3/4/5. Garantimos no mínimo 50% de desconto vs alternativas comerciais (Bacula Enterprise não cobre Firebird, Veeam não cobre Firebird, Commvault tem suporte limitado). Suporte exclusivo para o ecossistema Firebird brasileiro.

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

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