Blog

Acceso directo a VHDX sin Export-VM, change tracking vía RCT (Resilient Change Tracking), replicación RCT-Push near-CDP, conversión cross-hypervisor (vSphere/Proxmox → Hyper-V) y arquitectura multi-adapter.

Documento técnico complementario a la página del plugin PodHeitor Hyper-V.

1. Problema: backup de Hyper-V sin plugin es caro o frágil

Las VMs Hyper-V en producción presentan tres problemas fundamentales para Bacula stock:

• VHDX bloqueado mientras la VM corre — la lectura directa del archivo es imposible sin production checkpoint. Bacula stock no lo sabe.
• Export-VM duplica el storage — exigir un Export-VM antes del backup duplica la flota en disco y no escala.
• Sin change tracking nativo en Bacula — todo «incremental» degrada a re-leer el VHDX completo. 2 GB modificados en 100 GB de disco se vuelven 100 GB transferidos.

El PodHeitor Hyper-V Plugin ataca los tres problemas con lectura in-place del VHDX (cero staging adicional), RCT block-level vía WMI, y replicación delta near-CDP a sitios secundarios.

2. Modelo arquitectural

El plugin usa el patrón PodHeitor de cdylib + backend standalone, con PTCOMM en stdin/stdout. En Windows el cdylib es una DLL (podheitor-hyperv-fd.dll) cargada por bacula-fd, y el backend es podheitor-hyperv-backend.exe.

Bacula FD (Windows)
  └─ podheitor-hyperv-fd.dll  (metaplugin adapter)
       │  PTCOMM (stdin/stdout)
       ▼
     podheitor-hyperv-backend.exe (Rust)
       ├─ Get-VM / Checkpoint-VM (PowerShell + WMI)
       ├─ Msvm_VirtualSystemReferencePointService (RCT API)
       ├─ Direct VHDX reader (no Export-VM)
       ├─ CBT delta encoder (proprietary binary format)
       ├─ RCT-Push replication driver
       └─ Cross-hypervisor convert (qemu-img.exe wrapper)

2.1 Diseño multi-adapter

Un único backend engine atiende múltiples DLLs cdylib, cada una con un namespace Bacula distinto:

Operacionalmente: un único host Bacula FD puede ser destino de migración de cualquier hypervisor — sin reaprovisionamiento, sin instalar tres productos diferentes.

3. Direct VHDX + RCT — por qué importa

4. RCT — Resilient Change Tracking

RCT es la API nativa de Microsoft (Windows Server 2016+) para change tracking de discos virtuales. El plugin la consume vía WMI:

• Los reference points son marcadores persistentes (sobreviven al reboot del host Hyper-V) registrados en Msvm_VirtualSystemReferencePointService.
• En cada incremental/diferencial, el plugin pide a Hyper-V el diff entre dos reference points y recibe la lista de extents {offset, length} que cambiaron.
• El plugin lee sólo esos extents del VHDX y los empaqueta en el formato CBT delta propietario (binary stream con header de offset).
• En restore, el cdylib aplica los deltas en orden cronológico sobre la base full.

Cuando RCT no está disponible (gen 1 legacy, host antiguo), el plugin cae automáticamente a full streaming del VHDX en vez de fallar — comportamiento documentado como Gen1 fallback.

5. Replicación RCT-Push (near-CDP)

Configurado con mode=rct-push, el plugin ejecuta ciclos continuos de replicación directa a un host Hyper-V secundario, sin pasar por Bacula SD en cada ciclo.

Con push_apply_remote=yes, el canal va directo del FD source al DR, sin paso por el Storage Daemon Bacula — útil cuando el objetivo es puramente DR y no retención centralizada. Con =no, los deltas van por el SD (catalogados) y se reaplican en el DR en el próximo ciclo.

6. Conversión cross-hypervisor (vSphere / Proxmox → Hyper-V)

Restore de VMs hechas por otros plugins PodHeitor directamente en Hyper-V — sin reconversión manual de disco.

La traducción de configuración de la VM (adaptadores de red, orden de boot, detección Gen1/Gen2) es automática. Prerrequisito: qemu-img.exe en %BACULA_DIR%tools o en el %PATH%; espacio temporal ~1,5× el tamaño comprimido de la VM.

7. Granular restore (file-level)

Compatible con PodHeitor Granular Restore:

1. Browse en el catálogo Bacula (BVFS) para localizar archivos VHDX de la VM.
2. Restore sólo del VHDX base + CBT deltas relevantes al Storage Daemon.
3. Reconstrucción del estado completo del disco aplicando CBT deltas sobre el VHDX base.
4. Mount del filesystem guest (NTFS, ext4, XFS, etc.) vía libguestfs o qemu-nbd.
5. Browse y extracción de archivos individuales.

8. Plataformas validadas

9. Anti-patterns documentados

• No deshabilites quiesce en VMs con app stateful. Sin VSS quiesce el snapshot es crash-consistent — el restore puede bootear, pero las DBs pueden necesitar recovery.
• No corras dos plugins concurrentes contra la misma VM. Los reference points RCT son globales por-VM; la concurrencia genera reference-point churn.
• No confíes en RCT en VMs Gen1 u hosts < Windows Server 2016. El plugin hace fallback transparente a full VHDX streaming, pero el operador debe saberlo para dimensionar bandwidth/storage.

10. Postura de licencia

Plugin bajo LicenseRef-PodHeitor-Proprietary. Ningún source AGPLv3 de Bacula se vincula estáticamente a la DLL cdylib. El binding es vía crate bacula-fd-abi (puro PodHeitor) con declaraciones extern "C" independientes.

¿Listo para evaluar?

Trial gratuito de 30 días para flotas Hyper-V en producción. Garantizamos al menos 50% de descuento vs Bacula Enterprise, Veeam o Commvault, con más funcionalidades incluidas.

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

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