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

Respaldo Hyper-V a escala corporativa. Snapshots VSS coordinados, CBT nativo, restauración granular de archivo, soporte completo Cluster Shared Volumes (CSV).

VSS application-consistent — Microsoft VSS writer coordinado para Exchange, SQL, AD dentro de la VM.
RCT (Resilient Change Tracking) — incrementales reales sin hashing global.
CSV-aware — respaldo correcto en Failover Cluster sin migrar la VM.
Restore granular de archivos — monte el VHDX del snapshot, recupere lo necesario.
Restore cross-host — recupere a otro host Hyper-V, standalone o cluster.

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 →

Whitepaper Técnico — Versión 1.2.0

Autor: Heitor Faria Organización: OpenTechs Contacto: heitor@opentechs.lat | +1 786 726-1749 | +55 61 98268-4220 (WhatsApp) Copyright: © 2026 Heitor Faria — Todos los Derechos Reservados

💼 Oportunidad Comercial

Traiga su propuesta de renovación de cualquier plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup u otras. Ofrecemos al menos un 50% de descuento con muchas más funcionalidades.

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

Tabla de Contenidos

Resumen Ejecutivo
Problema de Negocio y Casos de Uso
Arquitectura de la Solución
Análisis Técnico en Profundidad
Funcionalidades de Backup y Restauración
Funcionalidades de Replicación
Conversión entre Hipervisores
Instalación e Implementación
Dimensionamiento y Planificación de Capacidad
Compatibilidad de Plataforma
Referencia de Configuración
Ejemplos de FileSet y Job
Consideraciones de Seguridad
Benchmarks de Rendimiento
Comparativa Competitiva
Hoja de Ruta de Desarrollo

1. Resumen Ejecutivo

PodHeitor Hyper-V Plugin es una solución de arquitectura abierta y calidad productiva que extiende PodHeitor Backup Edition con protección de VMs de clase empresarial para entornos Microsoft Hyper-V. Construido íntegramente en Rust para seguridad de memoria y rendimiento nativo, ofrece tres capacidades críticas en un único paquete integrado:

Backup y Restauración — Backup de VM a nivel de bloque y consistente con las aplicaciones mediante Resilient Change Tracking (RCT). Sin tiempo de inactividad de la VM. Sin espacio en disco adicional. Incremental/diferencial verdadero con tecnología de delta CBT.

Replicación — Protección de datos near-CDP mediante replicación RCT-Push a sitios secundarios. RPO configurable desde minutos hasta horas. Transporte de delta cifrado. Puntos de referencia persistentes para ciclos incrementales eficientes.

Conversión — Soporte para migración entre hipervisores. Restaure VMs respaldadas desde VMware vSphere o Proxmox/KVM directamente en Hyper-V con conversión automática de formato de disco y traducción de configuración de VM.

La versión 1.2.0 representa un lanzamiento completamente validado y listo para producción, con funcionalidad confirmada en Windows Server 2016 y 2025 con Bacula FD 15.0.3.

Principales Beneficios de Negocio

Beneficio	Detalle
Cero costos adicionales de licenciamiento	Funciona con PodHeitor Backup Edition (gratuito, código abierto)
Reducción de costos superior al 50% frente a competidores	Comparado con plataformas comerciales de backup empresarial
Sin agente en las VMs invitadas	El backup se ejecuta completamente en el host Hyper-V
Sin espacio en disco adicional	Lectura directa de VHDX — sin exportación, sin área de preparación
Replicación near-CDP	Ciclos RCT-Push tan frecuentes como cada 5 minutos
Migración multiplataforma	VMs de VMware/Proxmox → Hyper-V con un solo comando
Rendimiento impulsado por Rust	Seguridad de memoria, abstracciones sin sobrecarga, velocidad nativa

2. Problema de Negocio y Casos de Uso

2.1 El Desafío: Protección de VMs a Escala

Los entornos de TI modernos dependen de las máquinas virtuales para todo, desde controladores de dominio hasta servidores de base de datos. Proteger estas VMs requiere:

Consistencia — Los backups deben capturar un estado consistente de la VM, no una mezcla de estados de disco de diferentes momentos en el tiempo.
Eficiencia — Recopiar la VM completa en cada backup es impracticable para discos de gran tamaño. El incremental debe ser verdaderamente a nivel de bloque.
Velocidad — Las ventanas de backup se están reduciendo. Los requisitos de RTO exigen una restauración rápida y confiable.
Flexibilidad — Los escenarios de DR requieren replicación de VMs y la capacidad de migrar cargas de trabajo entre hipervisores.

2.2 Casos de Uso

Caso de Uso 1: Backup Diario de VMs con Incrementales RCT

Una PYME ejecuta 20 VMs en un clúster Hyper-V con Windows Server 2022. Su equipo de TI necesita:

Backup completo nocturno, incrementales por hora
Backup consistente con las aplicaciones para VMs de SQL Server y Exchange
Restauración rápida de VMs individuales sin restaurar todo el entorno

