Whitepaper — PodHeitor vSphere - PodHeitor — Backup, Replicação e Recuperação de Desastres

Respaldo VMware vSphere clase enterprise. VADP nativo, CBT (Changed Block Tracking), restore granular de archivo, instant recovery, application-consistent vía VMware Tools quiesce.

VADP nativo — captura vía VMware vStorage API, sin agente en la VM.
CBT (Changed Block Tracking) — incrementales reales, sin re-leer el disco completo.
Instant recovery — VM operativa en segundos desde el datastore del respaldo, Storage vMotion a producción en segundo plano.
Application-consistent — VMware Tools quiesce con VSS writer integrado.
Restore cross-vCenter — recupere a otro vCenter con mapeo automático de redes.

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 →

Backup, Replicación y Conversión para VMware vSphere/ESXi en PodHeitor Backup

💰 Oferta Especial

Traiga su cotización o propuesta de renovación de Bacula Enterprise, Veeam, Commvault o Netbackup. Ofrecemos al menos un 50% de descuento, con muchas más funcionalidades.

📧 heitor@opentechs.lat | 📱 +1 786 726-1749 | +55 61 98268-4220 (WhatsApp)

Tabla de Contenidos

Resumen Ejecutivo
Definición del Problema y Contexto de Mercado
Casos de Uso
Arquitectura
Funcionalidades — Backup
Funcionalidades — Replicación y Recuperación ante Desastres
Funcionalidades — Conversión entre Hipervisores
Arquitectura de Seguridad
Guía de Instalación
Referencia de Configuración
Ejemplos de Configuración de Backup
Ejemplos de Configuración de Replicación
Manual de Usuario y Operaciones del Día a Día
Dimensionamiento y Requisitos
Matriz de Compatibilidad
Resultados de Pruebas
Comparativa con Soluciones Empresariales
Resolución de Problemas
Licenciamiento y Contacto

1. Resumen Ejecutivo

PodHeitor vSphere BRC es un plugin production-ready para PodHeitor Backup Edition que ofrece capacidades de backup, replicación y conversión entre hipervisores para VMware vSphere de grado empresarial — a una fracción del costo de las soluciones comerciales.

Diferenciadores Clave

Tres productos en uno: Backup + Replicación + Conversión en un único plugin
Nativo para PodHeitor Backup: No requiere licencia Enterprise
Replicación basada en CBT: RPO casi en tiempo real con mínimo consumo de ancho de banda
DR con 10 modos: Gestión completa del ciclo de vida de failover
Restauración entre hipervisores: Conversión vSphere ↔ Hyper-V ↔ Proxmox/KVM
Protocolo DR con TLS: Seguridad production-ready
Escrito en Rust: Seguridad de memoria, alto rendimiento, FFI de cero sobrecarga con VDDK

Novedades de la Versión 1.4.1

Correcciones completas de integridad en la restauración — validadas contra ESXi 8.0.3 + Bacula 15.0.3 (job 6442 restauró 2.147 GB / 4 archivos en 6 s, 0 errores en FD; la VM Alpine 3.21 recreada arrancó correctamente):

Categoría	Corrección
🐛 Backup	Las rutas de archivo ya no se duplican (`@vsphere/@vsphere/disk-2000.vmdk` → `@vsphere/disk-2000.vmdk`).
🐛 Restauración	El prefijo `Where=` enviado por Bacula ahora se captura correctamente: un valor no vacío en Where dirige a restauración en sistema de archivos; vacío/`/` continúa hacia restauración en el hipervisor.
🐛 Restauración	Las entradas de directorio ya no terminan el bucle de comandos con un `EOD` espurio; los directorios se procesan correctamente.

Novedades de la Versión 1.3.0

Categoría	Funcionalidad
🔐 Seguridad	Cifrado TLS para el protocolo DR
🔐 Seguridad	Autenticación de token en tiempo constante
🌐 Red	Mapeo automático de red en el failover (ReconfigVM SOAP)
🌐 Red	Reconfiguración automática de IP en el failover (CustomizeVM SOAP)
📸 Recuperación	Puntos de restore basados en snapshot en la VM réplica
🔧 Operaciones	Apagado controlado mediante SIGTERM en modo daemon

2. Definición del Problema y Contexto de Mercado

El Desafío

Las organizaciones que utilizan VMware vSphere enfrentan desafíos críticos en la protección de datos:

Costo: El plugin vSphere de Bacula Enterprise cuesta $$$; Veeam, Commvault y Netbackup, aún más
Dependencia del Proveedor: Las soluciones de backup empresarial atan a los clientes a renovaciones perpetuas costosas
Brechas de Funcionalidad: PodHeitor Backup no tiene backup nativo para vSphere — solo agentes a nivel de sistema de archivos
Complejidad de DR: Configurar replicación y failover normalmente requiere productos separados
Multi-Hipervisor: Migrar entre vSphere, Hyper-V y KVM requiere conversión manual

La Solución

PodHeitor vSphere BRC elimina estos desafíos al ofrecer:

Cero licenciamiento Enterprise — funciona con PodHeitor Backup gratuito
Plugin todo-en-uno — backup, replicación y conversión unificados
Integración nativa con Bacula — utiliza configuración estándar de FileSet/Job/Schedule
DR automatizado — failover con un clic, con remapeo de red y reconfiguración de IP
Estándares abiertos — conversión VMDK, VHDX y QCOW2 entre hipervisores

3. Casos de Uso

Caso de Uso 1: Backup de VM VMware

Escenario: La organización necesita backup de VM a nivel de imagen con CBT para incrementales eficientes.

Job: Full backup Sunday, Incremental daily
RPO: 24 hours (backup) / minutes (replication)
RTO: Minutes (instant restore) to hours (full restore)

Caso de Uso 2: Recuperación ante Desastres

Escenario: Fallo del sitio de producción — necesidad de arrancar las VMs en el sitio de DR de inmediato.

Normal operation: CBT push every 5 minutes
Planned failover: Sync → graceful shutdown → boot replica
Unplanned failover: Boot replica immediately from last sync point
Failback: Reverse-replicate once production is restored

Caso de Uso 3: Migración entre Hipervisores

Escenario: Migración de VMware a Proxmox/KVM debido a cambios en el licenciamiento de Broadcom.

Backup: VMware VM → Bacula storage
Restore: Bacula → Proxmox (automatic VMDK→QCOW2 conversion)

