Blog

XBSA cdylib nativo reemplazando TSM/ISP, fallback ontape STDIO, log shipping continuo, PITR por LSN/timestamp, instant recovery vía loop-device + FUSE, y conversión cross-version IDS 12.10 → 14.10 → 15.0 sobre Bacula Community 15.0.3+.

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

1. El problema: Bacula stock fuerza TSM/ISP para HCL Informix

El modelo nativo de Informix para backup es ON-Bar, que en el ship IBM/HCL habla con IBM Spectrum Protect (TSM/ISP) vía XBSA. Para integrarlo a Bacula, las alternativas de mercado son:

• Bacula Enterprise Informix plugin — disponible, pero limitado a ON-Bar full + log archiving simple; sin PITR por LSN, sin instant recovery, sin conversión cross-version.
• Scripts shell wrappers alrededor de ontape — comunes en campo pero frágiles: sin detección de gap en log archiving, sin signal handling, sin timeouts, sin catalogación apropiada de manifests.
• TSM/ISP licenciado — caro, fuera del mundo Bacula, y cada renovación duele al presupuesto.

PodHeitor Informix entrega un XBSA cdylib nativo (libpodheitor_xbsa.so) que ON-Bar carga en lugar de TSM/ISP, ruteando los streams de datos directamente a Bacula vía Unix socket — reemplazando TSM por completo.

2. Modelo arquitectónico

bacula-fd
  └── podheitor-informix-fd.so   (cdylib Rust puro — crate plugin-informix;
        │                         metaplugin-rs / bacula-fd-abi; sin C shim)
        └── podheitor-informix-backend   (rlib Rust + binario CLI, dispatcher de engine)
              ├── XBSA engine: ON-Bar → libpodheitor_xbsa.so → Unix socket → Bacula
              ├── ontape engine: ontape -s -t STDIO → zstd → PTCOMM D-packets
              ├── log_shipper: onstat -l poll → ontape -a -l <uniq_id> → virtual file
              ├── PITR: replay de manifest chain → onmode -m
              ├── instant: imagen .raw → losetup → oninit -PHY (RTO < 60s)
              ├── table_level: sandbox Podman/Docker → dbexport → docker cp
              ├── snapshot: LVM lvcreate --snapshot / ZFS snapshot
              ├── replicate: bootstrap HDR/RSS/SDS/ER vía transporte Bacula
              └── logical_dbexport: dbexport streaming para migración cross-version

El cdylib corre dentro de bacula-fd; el backend es proceso separado per-job, hablando PTCOMM. La razón es la de siempre: crash isolation, libertad de paralelismo (XBSA stripes paralelos cross-dbspace), y firewall de licencia — sin source AGPLv3 de Bacula linkeado estáticamente.

3. Modos de operación soportados

4. XBSA cdylib nativo — reemplazando TSM/ISP

XBSA (X/Open Backup Services API) es el ABI estandarizado que ON-Bar usa para hablar con servidores de medios. IBM/HCL ships ON-Bar configurado para TSM/ISP. libpodheitor_xbsa.so implementa el ABI XBSA completo en Rust y traduce cada llamada XBSA en frames PTCOMM que viajan por Unix socket al backend, que a su vez habla con el cdylib de Bacula.

Configuración mínima en $INFORMIXDIR/etc/bar_act.cfg:

BAR_BSALIB_PATH=/opt/bacula/lib/libpodheitor_xbsa.so

ON-Bar ni siquiera necesita saber que está hablando con Bacula — sigue creyendo que es TSM/ISP. Resultado: cero cambios a scripts ON-Bar legacy, cero recapacitación de DBA.

5. Log shipping continuo y PITR

El log_shipper poll onstat -l para descubrir logs lógicos rotados. Cada nuevo log es ontape -a -l <uniq_id>-archived, hasheado en SHA-256, y enviado como virtual file separado dentro del mismo job Bacula incremental. Detección de gap es obligatoria: si un log fue consumido por otro proceso (o si el polling perdió un cycle), el plugin lo detecta vía comparación secuencial de unique-id y aborta con mensaje claro.

RPO sub-minuto es alcanzable con polling de 30s. PITR en restore acepta target en tres formas:

• restore_to_lsn=... — LSN exacto
• restore_to_time=2026-04-15T14:30:00Z — timestamp ISO 8601
• restore_to_txid=... — ID de transacción Informix

El backend computa la chain (Full + N logs) y dispara onmode -m para reabrir la instancia en el LSN target.

6. Instant recovery en < 60s

Para workloads que no toleran restore tradicional de horas, el modo instant exporta la imagen del dbspace como .raw, hace losetup en loop device, y llama oninit -PHY apuntando IDS al loop. La instancia sube en < 60s queryable. La migración de vuelta al storage local es background, sin ventana de downtime adicional.

7. Conversión cross-version (logical_dbexport)

Migrar IDS 12.10 → 14.10 → 15.0 con downtime mínimo es caso recurrente. El modo logical_dbexport streama dbexport vía PTCOMM — sin disco intermedio — y el lado destino corre dbimport directo desde el stream. Backup, migración y restore en un solo job Bacula.

8. Versiones soportadas

• HCL Informix Dynamic Server: 12.10.FC12+, 14.10, 15.0
• Bacula Community: 15.0.3+
• Linux: EL8/EL9 (RPM), Ubuntu 22.04 / Debian 12 (DEB), x86_64

9. Validación

E2E suite (T01–T18, lab 2026-04-29): PASS=22 / FAIL=0 / SKIP=0 / TOTAL=22 — los 22 escenarios activos. Lab: 4 VMs (primary, HDR, RSS, snapshot), IDS 15.0.1.0.3 Developer Edition, Bacula Community 15.0.3. Unit tests OL9: 80/80 PASS.

10. Postura de licencia

Propietaria — single license. No vincula estáticamente ningún source AGPLv3 de Bacula. El cdylib usa extern "C" independiente vía crate bacula-fd-abi in-house; libpodheitor_xbsa.so implementa el ABI XBSA estándar (X/Open) sin dependencia de código IBM/HCL.

¿Listo para evaluar?

Trial gratuito de 30 días para instancias Informix calificadas (12.10+, 14.10, 15.0). Garantizamos al menos 50% de descuento vs Bacula Enterprise, Veeam, Commvault o TSM/ISP, con más funcionalidades — incluyendo XBSA nativo, conversión cross-version e instant recovery que ningún competidor entrega.

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

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