Solución PodHeitor: vm=* en FileSet con quiesce=yes. Completo el domingo, incremental por hora. RCT rastrea los bloques modificados — solo se transfiere entre el 2–5% de los datos del disco en cada incremental.

Caso de Uso 2: Replicación near-CDP a Sitio de DR

Una institución financiera requiere un RPO < 15 minutos para sus VMs de base de datos críticas. Su sitio principal ejecuta Hyper-V; su sitio de DR es un clúster Hyper-V secundario conectado mediante un enlace WAN.

Solución PodHeitor: mode=rct-push rpo_seconds=600 push_apply_remote=no. El job RCT-Push se ejecuta cada 10 minutos, transfiriendo solo los bloques modificados (4–20 MB por ciclo para VMs de base de datos activas). El Bacula SD en el sitio de DR almacena todos los puntos de restauración.

Caso de Uso 3: Migración a la Nube o entre Hipervisores

Una empresa está migrando de VMware vSphere a Hyper-V. Tiene 50 VMs respaldadas por el plugin PodHeitor vSphere y necesita incorporarlas a Hyper-V.

Solución PodHeitor: Instale podheitor-vsphere-fd.dll junto al plugin de Hyper-V. Cree Jobs de restauración con FileSet apuntando al espacio de nombres @vsphere/. El backend convierte automáticamente VMDK → VHDX y registra las nuevas VMs en Hyper-V.

Caso de Uso 4: Recuperación ante Ransomware

Una empresa manufacturera es afectada por ransomware un lunes por la mañana. Su VM de producción (sistema ERP) está cifrada. Necesitan restaurar al backup del sábado en menos de 30 minutos.

Solución PodHeitor: restore client=hyperv-fd restorejob=HyperV-Restore jobid=<last_full_id> all done yes. El plugin transmite el VHDX y los deltas CBT desde el Bacula SD, aplica los deltas durante la restauración y registra la VM en Hyper-V automáticamente. La VM arranca y queda operativa en minutos.

Caso de Uso 5: Reducción de Costos — Migración desde backup comercial premium

Una empresa de 500 usuarios paga US$ 80.000/año por Veeam Enterprise Plus. Su director de TI quiere reducir costos manteniendo los SLAs.

Solución PodHeitor: Migre a PodHeitor Backup + plugin PodHeitor. Funcionalidades comparables (backup a nivel de bloque, replicación, conversión entre hipervisores) a una fracción del costo.

3. Arquitectura de la Solución

3.1 Descripción General de Componentes

┌─────────────────────────────────────────────────────────────────────┐
│                         Bacula Director                              │
│  (Linux — schedules jobs, manages catalog, orchestrates all tasks)   │
└───────────────────────┬─────────────────────────────────────────────┘
                        │
              Job schedule + control
                        │
         ┌──────────────▼──────────────────────┐
         │       Bacula File Daemon (FD)        │
         │       (Windows Server — Hyper-V)      │
         │                                      │
         │  ┌─────────────────────────────────┐ │
         │  │  podheitor-hyperv-fd.dll         │ │
         │  │  (plugin FD adapter)             │ │
         │  │                                  │ │
         │  │  Delegates ALL logic via internal │ │
         │  │  channel (stdin/stdout)          │ │
         │  └──────────────┬──────────────────┘ │
         │                 │ internal channel    │
         │  ┌──────────────▼──────────────────┐ │
         │  │  podheitor-hyperv-backend.exe    │ │
         │  │  (Rust — core engine)            │ │
         │  │                                  │ │
         │  │  • Hyper-V WMI/PS integration   │ │
         │  │  • Direct VHDX I/O              │ │
         │  │  • RCT change tracking          │ │
         │  │  • CBT delta engine             │ │
         │  │  • RCT-Push replication         │ │
         │  │  • Cross-hypervisor conversion  │ │
         │  │  • VHDX integrity verification  │ │
         │  └──────────────┬──────────────────┘ │
         └─────────────────┼───────────────────┘
                           │ WMI / Direct file I/O
              ┌────────────▼──────────────────────────┐
              │           Hyper-V Host                 │
              │  ┌────────┐  ┌────────┐  ┌────────┐   │
              │  │  VM-1  │  │  VM-2  │  │  VM-N  │   │
              │  │ (VHDX) │  │ (VHDX) │  │ (VHDX) │   │
              │  └────────┘  └────────┘  └────────┘   │
              │                                        │
              │  RCT: Msvm_VirtualSystem               │
              │       ReferencePointService            │
              └───────────────────────────────────────┘
                           │ network (SD port 9103)
              ┌────────────▼──────────────────────────┐
              │         Bacula Storage Daemon          │
              │  (Linux — stores backup data on disk)  │
              └───────────────────────────────────────┘

3.2 Comunicación entre componentes

La biblioteca FD (podheitor-hyperv-fd.dll) es un adaptador ligero que:

Recibe eventos del Bacula FD (inicio de backup, obtención de información de archivos, lectura de datos, etc.)
Los reenvía al backend en Rust a través de un canal interno (stdin/stdout)
Transmite las respuestas del backend de vuelta al Bacula FD

Esta arquitectura modular implica que:

El componente FD es mínimo y estable
Toda la inteligencia reside en el binario backend en Rust
El backend puede actualizarse de forma independiente a la DLL
El backend puede probarse de forma autónoma sin Bacula

3.3 Diseño Multi-Adaptador

Un único binario backend gestiona tres espacios de nombres de plugin distintos:

podheitor-hyperv-fd.dll    →  @hyperv/    (native Hyper-V)
podheitor-vsphere-fd.dll   →  @vsphere/   (VMware → Hyper-V)
podheitor-proxmox-fd.dll   →  @proxmox_/  (Proxmox → Hyper-V)

El backend detecta el espacio de nombres activo a partir del prefijo de la directiva Plugin del FileSet y enruta al manejador operativo correspondiente (backup, restauración, conversión, replicación).

4. Análisis Técnico en Profundidad

4.1 Acceso Directo a VHDX

Windows bloquea los archivos VHDX mientras las VMs están en ejecución — un simple CopyFile() falla. El enfoque de PodHeitor:

Checkpoint de producción (Checkpoint-VM -SnapshotType Production) activa el quiesce VSS dentro de la VM invitada, garantizando la consistencia de las aplicaciones (descarga de logs de transacciones de SQL Server, registro circular de Exchange, etc.)
El checkpoint bifurca el VHDX — la VM en ejecución escribe en un nuevo disco diferencial AVHDX mientras el VHDX padre queda congelado
PodHeitor abre el VHDX padre congelado con FileShare.ReadWrite — ahora legible sin bloquear la VM en ejecución
Los datos se transmiten al Bacula FD → SD → disco vía canal interno
El checkpoint de producción se elimina tras el backup — las escrituras de la VM invitada se fusionan de vuelta

Este enfoque:

Requiere cero espacio en disco adicional (sin copia de preparación con Export-VM)
No genera tiempo de inactividad de la VM (la VM continúa ejecutándose sobre el disco diferencial)
Garantiza la consistencia de las aplicaciones vía VSS

4.2 RCT (Resilient Change Tracking)

RCT es una funcionalidad de Windows Server 2016 en adelante que rastrea los cambios a nivel de bloque en discos VHDX mediante puntos de referencia — instantáneas inmutables del estado de seguimiento de cambios almacenadas en los metadatos del VHDX.

Flujo RCT de PodHeitor:

Backup completo:

Crear checkpoint de producción
Crear punto de referencia RCT (Msvm_VirtualSystemReferencePointService.CreateReferencePoint)
Transmitir el contenido completo del VHDX
Guardar el ID del punto de referencia en %ProgramData%PodHeitorrct<VM-GUID>.json

Backup incremental:

Crear checkpoint de producción
Crear nuevo punto de referencia RCT
Llamar a GetVirtualDiskChanges(previousRef, newRef) — devuelve la lista de rangos de bloques modificados
Leer solo los bloques modificados del VHDX
Transmitir como delta CBT (formato binario personalizado)
Actualizar el estado del punto de referencia guardado

El estado RCT también se transmite como @hyperv/VMName/.meta/rct-state.json en cada backup para la recuperación ante desastres del propio estado.

4.3 Formato de Delta CBT

PodHeitor utiliza un formato binario eficiente para los datos de bloques modificados. El delta contiene una cabecera de 16 bytes que identifica el formato (magic «PCBT», versión y conteo de bloques), seguida de entradas por bloque con offset, tamaño y datos brutos del bloque en el VHDX.

Durante la restauración, el plugin:

Restaura el VHDX base desde el backup completo
Por cada incremental: abre el VHDX y aplica cada bloque CBT en su offset correcto
Tras aplicar todos los deltas, el VHDX es idéntico al estado en el momento del backup

Esto es análogo al funcionamiento de los redo logs de VMDK o las instantáneas de QCOW2, pero implementado en la capa del plugin de Bacula.

4.4 Replicación RCT-Push

Para escenarios near-CDP, PodHeitor implementa RCT-Push — un modo de replicación que:

Se ejecuta como un job de Backup de Bacula (JobType=B) con mode=rct-push
En cada ciclo:

Crea un nuevo punto de referencia RCT en la VM de origen
Llama a GetVirtualDiskChanges entre el punto de referencia anterior y el nuevo
Transmite solo los bloques modificados (normalmente 4–50 MB por ciclo para VMs activas)
Almacena el delta en el Bacula SD como un job de backup estándar

Guarda el estado del punto de referencia para el siguiente ciclo

Dado que cada ciclo es un job de backup estándar de Bacula, todos los puntos de restauración quedan catalogados y son navegables. Se admite la recuperación desde cualquier punto en el tiempo.

4.5 Verificación de Integridad

La versión 1.2.0 incorpora verificación criptográfica de integridad:

Durante el backup: se calculan hashes SHA-256 para cada bloque del VHDX y se almacenan en los metadatos del backup
Durante la restauración: los hashes se recalculan y comparan — cualquier corrupción se detecta y se reporta
Soporta verificación cruzada entre componentes durante el proceso de restauración

5. Funcionalidades de Backup y Restauración

5.1 Niveles de Backup

Nivel	Descripción	RCT Requerido
Completo	VHDX completo + archivos de configuración	No (crea el punto de referencia RCT de línea base)
Incremental	Bloques modificados desde el último backup (de cualquier nivel)	Sí
Diferencial	Bloques modificados desde el último backup completo	Sí

5.2 Selección de VMs

vm=*                    # All VMs
vm=SQL*                 # Wildcard — SQL Server VMs
vm=DC01                 # Specific VM by name
vm=* exclude=Test*,Dev* # All VMs except test/dev

5.3 Comportamiento de la Restauración

Los archivos se restauran en el directorio Where bajo el espacio de nombres @hyperv/VMName/...
Los archivos de delta CBT (.cbt) se aplican automáticamente durante la restauración
Al completar la restauración: la VM se registra en Hyper-V mediante Import-VM (si se indica new_vm_name, la VM se registra con un nuevo nombre y nuevo GUID)
Restauración en la ruta existente de la VM: reemplaza los archivos de disco y vuelve a registrar
Restauración como nueva VM: crea una VM nueva con GUID y nombre únicos

5.4 Integración con el Catálogo

Todos los archivos respaldados aparecen en el catálogo de Bacula bajo @hyperv/:

@hyperv/VM-Name/disks/VM-Name_<UUID>.vhdx        # VHDX disk
@hyperv/VM-Name/disks/VM-Name_<UUID>.vhdx.cbt   # CBT delta (incremental)
@hyperv/VM-Name/config/                          # VM configuration files
@hyperv/VM-Name/.meta/rct-state.json             # RCT tracking state

Esto permite la selección granular de archivos en bconsole restore — restaurar solo el VHDX sin la configuración, o viceversa.

6. Funcionalidades de Replicación

6.1 Modo RCT-Push

Se configura con mode=rct-push en la directiva Plugin del FileSet:

Plugin = "podheitor-hyperv: vm=ProductionDB mode=rct-push push_cycles=1 rpo_seconds=600"

Cada invocación del job de Bacula realiza un ciclo de replicación:

Consultar los bloques modificados desde el último punto de referencia
Transmitir los deltas al Bacula SD
Actualizar el estado del punto de referencia

Para replicación casi continua, programe el job con intervalos cortos (p. ej., cada 10 minutos).

6.2 Gestión de Puntos de Referencia

Los puntos de referencia se mantienen en el host Hyper-V:

Ubicación: %ProgramData%PodHeitorrct<VM-GUID>.json
Contenido: ID de referencia del backup completo, ID de referencia del último backup, marcas de tiempo
También se respaldan en Bacula como @hyperv/VM-Name/.meta/rct-state.json

Si se pierde el estado del punto de referencia (p. ej., tras una conmutación de DR), el siguiente job retrocede automáticamente a un ciclo de replicación completo.

6.3 Parámetros de Replicación

Parámetro	Predeterminado	Descripción
`mode`	`backup`	`rct-push` para modo de replicación
`push_cycles`	`1`	Ciclos por invocación del job (1 = un ciclo, 0 = bucle infinito)
`rpo_seconds`	`900`	RPO objetivo — se registra una advertencia si se supera
`push_interval`	`300`	Espera entre ciclos (si push_cycles > 1)
`push_apply_remote`	`no`	Enviar deltas directamente al host de DR sin pasar por el Bacula SD
`dr_host`	—	Nombre de host/IP del sitio de DR para envío directo
`dr_port`	`9847`	Puerto del receptor en el sitio de DR
`dr_psk`	—	Clave precompartida para el cifrado del transporte hacia el DR
`bandwidth`	`0`	Límite de ancho de banda en bytes/segundo
`max_restore_points`	`5`	Máximo de puntos de restauración retenidos en el sitio de DR

7. Conversión entre Hipervisores

7.1 Conversiones Soportadas

Origen	Destino	DLL del Adaptador	Formato de Origen	Formato de Salida
VMware vSphere (vía plugin PodHeitor vSphere)	Hyper-V	`podheitor-vsphere-fd.dll`	VMDK / raw CBT	VHDX
Proxmox / KVM (vía plugin PodHeitor Proxmox)	Hyper-V	`podheitor-proxmox-fd.dll`	raw / qcow2 CBT	VHDX

7.2 Flujo de Conversión

El Bacula FD carga podheitor-vsphere-fd.dll (o el de Proxmox)
El comando del plugin utiliza un prefijo que coincide con el espacio de nombres de origen (p. ej., @vsphere/)
El job de restauración envía los archivos desde el Bacula SD al FD
El backend detecta el espacio de nombres de origen y enruta hacia el módulo de conversión
Los datos de disco raw/VMDK se escriben en un archivo temporal
Se ejecuta qemu-img.exe convert -f raw -O vhdx input.raw output.vhdx
El VHDX se registra como nueva VM en Hyper-V vía PowerShell
Se eliminan los archivos temporales