Caso de Uso 4: Clonación de Entorno de Pruebas/Desarrollo

Escenario: Clonar VMs de producción en una red de pruebas aislada.

Mode: failover-test (non-destructive)
Network: Isolated test VLAN
Result: Production unaffected, test VM available

Caso de Uso 5: Cumplimiento Normativo y Backup Multi-Sitio

Escenario: Requisito regulatorio para copias de backup fuera del sitio principal.

Primary: Local backup to disk/tape
Secondary: CBT replication to remote DR site
Tertiary: Cross-restore to different hypervisor at third site

4. Arquitectura

Descripción General de Componentes

┌─────────────────────────────────────────────────────────────┐
│                     Bacula Director                          │
│  (Job scheduling, catalog, policy management)               │
└─────────────────┬───────────────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────────────┐
│                   Bacula File Daemon (FD)                    │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  podheitor-vsphere-fd.so (plugin FD, v1.4.1+)         │   │
│  │  • Loaded by Bacula FD via dlopen                    │   │
│││││  └──────────────────┬───────────────────────────────────┘   │
│                     │ stdin/stdout pipe                      │
│  ┌──────────────────▼───────────────────────────────────┐   │
│  │  podheitor-vsphere-backend (Rust binary)              │   │
│  │                                                       │   │
│  │  ┌─────────────────────────────────────────────────┐  │   │
│  │  │  Backup Module        │  Restore Module         │  │   │
│  │  │  • VADP workflow      │  • Full VM restore      │  │   │
│  │  │  • CBT tracking       │  • Single disk restore  │  │   │
│  │  │  • Snapshot lifecycle  │  • Cross-restore (VHDX) │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  Replication Module                             │  │   │
│  │  │  • CBT push (async replication)                 │  │   │
│  │  │  • Seed (initial full sync)                     │  │   │
│  │  │  • 10-mode failover lifecycle                   │  │   │
│  │  │  • TLS-encrypted DR protocol                    │  │   │
│  │  │  • DR receiver daemon                           │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  vSphere API Client                             │  │   │
│  │  │  • SOAP/XML over HTTPS                          │  │   │
│  │  │  • Property collector                           │  │   │
│  │  │  • Task manager                                 │  │   │
│  │  │  • ReconfigVM (net_map)                         │  │   │
│  │  │  • CustomizeVM (Re-IP)                          │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  VDDK Integration (FFI)                         │  │   │
│  │  │  • VixDiskLib_Open/Read/Write                   │  │   │
│  │  │  • QueryAllocatedBlocks                         │  │   │
│  │  │  • Transport: NBD, NBDSSL, HotAdd, SAN          │  │   │
│  │  └─────────────────────────────────────────────────┘  │   │
│  └───────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                  │                            │
                  ▼                            ▼
┌─────────────────────────┐  ┌─────────────────────────────┐
│   VMware vSphere API     │  │  DR Receiver (remote host)  │
│   (SOAP over HTTPS)      │  │  TLS-encrypted TCP          │
│   ESXi / vCenter         │  │  PSK authentication         │
└─────────────────────────┘  │  Snapshot management         │
                              │  Delta application           │
                              └─────────────────────────────┘

Flujo de Datos — Backup

1. Bacula FD invokes plugin
2. Plugin creates VM snapshot (quiesced)
3. VDDK opens VMDK via chosen transport
4. CBT provides changed block list (incremental)
5. Blocks streamed to Bacula SD via FD pipe
6. Snapshot deleted after backup
7. Job metadata stored in Bacula catalog

Flujo de Datos — Replicación CBT

1. Plugin queries CBT delta since last sync
2. Changed blocks read via VDDK
3. Delta sent to DR receiver via TLS-encrypted TCP
4. Receiver creates restore point snapshot on replica
5. Receiver writes delta to replica VMDK via VDDK
6. Replication state persisted to /var/lib/podheitor/replication/

Flujo de Datos — Failover

Planned Failover:
1. Final CBT sync (catch up)
2. Shutdown source VM
3. Apply net_map (ReconfigVM)
4. Apply Re-IP (CustomizeVM)
5. Power on replica
6. Update replication state

Unplanned Failover:
1. Apply net_map on replica
2. Apply Re-IP on replica
3. Power on replica immediately
4. (no final sync — uses last available restore point)

5. Funcionalidades — Backup

Backup Completo

Backup de VM a nivel de imagen mediante VMware VADP API
Snapshots con quiesce para consistencia de aplicación
Soporte para múltiples discos (todos los discos virtuales capturados)
Preservación de metadatos (configuración de VM, versión de hardware, sistema operativo invitado)

Backup Incremental

Changed Block Tracking (CBT) para backups incrementales eficientes
Solo se transfieren los bloques modificados — típicamente entre el 1 y el 5% del disco total
Reducción significativa de la ventana de backup y del almacenamiento requerido

Backup Diferencial

Captura todos los cambios desde el último backup completo
Útil en entornos con alta tasa de cambios

Modos de Transporte

Modo	Descripción	Caso de Uso
NBD	Network Block Device (sin cifrado)	Entornos de laboratorio/pruebas
NBDSSL	NBD con cifrado SSL	Uso estándar en producción
HotAdd	Conecta el VMDK directamente a la VM del FD	FD ejecutándose como VM en el mismo ESXi
SAN	Acceso directo por SAN al LUN del VMDK	Backup sin LAN, máximo rendimiento

Soporte para Múltiples VMs

Backup de múltiples VMs con Jobs separados
Filtros de inclusión/exclusión por host para operaciones masivas
Inclusión/exclusión de disco para backup selectivo

6. Funcionalidades — Replicación y Recuperación ante Desastres

Replicación Basada en CBT

Replicación asíncrona push mediante VMware CBT
RPO medido en minutos (intervalo de push configurable)
Eficiente en ancho de banda — solo se transmiten los bloques modificados
Limitación de ancho de banda opcional (max_bandwidth_mbps)

Ciclo de Vida DR con 10 Modos

