Whitepaper técnico — PodHeitor vSphere para Bacula - PodHeitor

Backup image-level vía VADP + CBT, replicación push CBT-based con 10 modos DR, restore cross-hypervisor (vSphere ↔ Hyper-V ↔ Proxmox), y el paquete VDDK runtime RPM con RPATH=$ORIGIN que evita contaminar el ld.so del host.

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

1. Problema: Bacula stock no habla VADP

Bacula Community por diseño no tiene cliente VADP ni CBT. Backup de VMs ESXi vía FD stock se reduce a:

Backup del datastore montado en el host FD — captura VMDKs en estado inconsistente, sin snapshot, sin CBT.
Plugin Bacula Enterprise vSphere — existe, pero a precio enterprise y sin replicación DR cross-site ni 10 modos de failover.
Veeam standalone — paralelo a Bacula, con tooling, RPO, scripting y licencias separadas. Duplica TCO.

El PodHeitor vSphere BRC consolida backup, replicación y conversión cross-hypervisor en un único plugin Bacula, con integración nativa VADP + VDDK 9.0.

2. Modelo arquitectural

Bacula FD → Rust cdylib plugin (.so) → Rust backend binary (PTCOMM pipe)
                                          ↕
                                     vSphere SOAP API (vía reqwest)
                                          ↕
                                     VDDK 9.0 (FFI — read/write VMDK blocks)

El .so es una cdylib Rust pura construida desde el workspace PodHeitor Rust cdylib (crate plugin-vsphere). Implementa el ABI C del plugin Bacula FD vía el crate bacula-fd-abi reimplementado independientemente — ningún source tree de Bacula es necesario para build, y ningún objeto AGPLv3 de Bacula se vincula al binario. El .so spawnea al backend Rust como subproceso y usa PTCOMM (status_char + 6-digit length + newline + payload) sobre stdin/stdout.

3. Modos de transporte VADP

La lectura de VMDKs vía VADP soporta cuatro modos; el plugin los expone vía el parámetro transport:

Mode	Cuándo usar	Tradeoff
`nbd`	Lab, sin TLS requerido	Texto-claro; debug fácil
`nbdssl` (default)	Producción sin SAN compartido	TLS sobre NBD; CPU overhead aceptable
`hotadd`	FD corriendo como VM en el mismo cluster ESXi	Discos de la VM-target hot-add en el FD-VM; LAN-free
`san`	FD con acceso directo al SAN/iSCSI de la VM	LAN-free puro; máximo throughput

4. CBT — Changed Block Tracking

VADP CBT es la feature de VMware que permite a un cliente preguntar «qué bloques cambiaron desde el ChangeId X?». El plugin la usa en cada Incremental/Diferencial:

Snapshot consistente de la VM (con quiesce=true default — VMware Tools quiesce filesystem).
Query CBT contra el snapshot anterior — retorna lista de extents {offset, length}.
Lee vía VDDK sólo esos extents.
Stream-ea por PTCOMM con offsets preservados.
Elimina snapshot (con snapshot_delete_delay opcional para grandes commits).

El parámetro keep_cbt=true evita reset del estado CBT tras backup — útil cuando múltiples jobs Bacula consumen el mismo CBT en paralelo.

5. Replicación CBT-Push y los 10 modos DR

El plugin implementa replicación push basada en CBT con daemon receiver persistente del lado DR. El parámetro mode= selecciona una de diez operaciones:

Mode	Función
`replication-status`	Muestra status y last sync time
`seed`	Replicación full inicial (seed de la réplica)
`cbt-push`	Push CBT deltas a la réplica remota
`failover-test`	Boot de la réplica en red aislada (no-destructivo)
`failover-undo`	Deshace test failover, power off de la réplica
`failover-planned`	Failover graceful: sync → shutdown source → boot replica
`failover-unplanned`	Failover de emergencia: boot de la réplica inmediatamente
`failover-permanent`	Failover permanente: réplica vuelve producción
`failback`	Replicación reversa de la réplica de vuelta al source
`reprotect`	Re-establece replicación tras failback

Todo el workflow Veeam SRM-style (test → planned → reprotect) está disponible como modos del plugin, manejable desde el Bacula Director sin producto extra.

5.1 Network mapping y Re-IP