7.3 Requisitos para la Conversión

qemu-img.exe instalado (incluido en la sección opcional Herramientas de Conversión del instalador NSIS)
Espacio en disco temporal: ~1,5× el tamaño sin comprimir del disco de la VM
Cuota de disco Hyper-V suficiente para el nuevo VHDX

8. Instalación e Implementación

8.1 Requisitos Previos

Componente	Requisito
SO del Host Hyper-V	Windows Server 2016, 2019, 2022 o 2025
Rol Hyper-V	Habilitado (integrado)
Bacula FD	v15.0.x (instalado y configurado)
Acceso de Administrador	Requerido para el instalador y el reinicio del servicio FD
Puerto de red	TCP 9102 (Bacula FD) abierto hacia el Director

8.2 Instalador NSIS

El instalador (PodHeitor-HyperV-Plugin-1.2.0-x64.exe) está construido con NSIS y proporciona:

Componentes requeridos (siempre instalados):

podheitor-hyperv-backend.exe → %PROGRAMFILES%Bacula
podheitor-hyperv-fd.dll → %PROGRAMFILES%Baculaplugins
hyperv-fileset.conf.example → %PROGRAMFILES%Bacula
README.md, INSTALLATION_MANUAL.md, LICENSE.txt

Componente opcional — Herramientas de Conversión (SEC_CONV):

podheitor-vsphere-fd.dll → %PROGRAMFILES%Baculaplugins
podheitor-proxmox-fd.dll → %PROGRAMFILES%Baculaplugins
qemu-img.exe → %PROGRAMFILES%Baculatools (si se proporciona)

Componente opcional — Documentación:

WHITEPAPER.md, REPLICATION_PLAN.md

8.3 Instalación Silenciosa

.PodHeitor-HyperV-Plugin-1.2.0-x64.exe /S

Con directorio de instalación personalizado:

.PodHeitor-HyperV-Plugin-1.2.0-x64.exe /S /D=D:Baculaplugins

8.4 Validación Post-Instalación

# In bconsole on the Bacula Director:
status client=hyperv-host-fd

# Expected output should include:
# Plugin: podheitor-hyperv(1.2.0)

8.5 Reversión

# Stop FD
Stop-Service bacula-fd