#	Modo	Descripción	Destructivo	Impacto en Origen
1	`replication-status`	Consulta el estado de replicación y la última sincronización	No	Ninguno
2	`cbt-push`	Envía deltas CBT a la réplica	No	Ninguno
3	`seed`	Sincronización completa inicial del disco (crea réplica)	No	Ninguno
4	`failover-test`	Arranca la réplica en red aislada	No	Ninguno
5	`failover-undo`	Apaga la réplica de prueba	No	Ninguno
6	`failover-planned`	Sincroniza → apaga origen → arranca réplica	Sí	Apagado
7	`failover-unplanned`	Arranca la réplica de inmediato	No	Ninguno
8	`failover-permanent`	Convierte la réplica en producción	Sí	N/A
9	`failback`	Replica en sentido inverso de la réplica al origen	Sí	Restaurado
10	`reprotect`	Restablece la replicación en sentido directo	No	Ninguno

Mapeo de Red (net_map)

Reconfigura automáticamente las NICs de la VM en el failover
Mapea las redes de origen a las redes de destino en el sitio de DR
Utiliza la API SOAP ReconfigVM_Task de VMware
Se aplica en: failover planificado, no planificado y permanente

Reconfiguración de IP (Re-IP)

Configura automáticamente dirección IP, máscara, gateway y DNS en el failover
Utiliza la API SOAP CustomizeVM_Task de VMware (Personalización del SO Invitado)
Formato: "nic_index:ip/prefix:gateway:dns1,dns2"
Requiere VMware Tools en el sistema operativo invitado

Puntos de Restore

Se crea un snapshot en la réplica antes de cada aplicación de delta
Denominados PodHeitor_RP_<timestamp>
Retención configurable (dr_restore_points, valor predeterminado: 5)
Permite recuperación en un punto específico del tiempo desde la réplica

Daemon Receptor de DR

Modo daemon persistente para recibir datos replicados
Escucha en puerto TCP configurable (predeterminado: 9102)
Autenticación basada en PSK con comparación en tiempo constante
Manejador de apagado controlado mediante SIGTERM
Cifrado TLS (opcional, recomendado para producción)

7. Funcionalidades — Conversión entre Hipervisores

Conversiones Soportadas

Origen	Destino	Conversión de Formato
VMware vSphere (VMDK)	Hyper-V (VHDX)	Automática
VMware vSphere (VMDK)	Proxmox/KVM (QCOW2)	Automática
Hyper-V (VHDX)	VMware vSphere (VMDK)	Automática
Hyper-V (VHDX)	Proxmox/KVM (QCOW2)	Automática
Proxmox/KVM (QCOW2)	VMware vSphere (VMDK)	Automática

Cómo Funciona

El backup captura la VM a nivel de imagen (formato nativo VMDK)
Bacula almacena los datos de backup en su almacenamiento estándar
Durante la restauración, el plugin de destino detecta el hipervisor de origen
Conversión automática de formato (VMDK ↔ VHDX ↔ QCOW2)
La configuración de la VM se adapta al hipervisor de destino (hardware, controladores)

8. Arquitectura de Seguridad

Seguridad de Transporte

Backup: NBDSSL (cifrado SSL) o SAN (red de almacenamiento dedicada)
Protocolo DR: TLS 1.3 mediante rustls (cuando se configura certificado/clave)
API vSphere: HTTPS con validación de certificado

Autenticación

vSphere: Usuario/contraseña mediante SOAP SessionManager
Protocolo DR: Clave precompartida (PSK) con comparación en tiempo constante
Autenticación en tiempo constante: Comparación basada en XOR que previene ataques de temporización

Protección de Datos

Sin secretos almacenados en el código — credenciales mediante configuración de FileSet de Bacula
Tokens de autenticación de DR rotables sin reinicio del servicio
Rutas de certificado/clave TLS configurables mediante opciones del plugin

Funcionalidades de Cumplimiento

Registro estructurado (nivel + componente + mensaje)
Trazabilidad de auditoría mediante el catálogo de Bacula (historial de jobs, metadatos)
Persistencia del estado de replicación para verificación de cumplimiento de DR

9. Guía de Instalación

9.1 Requisitos Previos

Requisito	Detalles
SO (host del File Daemon)	Oracle Linux 9 / RHEL 9 / Rocky Linux 9 / AlmaLinux 9 — x86_64
Bacula	Community 15.0.x instalado y en ejecución en el mismo host
VDDK	Distribuido como RPM `podheitor-vixdisklib-runtime` — sin extracción manual de tar
Red	TCP 443 hacia ESXi/vCenter; TCP 9102 (predeterminado) entre el FD principal y el receptor de DR
VMware Tools	Instalado en las VMs invitadas (requerido para quiesce y Re-IP)
CBT	Habilitado en cada VM a proteger (ver §9.5)
Espacio en disco	≥ 500 MB libres para el binario del backend + runtime de VDDK; ver §13 para almacenamiento de backup

El host del File Daemon necesita salida TCP 443 hacia la API de ESXi/vCenter y, para replicación, salida TCP 9102 hacia el receptor de DR. No se requieren puertos de entrada en el FD principal.

9.2 Artefactos de la Versión

Todo se distribuye como RPMs firmados dentro de releases/:

Archivo	Propósito
`podheitor-vsphere-1.4.1-1.el9.x86_64.rpm`	Plugin FD (`.so`) + backend + directorios de estado CBT/replicación
`podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm`	Bibliotecas de runtime VMware VDDK 9.0.1, autocontenidas mediante RPATH `$ORIGIN`

Sin extracción de tar, sin ediciones manuales de ld.so.conf, sin exportaciones de LD_LIBRARY_PATH — todo eso es gestionado por los scriptlets %post de los RPMs.

9.3 Instalación estándar (RPM)

El orden no importa; cualquiera de los RPMs puede instalarse primero.

# 1. Plugin RPM
sudo rpm -Uvh releases/podheitor-vsphere-1.4.1-1.el9.x86_64.rpm

# 2. VDDK runtime RPM
sudo rpm -Uvh releases/podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm

# 3. Restart Bacula FD
sudo systemctl restart bacula-fd

El RPM del plugin instala:

Ruta	Contenido
`/opt/bacula/plugins/podheitor-vsphere-fd.so`	Plugin FD cargado por Bacula FD
`/opt/bacula/bin/podheitor-vsphere-backend`	Binario del backend
`/opt/bacula/working/podheitor/cbt/`	Estado CBT (change-ids por VM)
`/var/lib/podheitor/replication/`	Estado de replicación + metadatos de puntos de restore

El RPM del runtime VDDK instala:

Ruta	Contenido
`/usr/lib/vmware-vix-disklib/lib64/`	`libvixDiskLib.so*` + OpenSSL/curl/z incluidos (todos parcheados con `RPATH=$ORIGIN`)
`/usr/lib/vmware-vix-disklib/bin64/`	`vixDiskCheck`, `vmware-vdiskmanager`, `vddkReporter`
`/usr/lib/vmware-vix-disklib/include/`	Cabeceras VDDK (solo para desarrollo)
`/usr/lib/vmware-vix-disklib/doc/`	Documentación HTML de VDDK

9.4 Conflicto con OpenSSL 3.4.0 — prevención y recuperación

Los instaladores antiguos creaban /etc/ld.so.conf.d/vmware-vddk.conf apuntando a /usr/lib/vmware-vix-disklib/lib64. En hosts EL9 cuyo OpenSSL del sistema haya sido actualizado a una versión posterior a la 3.4.0, todos los binarios del sistema (rpm, dnf, flatpak, …) cargaban el libcrypto.so.3 (versión antigua) de VMware y fallaban con:

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

El RPM actual de podheitor-vixdisklib-runtime previene esto parcheando cada objeto compartido con RPATH=$ORIGIN en tiempo de compilación, de modo que VDDK encuentra sus dependencias sin ninguna directiva global en el cargador. El scriptlet %post también elimina entradas obsoletas:

/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
/etc/ld.so.conf.d/flatpak-vddk*.conf

Para recuperar un host ya dañado (que ni siquiera puede ejecutar dnf), ejecute — sin conexión es posible:

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
# Verify the system libcrypto is back in front:
ldconfig -p | grep 'libcrypto.so.3 .*=> /lib64'
# Then dnf/rpm/flatpak work again:
sudo dnf check-update

9.5 Habilitar Changed Block Tracking (CBT)

El CBT es obligatorio para los incrementales eficientes y para la replicación.

Mediante govc:

export GOVC_URL="https://root:<PASSWORD>@<ESXI_IP>/sdk"
export GOVC_INSECURE=true

govc vm.change -vm <VM_NAME> -e ctkEnabled=TRUE
govc vm.change -vm <VM_NAME> -e scsi0:0.ctkEnabled=TRUE
# Repeat for each virtual disk (scsi0:1, scsi0:2, …)

Mediante vSphere Client: VM → Editar Configuración → Opciones de VM → Avanzado → Parámetros de Configuración → establecer ctkEnabled=TRUE y scsi<N>:<M>.ctkEnabled=TRUE por disco, luego crear y eliminar un snapshot para materializar el change log.

9.6 Configurar Bacula

Agregue el directorio de plugins al FD (normalmente ya configurado):

# /opt/bacula/etc/bacula-fd.conf
FileDaemon {
  Name = vsphere-fd
  Plugin Directory = /opt/bacula/plugins
  Plugin Names = "podheitor-vsphere"
  ...
}

Luego agregue FileSets / Jobs / Schedules en el Director (ver §11 y §12). Reinicie ambos daemons:

sudo systemctl restart bacula-fd
sudo systemctl restart bacula-dir

9.7 Prueba de humo

# VDDK visible to the backend?
/opt/bacula/bin/podheitor-vsphere-backend --version
# Should print the build version and exit 0.

# Run a dry-run backup of a single VM:
echo "status" | bconsole
run job=Backup-<VM_NAME> yes
# watch progress:
status client=vsphere-fd

9.9 Desinstalar

sudo systemctl stop bacula-fd
sudo rpm -e podheitor-vsphere podheitor-vixdisklib-runtime
sudo systemctl start bacula-fd

Los directorios de estado (/opt/bacula/working/podheitor/, /var/lib/podheitor/) se conservan entre actualizaciones y se eliminan solo con una desinstalación completa mediante rpm -e.

10. Referencia de Configuración

Formato de la Plugin String

Plugin = "podheitor-vsphere: key1=value1 key2=value2 ..."

Todas las opciones pueden especificarse directamente en la directiva Plugin del FileSet.

Tabla Completa de Opciones — Backup

Opción	Tipo	Requerido	Predeterminado	Descripción
`host`	string	Sí	—	Nombre de host / IP del ESXi o vCenter
`username`	string	Sí	—	Nombre de usuario en vSphere
`password`	string	Sí	—	Contraseña de acceso a vSphere
`datacenter`	string	Sí	—	Nombre del objeto administrado del datacenter
`vm`	string	Sí	—	Nombre de la VM a proteger
`transport`	string	No	`nbdssl`	`nbd`, `nbdssl`, `hotadd`, `san`
`quiesce`	bool	No	`true`	Quiesce del sistema de archivos del invitado
`timeout`	int	No	`3600`	Tiempo de espera en segundos
`include_disk`	multi	No	todos	Incluir discos específicos
`exclude_disk`	multi	No	ninguno	Excluir discos específicos
`keep_cbt`	bool	No	`false`	Conservar CBT tras el backup
`abort_on_error`	bool	No	`false`	Abortar en el primer error
`snapshot_delete_delay`	int	No	`0`	Segundos de espera antes de eliminar el snapshot
`force_san`	bool	No	`false`	Forzar transporte SAN
`debug`	bool	No	`false`	Habilitar registro de depuración
`config_file`	string	No	—	Archivo de configuración externo

Tabla Completa de Opciones — Restauración

Opción	Tipo	Requerido	Predeterminado	Descripción
`new_vm_name`	string	No	original	Nombre de la VM restaurada
`power_on`	bool	No	`false`	Encender tras la restauración
`datastore`	string	No	original	Nombre del datastore de destino
`overwrite`	bool	No	`false`	Sobrescribir VM existente
`no_network`	bool	No	`false`	Desconectar NICs
`thin_provisioned`	bool	No	`false`	Usar aprovisionamiento thin de disco
`resource_pool`	string	No	predeterminado	Pool de recursos de destino
`network_name`	string	No	original	Red de destino
`guest_id_override`	string	No	auto	Reemplazar tipo de SO invitado
`hw_version`	string	No	auto	Reemplazar versión de hardware
`controller_type`	string	No	`auto`	`auto`, `ide`, `scsi`, `nvme`

Tabla Completa de Opciones — Replicación