Parámetro	Formato	Función
`net_map`	`"source_net=target_net"`	Reconfigura NICs de la réplica en el failover
`reip`	`"nic:ip/prefix:gw:dns1,dns2"`	Reconfigura IP guest de la réplica en el failover
`storage_map`	`"source_ds=target_ds"`	Mapeo de datastore
`test_failover_network`	nombre de red	Red aislada para test failover (no contamina producción)

5.2 TLS para canal DR

Soporta dr_tls_cert + dr_tls_key (PEM) con rustls; dr_tls_insecure=true acepta self-signed (sólo para lab). Token PSK vía dr_auth_token obligatorio en todos los modos.

6. VDDK runtime RPM — por qué es importante

VDDK es distribuido por VMware como tarball con libcrypto.so.3/libssl.so.3/libcurl.so.4 bundled. Las instalaciones antiguas escribían /etc/ld.so.conf.d/vmware-vddk.conf apuntando a esas libs — haciendo que todo proceso en el host (incluyendo rpm, dnf, flatpak) cargue el libcrypto de VMware en lugar del OpenSSL del sistema. Síntoma típico:

flatpak: /usr/lib/vmware-vix-disklib/lib64/libcrypto.so.3: 
    version `OPENSSL_3.4.0' not found (required by /lib64/librpmio.so.9)

El podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm resuelve esto en build time: cada .so en /usr/lib/vmware-vix-disklib/lib64 es parcheado con RPATH=$ORIGIN, así VDDK resuelve sus siblings desde su propio directorio sin contaminar el ld.so del host. El scriptlet %post remueve cualquier /etc/ld.so.conf.d/vmware-vddk*.conf, vixlib*.conf o flatpack*.conf stale y reejecuta ldconfig.

Recovery sin internet (host ya roto por instalación legacy):

sudo rm -f /etc/ld.so.conf.d/vmware-vddk.conf 
           /etc/ld.so.conf.d/vmware-vix-disklib.conf 
           /etc/ld.so.conf.d/*vixlib*.conf 
           /etc/ld.so.conf.d/*flatpack*.conf
sudo ldconfig
sudo rpm -Uvh releases/podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm

7. Cross-restore (vSphere ↔ Hyper-V ↔ Proxmox)

El plugin participa en dos lados del triángulo cross-hypervisor:

Como source: los backups VMware se pueden restaurar en Hyper-V o Proxmox vía los plugins-hermanos PodHeitor Hyper-V / PodHeitor Proxmox.
Como target: los backups Hyper-V/Proxmox se pueden restaurar en vSphere vía este plugin (con conversión VHDX → VMDK y qcow2 → VMDK).

8. Compatibilidad

Componente	Versiones soportadas
VMware ESXi	7.0, 8.0, 8.0U3
VMware vCenter	7.0, 8.0
VDDK	8.0.x, 9.0.x
Bacula Community	15.0.x
OS (FD server)	Oracle Linux 9, RHEL 9, Rocky 9, AlmaLinux 9
Arquitectura	x86_64

9. Validación en laboratorio

ESXi 8.0U3e standalone host, VDDK 9.0.1 en Oracle Linux 9.5, Bacula Community 15.0.3.
4 VMs con CBT habilitado (Alpine, TinyCore, CirrOS, multi-disk).
12/12 tests de replicación PASSED (abril 2026).
v1.4.1: lab job 6442 restauró 2,147 GB / 4 archivos en 6s, 0 errores FD; VM Alpine 3.21 restaurada bootea limpia.

10. Anti-patterns documentados

No dejes dr_tls_insecure=true en producción. Acepta self-signed certs en el canal DR — útil en lab; riesgo MITM en prod.
No uses force_san=true sin zoneamiento SAN correcto. El FD debe ver los LUNs de la VM target directamente; misconfiguration causa errores I/O confusos.
No corras quiesce=false en VMs con DBs. Snapshot crash-consistent → DBs necesitan recovery en boot de réplica/restore.

11. Postura de licencia

Plugin bajo LicenseRef-PodHeitor-Proprietary. Desde v1.4.0, el .so es cdylib Rust pura — ningún source AGPLv3 de Bacula se vincula estáticamente. Releases anteriores linkeaban objetos C++ pluginlib/metaplugin del tree de Bacula — ya no es el caso. Bindings vía crate clean-room bacula-fd-abi.

¿Listo para evaluar?

Trial gratuito de 30 días para flotas vSphere en producción. Garantizamos al menos 50% de descuento vs Bacula Enterprise, Veeam o Commvault, con 10 modos DR y restore cross-hypervisor incluidos.

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

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