# Restore previous DLL from backup
Copy-Item "C:Backuppodheitor-hyperv-fd.dll.bak" `
          "$env:PROGRAMFILESBaculapluginspodheitor-hyperv-fd.dll" -Force

# Start FD
Start-Service bacula-fd

9. Dimensionamiento y Planificación de Capacidad

9.1 Host Hyper-V — Mínimo Recomendado

Carga de Trabajo	CPU	RAM	Almacenamiento (temporal)	Red
Solo backup (≤10 VMs)	4 núcleos	4 GB	No requerido	1 Gbps
Solo backup (≤50 VMs)	8 núcleos	8 GB	No requerido	10 Gbps
Backup + Replicación	8 núcleos	8 GB	No requerido	10 Gbps
Conversión (importación)	8 núcleos	8 GB	2× tamaño de la VM más grande	10 Gbps

9.2 Bacula Storage Daemon

Carga de Trabajo	Estimación de Almacenamiento
Backup completo, VM de 100 GB	~30–60 GB (comprimido, disco típico de sistema Linux/Windows)
Incremental, VM activa	~2–10 GB/día (tasa de cambio diaria típica)
Ciclos de replicación (diario)	~5–30 GB/día (solo cambios vía RCT)
Retención 30 días, 10 VMs promedio 100 GB	~2–5 TB

9.3 Ancho de Banda de Red

Escenario	Transferencia Típica
Backup completo, VM de 100 GB	30–60 GB durante la ventana de backup
Incremental por hora, VM activa	2–5 GB/hora (después del primer backup completo)
Ciclo RCT-Push, intervalo de 10 min	4–50 MB/ciclo (dependiendo de la actividad de la VM)

9.4 Bacula Director

Sin requisitos adicionales. El Director solo almacena metadatos de jobs (entradas del catálogo). La operación del plugin se realiza completamente del lado del FD/SD.

10. Compatibilidad de Plataforma

10.1 Configuraciones Validadas

SO del Host Hyper-V	Versión de Hyper-V	Bacula FD	Plugin	Estado
Windows Server 2016 Datacenter Eval	10.0.14393	15.0.3	1.2.0	✅ Completamente validado
Windows Server 2025 Standard	10.0.26100	15.0.3	1.2.0	✅ Completamente validado

10.2 Compatibilidad Esperada

SO del Host Hyper-V	Estado	Notas
Windows Server 2019	✅ Esperado	RCT disponible desde 2016
Windows Server 2022	✅ Esperado	Soporte completo de RCT
Windows 10/11 Pro (Hyper-V cliente)	⚠️ Sin pruebas	RCT puede comportarse de forma diferente
Azure Stack HCI	⚠️ Sin pruebas	Debería funcionar; integración con SCVMM no probada

10.3 Compatibilidad con VMs Invitadas

SO Invitado	quiesce=yes	quiesce=no	Notas
Windows Server (cualquier versión)	✅	✅	VSS en el invitado vía Integration Services
Windows 10/11	✅	✅	VSS soportado
Ubuntu/Debian Linux	⚠️	✅	VSS vía linux-guest-agent; se recomienda quiesce=no
RHEL/CentOS Linux	⚠️	✅	Igual que Ubuntu
FreeBSD	❌	✅	Sin soporte de VSS; se requiere quiesce=no
Otro Linux	❌	✅	Se requiere quiesce=no

10.4 Compatibilidad con Bacula

Componente	Versión	Estado
Bacula FD	15.0.x	✅ Probado
Bacula Director	15.0.x	✅ Probado
Bacula SD	15.0.x	✅ Probado
Bacula FD	14.x	⚠️ Esperado (API de plugin estable)
Bacularis (interfaz web)	Cualquiera	✅ Todos los jobs gestionables vía Bacularis

11. Referencia de Configuración

11.1 Referencia Completa de Parámetros — Backup

Parámetro	Tipo	Predeterminado	Descripción
`vm`	string	`*`	Nombre de VM o comodín. `*` = todas las VMs. No se admiten múltiples patrones (use múltiples líneas Plugin=).
`exclude`	string	—	Patrones separados por comas para excluir. Ej.: `Test,Dev,Staging*`.
`quiesce`	bool	`yes`	Crear checkpoint VSS consistente con las aplicaciones antes de leer el VHDX. Defina `no` para VMs Linux sin integration services.
`online`	bool	`yes`	Permitir el backup de VMs en ejecución mediante checkpoint de producción. Defina `no` para omitir las VMs en ejecución.
`timeout`	int	`3600`	Segundos máximos de espera para cualquier operación (creación de checkpoint, transmisión de VHDX).
`new_vm_name`	string	—	Al restaurar, registrar la VM con este nombre en lugar del nombre original.
`restore_path`	string	—	Sobreescribir el directorio de restauración predeterminado. Predeterminado: `Where` del job de restauración.
`abort_on_error`	bool	`no`	Cancelar el job completo si falla alguna VM. Predeterminado: continuar con la siguiente VM.
`config_file`	string	—	Ruta a un archivo de configuración. Los parámetros en la directiva Plugin= tienen prioridad sobre los valores del archivo de configuración.

11.2 Referencia Completa de Parámetros — Replicación

Parámetro	Tipo	Predeterminado	Descripción
`mode`	enum	`backup`	Modo de operación. Valores: `backup`, `rct-push`, `seed`, `async-hvr`, `receiver`, `replication-status`, `daemon`, `failback`, `reprotect`, `failover-planned`, `failover-unplanned`, `failover-test`, `failover-undo`, `failover-permanent`.
`push_interval`	int	`300`	Segundos entre ciclos de replicación (cuando `push_cycles > 1`).
`push_cycles`	int	`1`	Número de ciclos de replicación por job. `0` = ejecutar indefinidamente (modo daemon).
`rpo_seconds`	int	`900`	RPO objetivo. Se registra una advertencia si el ciclo de replicación lo supera.
`dr_host`	string	—	Nombre de host/IP del sitio de DR para el modo de envío directo (`push_apply_remote=yes`).
`dr_port`	int	`9847`	Puerto del receptor en el sitio de DR.
`dr_psk`	string	—	Clave precompartida para el cifrado del transporte hacia el DR.
`bandwidth`	int	`0`	Límite de ancho de banda en bytes/segundo. `0` = sin límite.
`max_restore_points`	int	`5`	Máximo de puntos de restauración retenidos en el sitio de DR. Los puntos más antiguos se eliminan automáticamente.
`push_apply_remote`	bool	`no`	Cuando es `yes`, los deltas se aplican directamente en el host de DR (sin pasar por el Bacula SD como intermediario).
`network_map`	string	—	Mapeo de adaptadores de red para escenarios de conmutación. Formato: `src_switch=dst_switch,...`.
`reip_rules`	string	—	Reglas de re-IP para conmutación. Formato: `vm:new_ip/mask/gw,...`.

12. Ejemplos de FileSet y Job

12.1 Backup — Todas las VMs, Completo Diario + Incremental por Hora

# FileSet
FileSet {
  Name = "HyperV-AllVMs"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
    }
    Plugin = "podheitor-hyperv: vm=*"
  }
}

# Schedules
Schedule {
  Name = "DailyFull"
  Run = Full sun at 01:00
  Run = Incremental mon-sat at 01:00
  Run = Incremental mon-sat at 07:00
  Run = Incremental mon-sat at 13:00
  Run = Incremental mon-sat at 19:00
}

# Job
Job {
  Name = "HyperV-Backup-AllVMs"
  Type = Backup
  Client = hyperv-host-fd
  FileSet = "HyperV-AllVMs"
  Schedule = "DailyFull"
  Storage = File1
  Pool = Default
  Priority = 10
  Messages = Standard
  Write Bootstrap = /opt/bacula/working/%c.bsr
}

12.2 Backup — Agrupado por Criticidad

FileSet {
  Name = "HyperV-Tiered"
  Include {
    Options { Signature = SHA256; Compression = LZ4 }
    # Tier 1: application-consistent, every 4h incremental
    Plugin = "podheitor-hyperv: vm=SQL* quiesce=yes timeout=7200"
    Plugin = "podheitor-hyperv: vm=Exchange* quiesce=yes timeout=7200"
    Plugin = "podheitor-hyperv: vm=DC* quiesce=yes"
    # Tier 2: no quiesce for Linux
    Plugin = "podheitor-hyperv: vm=Linux* quiesce=no"
    # Exclude dev/test
    Plugin = "podheitor-hyperv: vm=Web* exclude=*-dev,*-test quiesce=no"
  }
}

12.3 Replicación — near-CDP (RPO de 10 minutos)

FileSet {
  Name = "HyperV-Replicate-CriticalDBs"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-hyperv: vm=SQL* mode=rct-push push_cycles=1 rpo_seconds=600 push_apply_remote=no"
  }
}

Schedule {
  Name = "Every10Minutes"
  Run = Incremental hourly at 0:00
  Run = Incremental hourly at 0:10
  Run = Incremental hourly at 0:20
  Run = Incremental hourly at 0:30
  Run = Incremental hourly at 0:40
  Run = Incremental hourly at 0:50
}

Job {
  Name = "HyperV-Replicate-CriticalDBs"
  Type = Backup
  Level = Full
  Client = hyperv-host-fd
  FileSet = "HyperV-Replicate-CriticalDBs"
  Schedule = "Every10Minutes"
  Storage = ReplicaStorage
  Pool = ReplicaPool
  Messages = Standard
  Priority = 5
}

12.4 Restauración — VM Específica

# In bconsole:
restore client=hyperv-host-fd 
        restoreclient=hyperv-host-fd 
        restorejob=HyperV-Restore 
        jobid=<backup_jobid> 
        where=/ 
        all done yes

12.5 Restauración — Como Nueva VM (Nombre Diferente)

FileSet {
  Name = "HyperV-Restore-NewVM"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-hyperv: vm=ProductionVM new_vm_name=RestoredVM-Test restore_path=D:HyperVRestored"
  }
}

12.6 Conversión entre Hipervisores (vSphere → Hyper-V)

# Prerequisite: podheitor-vsphere-fd.dll installed on Hyper-V host
# Prerequisite: qemu-img.exe available

FileSet {
  Name = "vSphere-to-HyperV"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-vsphere: vm=LinuxVM restore_path=D:HyperVConverted"
  }
}

Job {
  Name = "Convert-vSphere-to-HyperV"
  Type = Restore
  Client = hyperv-host-fd
  FileSet = "vSphere-to-HyperV"
  Storage = File1
  Pool = Default
  Where = /
  Messages = Standard
}

13. Consideraciones de Seguridad

13.1 Autenticación

El plugin se comunica localmente vía stdin/stdout (canal interno) — sin socket de red
Bacula FD ↔ Director usa TLS con certificados (estándar de Bacula)
Bacula FD ↔ SD usa TLS con certificados (estándar de Bacula)
El canal de envío al DR usa clave precompartida (dr_psk) para cifrado adicional

13.2 Credenciales

No se almacenan credenciales en el código del plugin ni en los archivos de configuración
El acceso a Hyper-V utiliza la cuenta de Windows bajo la que se ejecuta el servicio Bacula FD (generalmente SYSTEM o una cuenta de servicio dedicada)
Recomendación: crear una cuenta de servicio de Windows dedicada con el rol de Administrador de Hyper-V

13.3 Datos en Tránsito

Todos los datos de backup viajan a través de la conexión TLS estándar de Bacula FD → SD
La replicación vía RCT-Push usa transporte cifrado con PSK cuando dr_psk está configurado
Sin exposición de datos sin cifrar durante la operación del plugin

13.4 Cumplimiento OWASP

Sin riesgo de inyección SQL (sin interacción con base de datos en el código del plugin)
Sin inyección de comandos (la ejecución de subprocesos usa arrays de argumentos, no cadenas de shell)
Sin credenciales codificadas
Validación de entradas en todos los límites del sistema
Sin path traversal (todas las rutas de restauración se validan contra el parámetro Where)

14. Benchmarks de Rendimiento

14.1 Configuración de Prueba

Componente	Especificación
Host Hyper-V	Windows Server 2016, Dual-Core, 4 GB RAM
Bacula FD	15.0.3
Bacula SD	Linux, enlace de 10 Gbps
Almacenamiento	Almacenamiento dedup de Bacula (SD)
Compresión	LZ4

14.2 Rendimiento de Backup

Escenario	Tamaño de VM	Datos Transferidos	Tiempo Transcurrido	Tasa de Transferencia
Backup completo, VM Linux (TestVM-Linux)	~1 GB de disco (sparse)	15,6 MB	~10 seg	~1,5 MB/s (dedup SD activo)
Restauración, VM Linux	633 MB restaurados	~45 seg	~14 MB/s	Throughput estándar de SD
Ciclo incremental RCT-Push	4 MB modificados	36 KB (post-dedup)	~5 seg	Negligible

14.3 Observaciones

Dedup activo: El dedup del Bacula SD reduce significativamente los datos almacenados. El backup de 15,6 MB → restauración de 633 MB refleja una tasa de compresión dedup de ~40:1 para esta VM Linux.
Eficiencia de RCT-Push: Solo se transfieren los bloques modificados. Para una VM de 1 GB con cambios mínimos entre ciclos, cada ciclo transfiere menos de 10 MB de datos de cambio sin procesar.
Entorno de producción: Se esperan entre 100–500 MB/s de throughput en bruto en redes de 10 Gbps con almacenamiento NVMe (sin dedup).

15. Comparativa Competitiva

Funcionalidad	PodHeitor + Bacula	Veeam Enterprise	Commvault	Bacula Enterprise
Backup de VM en Hyper-V	✅	✅	✅	✅
Incremental a nivel de bloque con RCT	✅	✅	✅	✅
Consistente con aplicaciones (VSS)	✅	✅	✅	✅
Replicación near-CDP	✅	✅	✅	✅
Conversión vSphere → Hyper-V	✅	Parcial	✅	❌
Conversión Proxmox → Hyper-V	✅	❌	❌	❌
Catálogo abierto (PostgreSQL)	✅	❌ (propietario)	❌	✅
Director en Linux	✅	❌ (solo Windows)	❌	✅
Costo base de licencia	Gratuito (PodHeitor Backup)	US$ 2.500+/año	US$ 5.000+/año	US$ 3.000+/año
Costo del plugin	Consultar precio	Incluido	Incluido	Incluido
TCO total a 3 años (50 VMs)	~US$ 5.000	~US$ 25.000	~US$ 40.000	~US$ 20.000

16. Hoja de Ruta de Desarrollo

Completado (v1.2.0)

[x] Backup directo de VHDX con checkpoints de producción
[x] Incremental/diferencial a nivel de bloque con RCT
[x] Formato de delta CBT + aplicación de delta en la restauración
[x] Quiesce VSS consistente con las aplicaciones
[x] Registro automático de VM en la restauración
[x] Replicación RCT-Push (near-CDP)
[x] Conversión entre hipervisores: vSphere → Hyper-V
[x] Conversión entre hipervisores: Proxmox → Hyper-V
[x] Verificación de integridad (SHA-256 cruzado VerifyReq/VerifyResp)
[x] Soporte de archivo de configuración
[x] Instalador NSIS con Herramientas de Conversión opcionales
[x] Validación en producción en Windows Server 2016 + Bacula 15.0.3

Planificado (v1.2.0)

[ ] Automatización de failover/failback (modos de conmutación planificada/no planificada)
[ ] Reprotección tras failover
[ ] Integración con la interfaz web de Bacularis — panel dedicado de backup Hyper-V
[ ] Soporte de migración en vivo de Windows Server 2025 Hyper-V
[ ] Integración de alertas por correo electrónico (SMTP, Microsoft Teams, Slack)
[ ] API REST para estado y gestión del plugin

Planificado (v2.0.0)

[ ] Soporte de clúster Hyper-V multi-host (Live Migration + backup con conciencia de clúster)
[ ] Integración con Azure Stack HCI
[ ] Integración con Hyper-V Replica (uso de la replicación integrada de Hyper-V para DR)
[ ] Backup a nivel de contenedor (Windows Server Containers en Hyper-V)
[ ] Soporte de almacenamiento en la nube compatible con S3 como destino

Licenciamiento

PodHeitor Hyper-V Backup Plugin 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

Conclusión

PodHeitor Hyper-V Plugin ofrece protección de VM de clase empresarial — backup, replicación y conversión entre hipervisores — sobre PodHeitor Backup Edition a una fracción del costo de las soluciones propietarias.

Con un backend en Rust validado en producción, acceso directo a VHDX, incremental a nivel de bloque con RCT y replicación RCT-Push integrada, este plugin está preparado para entornos empresariales exigentes.

💼 ¿Listo para ahorrar más del 50% en su presupuesto de backup?

Traiga su propuesta de renovación de cualquier plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup u otras. Ofrecemos al menos un 50% de descuento con muchas más funcionalidades.

Contacte a Heitor Faria: – 📧 heitor@opentechs.lat – 📞 +1 786 726-1749 – 📱 +55 61 98268-4220 (WhatsApp)

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