Opción	Tipo	Requerido	Predeterminado	Descripción
`mode`	string	Sí	—	Modo de replicación (ver tabla de modos)
`dr_host`	string	Sí*	—	Nombre de host / IP del receptor de DR
`dr_port`	int	No	`9102`	Puerto TCP del receptor de DR
`dr_auth_token`	string	Sí*	—	Token de autenticación precompartido
`dr_restore_points`	int	No	`5`	Máximo de snapshots en la réplica
`dr_replica_datastore`	string	No	auto	Datastore para la réplica
`push_interval`	int	No	`300`	Intervalo de push (segundos)
`push_apply_remote`	bool	No	`true`	Aplicar deltas de forma remota
`max_retries`	int	No	`3`	Máximo de reintentos ante fallo
`retry_delay_sec`	int	No	`30`	Intervalo entre reintentos
`alert_after_failures`	int	No	`3`	Umbral para alerta
`net_map`	multi	No	—	Reglas de mapeo de red
`reip`	multi	No	—	Reglas de reconfiguración de IP
`storage_map`	multi	No	—	Reglas de mapeo de datastore
`max_bandwidth_mbps`	int	No	`0`	Límite de ancho de banda (0=ilimitado)
`test_failover_network`	string	No	—	Red de prueba aislada
`failover_vm`	string	No	auto	VM de destino en el failover
`dr_tls_cert`	string	No	—	Ruta del certificado TLS
`dr_tls_key`	string	No	—	Ruta de la clave privada TLS
`dr_tls_insecure`	bool	No	`false`	Aceptar certificados autofirmados

Requerido para los modos que se comunican con el receptor de DR (cbt-push, seed, failover-*, failback, reprotect).

11. Ejemplos de Configuración de Backup

Ejemplo 1: Backup Completo + Incremental Básico

# FileSet
FileSet {
  Name = "vSphere-Backup-VM1"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=production-web
              transport=nbdssl"
  }
}

# Full backup weekly, Incremental daily
Schedule {
  Name = "vSphere-Schedule"
  Run = Full sun at 02:00
  Run = Incremental mon-sat at 22:00
}

# Backup Job
Job {
  Name = "Backup-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Backup-VM1"
  Storage = File1
  Pool = File
  Schedule = "vSphere-Schedule"
  Messages = Standard
}

Ejemplo 2: Múltiples VMs

FileSet {
  Name = "vSphere-Backup-All"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=web-server
              transport=nbdssl"
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=db-server
              transport=nbdssl quiesce=true"
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=app-server
              transport=nbdssl"
  }
}

Ejemplo 3: Backup por SAN (sin LAN)

FileSet {
  Name = "vSphere-SAN-Backup"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=vcenter.prod.local username=admin@vsphere.local
              password=VcP@ss datacenter=Production vm=critical-db
              transport=san force_san=true"
  }
}

Ejemplo 4: Backup Selectivo de Disco

FileSet {
  Name = "vSphere-Selective"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=multi-disk-vm transport=nbdssl
              exclude_disk=Hard disk 3"
  }
}

Ejemplo 5: Restauración en Nueva VM

# bconsole commands
restore jobid=<BACKUP_JOBID> where=/
  # Then add these override options at the restore prompt:
  # podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
  #   datacenter=ha-datacenter new_vm_name=restored-vm power_on=yes
  #   datastore=datastore2 thin_provisioned=yes

12. Ejemplos de Configuración de Replicación

Ejemplo 1: Replicación CBT Push (Incremental)

# FileSet for CBT push
FileSet {
  Name = "vSphere-Repl-Push"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=cbt-push dr_host=192.168.2.50 dr_port=9102
              dr_auth_token=MySecureToken2026 dr_tls_insecure=yes"
  }
}

# Schedule: push every 15 minutes
Schedule {
  Name = "Repl-Push-15min"
  Run = Incremental hourly at 0:00
  Run = Incremental hourly at 0:15
  Run = Incremental hourly at 0:30
  Run = Incremental hourly at 0:45
}

# Job
Job {
  Name = "Replicate-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Repl-Push"
  Storage = File1
  Pool = File
  Schedule = "Repl-Push-15min"
}

Ejemplo 2: Seed Inicial

FileSet {
  Name = "vSphere-Seed"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=seed dr_host=192.168.2.50 dr_port=9102
              dr_auth_token=MySecureToken2026"
  }
}

Job {
  Name = "Seed-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Seed"
  Storage = File1
  Pool = File
}

Ejemplo 3: Failover Planificado con Mapeo de Red

FileSet {
  Name = "vSphere-Failover-Planned"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=failover-planned
              dr_host=192.168.2.50 dr_port=9102 dr_auth_token=MySecureToken2026
              net_map=Production_Network=DR_Network
              reip=0:192.168.2.10/24:192.168.2.1:8.8.8.8,8.8.4.4"
  }
}

Ejemplo 4: Receptor de DR

FileSet {
  Name = "vSphere-DR-Receiver"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.2.50 username=root password=DrP@ss
              datacenter=ha-datacenter vm=production-web-replica transport=nbdssl
              mode=dr-receiver dr_port=9102 dr_auth_token=MySecureToken2026
              dr_tls_cert=/etc/podheitor/tls/server.crt
              dr_tls_key=/etc/podheitor/tls/server.key"
  }
}

Ejemplo 5: Configuración Completa de DR

# === PRIMARY SITE (Production) ===

# 1. Initial seed
Job { Name = "Seed-WebVM"  ... FileSet = "vSphere-Seed" }

# 2. Continuous replication (every 5 min)
Job { Name = "Repl-WebVM"  ... FileSet = "vSphere-Repl-Push" Schedule = "Every5Min" }

# 3. Status check (hourly)
Job { Name = "Status-WebVM" ... FileSet = "vSphere-Status" Schedule = "Hourly" }

# === DR SITE (Standby) ===

# 4. DR Receiver (long-running)
Job { Name = "DR-Receiver"  ... FileSet = "vSphere-DR-Receiver" }

# === FAILOVER JOBS (manual trigger) ===

# 5. Test failover
Job { Name = "Test-Failover-WebVM" ... mode=failover-test }

# 6. Undo test
Job { Name = "Undo-Failover-WebVM" ... mode=failover-undo }

# 7. Planned failover (during maintenance window)
Job { Name = "Planned-Failover-WebVM" ... mode=failover-planned
      net_map=... reip=... }

# 8. Emergency failover
Job { Name = "Emergency-Failover-WebVM" ... mode=failover-unplanned
      net_map=... reip=... }

# 9. Permanent failover
Job { Name = "Permanent-Failover-WebVM" ... mode=failover-permanent
      net_map=... reip=... }

# 10. Failback (after production restored)
Job { Name = "Failback-WebVM" ... mode=failback }

# 11. Re-protect
Job { Name = "Reprotect-WebVM" ... mode=reprotect }

13. Manual de Usuario y Operaciones del Día a Día

Esta sección describe las tareas cotidianas que realiza el operador una vez instalado el plugin y agregados los FileSets de las secciones §11–§12 a bacula-dir.conf.

13.1 Comandos comunes de bconsole

Tarea	Comando (en `bconsole`)
Listar jobs de backup configurados	`show jobs`
Listar jobs de backup de un cliente	`list jobs client=vsphere-fd`
Ejecutar un job bajo demanda	`run job=Backup-Production-Web yes`
Ejecutar con nivel explícito	`run job=Backup-Production-Web level=Full yes`
Ver jobs en ejecución	`status client=vsphere-fd`
Monitorear mensajes	`messages`
Buscar archivos en el catálogo	`list files jobid=<JOBID>`
Cancelar un job bloqueado	`cancel jobid=<JOBID>`
Purgar y eliminar un backup	`delete jobid=<JOBID>`

13.2 Ejecutar un backup

echo "run job=Backup-Production-Web yes" | bconsole
# Then watch:
echo "status client=vsphere-fd" | bconsole
echo "messages" | bconsole

Para forzar un backup completo (p. ej., tras habilitar el CBT por primera vez):

run job=Backup-Production-Web level=Full yes

Tras el primer backup completo, los Incrementales posteriores solo transportarán los bloques modificados reportados por CBT (típicamente entre el 1 y el 5% del disco por día).

13.3 Restaurar una VM (interactivo)

* restore
Select item:  5 (Select the most recent backup for a client)
Defined Clients:
  1: vsphere-fd
Select Client (File Daemon) resource:  1
The defined FileSet resources are:
  1: vSphere-Backup-VM1
Select FileSet:  1
... bconsole picks the latest Full + chain of Incrementals
... it then drops you into the file selection tree.
$ mark *
$ done
Run Restore job
   JobName:    RestoreFiles
   Bootstrap:  /opt/bacula/working/...
   Where:      /tmp/bacula-restores
   Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
   ...
   12: Plugin Options
Select parameter to modify (1-13): 12
Please enter a Plugin Options string: podheitor-vsphere: 
        host=192.168.1.100 username=root password=MyP@ss 
        datacenter=ha-datacenter new_vm_name=production-web-restored 
        datastore=datastore2 thin_provisioned=yes power_on=yes
OK to run? (yes/mod/no): yes

El plugin reutiliza la versión de hardware original de la VM, el tipo de adaptador de red y el SO invitado, a menos que se reemplacen mediante hw_version, network_name, guest_id_override o controller_type.

13.4 Restauración de disco único

Use include_disk (o exclude_disk) en la Plugin string de restauración para restringir qué VMDK se restaura:

podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss 
        datacenter=ha-datacenter new_vm_name=onlydata 
        include_disk="Hard disk 2" datastore=datastore2 power_on=no

13.5 Restauración entre hipervisores (vSphere → Proxmox / Hyper-V)

La restauración entre hipervisores es simplemente una restauración regular dirigida a un host que no es VMware. La conversión de formato (VMDK ↔ VHDX ↔ QCOW2) es automática — ver §7.

# Restore a VMware backup onto a Proxmox host (FD running on PVE node)
restore client=proxmox-fd jobid=<BACKUP_JOBID>
   Plugin Options: podheitor-proxmox: node=pve1 storage=local-lvm 
                   new_vm_name=migrated-web vmid=120 power_on=no

13.6 Flujo de operaciones del día a día en replicación

Una vez finalizado el seed (modo seed) y con un job recurrente en modo cbt-push, la replicación es completamente automática. Las operaciones del día a día son:

Operación	Cuándo	bconsole
Verificar estado	En cualquier momento	`run job=Status-WebVM yes`
Probar failover (no destructivo)	Simulacro de DR	`run job=Test-Failover-WebVM yes`
Deshacer prueba	Tras el simulacro	`run job=Undo-Failover-WebVM yes`
Failover planificado	Ventana de mantenimiento	`run job=Planned-Failover-WebVM yes`
Failover no planificado	Interrupción	`run job=Emergency-Failover-WebVM yes`
Failover permanente	Migración definitiva	`run job=Permanent-Failover-WebVM yes`
Failback al origen	Origen restaurado	`run job=Failback-WebVM yes`
Reproteger (reiniciar replicación directa)	Tras el failback	`run job=Reprotect-WebVM yes`

13.7 Ciclo de vida del daemon receptor de DR

El receptor de DR se ejecuta como un job de larga duración (mode=dr-receiver) en el Bacula FD del sitio de DR. Configuración recomendada:

Job {
  Name = "DR-Receiver-Always-On"
  Type = Backup
  Client = vsphere-dr-fd
  FileSet = "vSphere-DR-Receiver"
  Schedule = "Boot"          # starts on FD boot
  Max Run Sched Time = 0     # never time out
  Allow Duplicate Jobs = no
  Reschedule On Error = yes
  Reschedule Interval = 60
  Reschedule Times = 0       # forever
}

SIGTERM (p. ej., bconsole: cancel jobid=<n>) desencadena un apagado controlado — los deltas en curso se vacían y el bloqueo de snapshot en la réplica se libera antes de la salida.

13.8 Certificados TLS para el protocolo DR

Para producción, genere un certificado de servidor para el host receptor de DR:

openssl req -x509 -newkey rsa:4096 -nodes -days 3650 
    -keyout /etc/podheitor/tls/server.key 
    -out    /etc/podheitor/tls/server.crt 
    -subj   "/CN=vsphere-dr-fd.dr.local"
chmod 600 /etc/podheitor/tls/server.key

Referencie ambos archivos mediante dr_tls_cert= y dr_tls_key= en el FileSet con mode=dr-receiver, y elimine dr_tls_insecure=yes en el lado emisor una vez que el certificado sea de confianza.

13.9 Rotación de token

Los tokens se leen de la Plugin string al inicio del job, por lo que la rotación es:

Genere un nuevo token (openssl rand -hex 32).
Actualice ambas cadenas dr_auth_token= (FileSets del emisor y del receptor).
bconsole: reload.
Cancele el job del receptor de DR en ejecución — Bacula lo reprogramará

automáticamente (según §13.7) y el nuevo token entrará en vigor.

13.10 Ubicación de los registros

Archivo	Contenido
`/opt/bacula/working/bacula-fd.log`	Registro del Bacula FD (salida del plugin multiplexada)
`/opt/bacula/working/podheitor/cbt/<vm>.json`	Change-IDs CBT por VM
`/var/lib/podheitor/replication/<vm>.json`	Estado de replicación, hora de la última sincronización, puntos de restore
`journalctl -u bacula-fd -e`	stderr capturado por systemd

Agregue debug=true a una Plugin string para trazado detallado del backend (enviado al registro del Bacula FD).

14. Dimensionamiento y Requisitos

Requisitos de Hardware

Componente	Mínimo	Recomendado	Alto Rendimiento
CPU	2 núcleos	4 núcleos	8+ núcleos
RAM	4 GB	8 GB	16+ GB
Disco (FD)	20 GB	50 GB	100+ GB
Red	1 Gbps	10 Gbps	25 Gbps

Dimensionamiento de Almacenamiento

Escenario	Estimación
Backup completo	~1:1 con datos usados (compresión por Bacula SD)
Incremental	Entre 1 y 5% del disco total por día (típico)
Réplica	Igual al tamaño del disco de la VM de origen
Puntos de restore	~1 a 5% por snapshot (depende de la tasa de cambios)

Ancho de Banda de Red

Escenario	Ancho de Banda Necesario
Backup diario (VM de 100 GB)	~5 GB incremental → ~11 Mbps sostenidos
Replicación (VM de 100 GB, RPO de 5 min)	~100 MB/intervalo → ~3 Mbps sostenidos
Seed completo (VM de 100 GB)	100 GB → ~2,2 horas a 100 Mbps

Límites de VMs Simultáneas

Configuración	Máximo Recomendado
2 CPU / 4 GB RAM	2 a 3 VMs simultáneas
4 CPU / 8 GB RAM	5 a 10 VMs simultáneas
8 CPU / 16 GB RAM	15 a 20 VMs simultáneas

15. Matriz de Compatibilidad

Compatibilidad con VMware

Componente	Versión	Probado	Notas
ESXi	7.0	✅	Todos los niveles de actualización
ESXi	8.0	✅	Todos los niveles de actualización
ESXi	8.0U3e	✅	Plataforma de prueba principal
vCenter	7.0	✅	Opcional — ESXi standalone soportado
vCenter	8.0	✅	Opcional
VDDK	8.0.x	✅	Mínimo recomendado
VDDK	9.0.1	✅	Plataforma de prueba principal

Compatibilidad de Sistema Operativo (Servidor FD)

SO	Versión	Probado	Notas
Oracle Linux	9.x	✅	Plataforma de prueba principal (9.5)
RHEL	9.x	✅	Mismo binario que OL9
Rocky Linux	9.x	✅	Mismo binario que OL9
AlmaLinux	9.x	✅	Mismo binario que OL9

Compatibilidad con Bacula

Componente	Versión	Probado
PodHeitor Backup	15.0.3	✅
PodHeitor Backup	15.0.x	Compatible esperado

Soporte de SO Invitado

SO Invitado	Backup	Restauración	Quiesce	CBT	Re-IP
Linux (cualquier)	✅	✅	✅*	✅	✅*
Windows Server	✅	✅	✅*	✅	✅*
Windows 10/11	✅	✅	✅*	✅	✅*
FreeBSD	✅	✅	⚠️	✅	❌
Otros	✅	✅	⚠️	✅	❌

*Requiere VMware Tools instalado en el invitado.

16. Resultados de Pruebas

Entorno de Prueba

Componente	Detalles
ESXi	8.0U3e, standalone, IP 192.168.15.91
Servidor FD	Oracle Linux 9.5, Bacula 15.0.3
VDDK	9.0.1
VMs de Prueba	Alpine (381 MB), TinyCore, CirrOS, Multi-Disk

Pruebas de Backup y Restauración

#	Prueba	Resultado	Detalles
1	Backup completo (NBDSSL)	✅ APROBADO	Las 4 VMs
2	Backup incremental (CBT)	✅ APROBADO	Solo bloques modificados
3	Restauración completa de VM	✅ APROBADO	Nombre original + nuevo nombre
4	Restauración en datastore diferente	✅ APROBADO	Thin provisioned
5	Restauración entre hipervisores (vSphere → Hyper-V)	✅ APROBADO	VMDK → VHDX
6	Restauración entre hipervisores (Hyper-V → vSphere)	✅ APROBADO	VHDX → VMDK

Pruebas de Replicación (20 de abril de 2026)

#	Prueba	JobId	Estado	Datos
1	Estado de Replicación	881	✅ T	870 B
2	CBT Push (Incremental)	882	✅ T	377 MB
3	Prueba de Failover	883	✅ T	137 B
4	Deshacer Failover	884	✅ T	137 B
5	Failover Planificado	885	✅ T	140 B
6	Deshacer Failover (2)	887	✅ T	137 B
7	Failover No Planificado	889	✅ T	142 B
8	Failover Permanente	892	✅ T	142 B
9	Seed (Sincronización Completa)	893	✅ T	377 MB
10	Failback	894	✅ T	2,1 GB
11	Reprotect	895	✅ T	1.795 B
12	Estado Final	897	✅ T	870 B

Resultado: 12/12 pruebas APROBADAS — 100% de tasa de éxito

Matriz de Validación de Restauración (v1.4.1, 29 de abril de 2026)

Laboratorio de ruta de restauración de extremo a extremo en ESXi 8.0.3 (192.168.15.91, sin vCenter) + Bacula 15.0.3 FD/SD/Director (192.168.15.105). VM de origen vm-alpine1 (Alpine 3.21, ext4 con SYSLINUX VBR; snapshot en vivo).

#	Ruta	JobId	Resultado	Notas
1	Backup completo (NBDSSL + habilitación CBT)	6425	✅ T	changeId persistido: `…/85`
2	Completo → restauración en sistema de archivos (`Where=/tmp/restore`)	6427	✅ T	4 archivos / 2,147 GB / 6 s, 0 errores en FD
3	Integridad de bytes del VMDK restaurado	—	✅	`mount -o ro,loop,noload`; `/etc/alpine-release = 3.21.0`
4	Backup incremental (CBT)	6429	✅ T	changeId persistido: `…/86`
5	Incremental → restauración en sistema de archivos	6431	✅ T	coincide byte a byte con la restauración completa
6	Seguridad en restauración del hipervisor (VM de origen existe)	6434/6435	✅ rechazado	«VM already exists; use overwrite=yes or different `where` name»
7	Backup con `new_vm_name=vm-alpine1-restored` incluido	6440	✅ T	Plugin string congelada en el catálogo
8	Restauración en hipervisor (recreación en ESXi vía NBD/SSL)	6442	✅ T	moref=71 creado, VMDK cargado
9	Encendido / arranque de la VM recreada	—	✅	`bootTime` establecido, `uptimeSeconds=118`, CPU 29 MHz, mem 220 MB

Resultado: 9/9 rutas APROBADAS. Las tres correcciones de v1.4.1 (duplicación de ruta, captura de Where=, EOD del writer de directorio) confirmadas contra carga de trabajo real.

17. Comparativa con Soluciones Empresariales

Comparativa de Funcionalidades

Funcionalidad	PodHeitor BRC	Bacula Enterprise	Veeam B&R	Commvault
Backup a Nivel de Imagen	✅	✅	✅	✅
Soporte CBT	✅	✅	✅	✅
Incremental	✅	✅	✅	✅
Transporte SAN	✅	✅	✅	✅
Restauración Completa de VM	✅	✅	✅	✅
Restauración de Disco Único	✅	✅	✅	✅
Entre Hipervisores	✅	❌	⚠️	⚠️
Replicación de VM	✅	❌	✅	✅
Failover de DR	✅ (10 modos)	❌	✅	✅
Mapeo de Red	✅	❌	✅	✅
Re-IP en Failover	✅	❌	✅	✅
Protocolo DR con TLS	✅	N/A	✅	✅
PodHeitor Backup	✅	❌	N/A	N/A
Costo	$$	$$$$	$$$$$	$$$$$

Ventaja de Costo

Traiga su cotización o propuesta de renovación de Bacula Enterprise, Veeam, Commvault o Netbackup. Garantizamos al menos un 50% de descuento, con muchas más funcionalidades.

18. Resolución de Problemas

18.1 `OPENSSL_3.4.0 not found` desde rpm / dnf / flatpak

Causa: una entrada heredada en /etc/ld.so.conf.d/ está forzando a todos los procesos a cargar el antiguo libcrypto.so.3 de VMware. Consulte §9.4 para la recuperación con un solo comando.

18.2 `libvixDiskLib.so not found in standard paths`

El backend busca en:

/usr/lib/vmware-vix-disklib/lib64
/usr/lib64/vmware-vix-disklib
/opt/bacula/lib/vix

Si el RPM del runtime VDDK está instalado, la ruta #1 contendrá libvixDiskLib.so. Si instaló VDDK manualmente en una ubicación inusual, establezca la variable de entorno VDDK_LIB_PATH=/ruta/completa/libvixDiskLib.so en la unidad de servicio del FD:

sudo systemctl edit bacula-fd
# add:
# [Service]
# Environment=VDDK_LIB_PATH=/opt/vddk/lib64/libvixDiskLib.so
sudo systemctl daemon-reload && sudo systemctl restart bacula-fd

18.3 El backup se ejecuta pero produce 0 bytes en Incremental

El CBT no está habilitado o fue reiniciado. Verifique:

govc vm.info -vm.ipath /ha-datacenter/vm/<VM_NAME> | grep -i ctk
# Must show ctkEnabled = true

Luego cree y elimine un snapshot para materializar el change log, y ejecute un nuevo backup completo.

18.4 `dlopen(libvixDiskLib.so): symbol lookup error`

El .so de VDDK no encontró una de sus dependencias (libcrypto.so.3, libssl.so.3, libcurl.so.4, …). Confirme que el RPATH fue aplicado:

readelf -d /usr/lib/vmware-vix-disklib/lib64/libvixDiskLib.so.9 | grep PATH
# Expected:
#   0x0000000000000001 (RUNPATH)            Library runpath: [$ORIGIN]

Si falta, reinstale podheitor-vixdisklib-runtime — el %install del RPM aplica patchelf --set-rpath '$ORIGIN' a cada .so en lib64/.

18.5 El delta de replicación se aplica pero la VM no arranca tras el failover

Verifique que net_map= / reip= en el FileSet de failover apunten a redes e IPs que realmente existen en el sitio de DR. Un port group no mapeado hace que VMware desconecte silenciosamente la NIC en el arranque.

18.6 «Authentication failed» en el receptor de DR

dr_auth_token= debe ser idéntico byte a byte en el emisor y en el receptor. La comparación se realiza en tiempo constante (basada en XOR) para prevenir ataques de temporización, por lo que la única forma de fallar es una discrepancia real. Si rotó el token recientemente, consulte §13.9.

18.7 Los backups son lentos o se quedan en `connecting`

Verifique el transporte:

nbdssl sobre WAN con alta latencia — cambie a san si es posible,

o hotadd si el FD es una VM en el mismo clúster ESXi.

Firewall entre el FD y ESXi — el puerto NBD (902) debe estar abierto

además del 443 al usar nbd / nbdssl.

Licenciamiento

PodHeitor vSphere BRC 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?

💬 WhatsApp: +1 (786) 726-1749
✉️ Email: heitor@opentechs.lat
🩺 Diagnóstico gratuito — 30 min con Heitor Faria

19. Licenciamiento y Contacto

Licencia

Este software es propietario. Todo el código fuente, binarios y documentación son propiedad exclusiva de Heitor Faria. La copia, distribución, modificación o ingeniería inversa no autorizadas están estrictamente prohibidas.

Contacto

Heitor Faria

📧 Email: heitor@opentechs.lat
📱 Teléfono: +1 786 726-1749
📱 WhatsApp: +55 61 98268-4220

Consultas Comerciales

Para precios, licenciamiento, prueba de concepto y demostraciones técnicas, contáctenos directamente. Descuentos por volumen y acuerdos plurianuales disponibles.

Oferta Especial: Traiga su cotización o propuesta de renovación existente de Bacula Enterprise, Veeam, Commvault o Netbackup. Garantizamos al menos un 50% de descuento, con muchas más funcionalidades.

PodHeitor vSphere BRC Plugin — Whitepaper v1.4.1 — Abril 2026 VMware, vSphere, ESXi, VADP, VDDK son marcas comerciales de Broadcom/VMware. Bacula es marca comercial de Kern Sibbald. Todas las demás marcas son propiedad de sus respectivos dueños.

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