Blog

Whitepaper — PodHeitor Proxmox

Whitepaper — PodHeitor Proxmox

Respaldo sin agente para Proxmox VE. KVM y LXC vía API nativa — incremental real, CBT por dirty bitmap, restauración granular de archivo, restore a cluster distinto.

  • Incremental real con dirty bitmap — solo envía bloques modificados.
  • Sin agente en la VM — captura vía PVE API, integración QGA para application-consistent.
  • Restore granular de archivo sin levantar la VM completa — monte el snapshot, copie lo necesario.
  • Restore cross-cluster — recupere a otro nodo PVE, opcionalmente otro storage backend.
  • Snapshots ZFS / Ceph / LVM-thin coordinados — app-consistent cuando disponible, crash-consistent garantizado.

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 →

Tabla de Contenidos

  1. Resumen Ejecutivo
  2. Introducción
  3. Casos de Uso
  4. Arquitectura Técnica
  5. Referencia Detallada de Funcionalidades
  6. Procedimiento de Instalación
  7. Guía de Dimensionamiento y Configuración
  8. Matriz de Compatibilidad
  9. Referencia de Parámetros
  10. Ejemplos de Configuración
  11. Modelo de Seguridad
  12. Comparación Competitiva
  13. Análisis de TCO y ROI
  14. Hoja de Ruta
  15. Conclusión
  16. Aviso Legal y Contacto
  17. Apéndice

1. Resumen Ejecutivo

Las organizaciones que ejecutan Proxmox VE como plataforma de virtualización han enfrentado históricamente una brecha significativa en la protección de datos de nivel empresarial: o aceptan las limitaciones de las herramientas PBS (Proxmox Backup Server) nativas de Proxmox — sin integración con los marcos corporativos de backup existentes — o pagan precios elevados por soluciones agnósticas al hipervisor que implican altos costos de licenciamiento, arquitecturas complejas y dependencia de un proveedor específico.

PodHeitor Proxmox Backup, Replication and Conversion Plugin for Bacula cierra esta brecha de manera decisiva. Es un plugin validado en producción, con licencia comercial, que integra nativamente la protección de máquinas virtuales Proxmox VE en PodHeitor Backup, uno de los motores de backup de código abierto más ampliamente implementados en el mundo. El resultado es una plataforma de backup unificada que combina la madurez de Bacula en programación de Jobs, catálogo y gestión de retención con protección de VMs consistente ante fallos y consistente a nivel de aplicación, backups incrementales perpetuos mediante bitmaps sucios de QEMU (CBT), replicación de recuperación ante desastres entre nodos, recuperación instantánea vía overlay NBD y migración entre hipervisores desde VMware vSphere y Microsoft Hyper-V hacia Proxmox.

El plugin ha sido validado en un entorno de producción ejecutando más de 1.290 Jobs — todos con estado Terminated OK — en dos nodos Proxmox VE 8.4 sobre Debian 12, coordinados por un Director PodHeitor Backup en Oracle Linux 9.6. La programación ha sido sometida a pruebas de estrés con intervalos de cinco minutos, y la ruta completa de replicación DR con anclaje de huella digital TLS ha sido confirmada como operativa.

Para audiencias de nivel ejecutivo y liderazgo de TI, las propuestas de valor estratégico son:

  • Reducción de costos: Elimina herramientas duplicadas. Una implementación de Bacula cubre servidores físicos, VMs, bases de datos y ahora VMs de Proxmox.
  • Reducción de riesgos: Replicación DR validada hacia un nodo PVE secundario con aprovisionamiento automatizado de VMs y transporte seguro por TLS.
  • Agilidad: La conversión entre hipervisores permite migrar cargas de trabajo de VMware e Hyper-V a Proxmox sin costosas herramientas de migración de terceros.
  • Preparación para cumplimiento normativo: Backups consistentes a nivel de aplicación (quiesce/freeze vía agente QEMU), registro de auditoría completo a través del catálogo de Bacula y políticas de retención configurables.
  • Sin proliferación de daemons adicionales: La programación es gestionada íntegramente por el scheduler nativo de Bacula — sin cron jobs adicionales, agentes ni servicios.

2. Introducción

2.1 El Problema

Los entornos de TI empresarial que han adoptado Proxmox VE como plataforma hipervisora principal o secundaria enfrentan un desafío recurrente: la integración de la protección de datos. La mayoría de las estrategias corporativas de backup están estandarizadas en torno a un único marco — comúnmente Bacula, Veeam o Commvault — y extender ese marco para cubrir las VMs de Proxmox normalmente requiere alguno de los siguientes compromisos:

  1. Ejecutar Proxmox Backup Server (PBS) como sistema paralelo — aceptable para entornos pequeños, pero introduce un plano de gestión completamente separado, lógica de retención y flujo de trabajo de informes que no se integra con el catálogo corporativo de backup.
  1. Instalar un agente de backup de nivel de archivos genérico dentro de cada VM — anula el propósito del backup a nivel de hipervisor, omite el quiescing previo al snapshot, requiere licenciamiento de agente por VM y no puede realizar restauraciones a bare-metal ni restauraciones instantáneas.
  1. Adquirir una solución empresarial agnóstica al hipervisor — Veeam, Commvault o Veritas añaden costos de licenciamiento significativos, pueden no soportar Proxmox oficialmente e introducen proliferación de agentes y arquitecturas complejas.
  1. Utilizar el plugin Proxmox de Bacula Enterprise — disponible, pero limitado al nivel comercial de Bacula Enterprise, que conlleva costos de licenciamiento por frontend o por TB que escalan desfavorablemente para implementaciones Proxmox de mercado medio.

2.2 La Solución

El Plugin Proxmox de PodHeitor proporciona un plugin nativo de Bacula que se ejecuta como biblioteca compartida cargada por el Bacula File Daemon en cada nodo Proxmox VE. Un binario backend de alto rendimiento en Rust se comunica directamente con la REST API de Proxmox, los sockets del Protocolo Monitor QEMU (QMP) y las interfaces Network Block Device (NBD) — permitiendo backups de VMs completos, incrementales y diferenciales con consistencia ante fallos y consistencia opcional a nivel de aplicación.

Dado que el plugin implementa la API estándar de plugins de Bacula, hereda todo el ecosistema de Bacula:

  • Programación de Jobs, ventanas y calendarios
  • Políticas de retención y gestión de volúmenes
  • Archivos bootstrap y restauración basada en catálogo
  • Informes y alertas a nivel de Director
  • Soporte de múltiples Storage Daemons
  • Backends de almacenamiento en la nube (S3, Azure, GCS) mediante configuraciones existentes de Bacula SD

2.3 Mercado Objetivo

El plugin está diseñado para:

  • Empresas medianas y grandes que ejecutan Proxmox VE 8.x como plataforma de virtualización principal junto con PodHeitor Backup
  • Proveedores de servicios y MSPs que gestionan múltiples entornos de clientes sobre Proxmox
  • Organizaciones que migran desde VMware o Hyper-V a Proxmox y necesitan una herramienta de migración y backup en una sola solución
  • Organizaciones que ya ejecutan Bacula Enterprise o Community y desean extender la cobertura a nodos Proxmox sin adoptar una plataforma adicional

3. Casos de Uso

3.1 Backup Completo de Toda la Flota de VMs con Estrategia Incremental Perpetua

Escenario: Una empresa mediana ejecuta 80 VMs en dos nodos Proxmox VE. El equipo de backup debe cumplir un RPO de 24 horas y un RTO de 4 horas, con retención de 90 días. El presupuesto de almacenamiento es limitado.

Solución: El plugin se configura con backup_type=full para Jobs semanales del domingo y backup_type=incremental para Jobs nocturnos. En la primera ejecución, un backup completo a nivel de imagen captura todos los extents del disco de la VM vía NBD. En las ejecuciones siguientes, solo los extents sucios rastreados por los bitmaps CBT de QEMU se envían al Bacula Storage Daemon, reduciendo las ventanas de backup de horas a minutos.

Flujo:

[Sunday 23:00]
  Bacula Director triggers FileSet "Proxmox-All-VMs" with backup_type=full
    -> Plugin enumerates all VMs on PVE node via REST API
    -> For each VM: create consistent snapshot (quiesce=yes via QEMU agent)
    -> Open NBD export for each disk
    -> Stream all extents to SD -> write to volume
    -> Remove snapshot, record CBT bitmap ID in catalog

[Mon-Sat 23:00]
  backup_type=incremental
    -> Plugin reads CBT bitmap delta since last backup
    -> Only dirty extents streamed -> 5-20x smaller backup window
    -> Full restore path reconstructed from base + delta chain

Resultado: Backup completo semanal (escala ~TB), incrementales en menos de 30 minutos nocturnos. Retención de 90 días mediante gestión de pools y volúmenes de Bacula. RTO cumplido vía asistente de restauración basado en catálogo.

3.2 Replicación para Recuperación ante Desastres hacia Sitio Secundario

Escenario: Una empresa de servicios financieros requiere un sitio secundario que replique las VMs críticas del clúster PVE primario. El sitio secundario debe poder arrancar las VMs de forma independiente en menos de 15 minutos tras un fallo del sitio primario.

Solución: El modo de replicación DR utiliza una arquitectura receptor/emisor. El nodo PVE secundario ejecuta el plugin en mode=receiver, escuchando en el puerto TCP 9190. El nodo primario ejecuta mode=seed (emisor), que transmite los datos del disco de la VM a través de un canal cifrado TLS con autenticación PSK. El receptor aprovisiona automáticamente la VM de destino en el clúster PVE secundario.

Flujo:

Primary PVE (192.168.15.129)              Secondary PVE (192.168.15.102)
  mode=seed                                   mode=receiver
  vm=127                                      dr_port=9190
  dr_host=192.168.15.102                      target_vmid=127
  dr_port=9190                                storage=local-lvm
       |
       |  TCP:9190 (PSK/TLS encrypted)
       +------------------------------------------------->
                                          Auto provision VM 127
                                          Write disk extents
                                          Register in PVE inventory

Resultado: La VM 127 está disponible en el nodo PVE secundario en cuestión de minutos. Ante un evento de failover, el equipo de operaciones arranca la VM 127 en el nodo DR. No se requiere copia ni importación manual de discos.

3.3 Recuperación Instantánea para Cumplimiento Rápido de SLA

Escenario: Una VM de base de datos en producción falla a las 09:15. El backup de las 02:00 existe en el Bacula Storage Daemon. El SLA del negocio requiere restauración del servicio en 30 minutos.

Solución: El modo de Recuperación Instantánea (IR) arranca la VM directamente desde el backup mediante un overlay NBD montado en el nodo Proxmox. La VM está activa en 2-5 minutos. En segundo plano, el plugin migra los discos de la VM desde el overlay NBD al almacenamiento de destino final, de forma transparente y sin interrupción del servicio.

Flujo:

[09:15] VM failure detected
[09:17] Operator initiates IR restore job
[09:19] Plugin mounts NBD overlay from backup volume on SD
        PVE boots VM from NBD overlay -> VM is live (read/write via overlay)
[09:20] VM available to users -- SLA met
[09:20-10:00] Background migration: disk pages copied from NBD overlay
              to target_storage=local-lvm
[10:00] Migration complete. VM detached from NBD overlay.
        Fully sovereign on local storage.

Resultado: SLA de 30 minutos cumplido a las 09:20 — 8 minutos desde la detección del fallo.

3.4 Migración entre Hipervisores — VMware a Proxmox

Escenario: Una empresa está rescindiendo un contrato de licencia perpetua de VMware tras los aumentos de precios por la adquisición de Broadcom. Necesitan migrar 40 VMs desde vSphere 7 a Proxmox VE 8 con tiempo de inactividad mínimo y sin adquirir herramientas de migración adicionales.

Solución: El plugin incluye un pipeline de conversión validado desde el formato VMware VMDK al formato nativo de Proxmox qcow2 o raw. Los discos VMDK se exportan desde vSphere, y el plugin gestiona la traducción de formato, la normalización de la geometría del disco y el mapeo de configuración de VM al formato .conf de Proxmox.

Flujo:

vSphere 7 Datastore (NFS)
  VMDK disks + .vmx config
       |
       | Direct file access / SCP
       v
PodHeitor Backend Conversion Engine
  +-- Parse .vmx -> generate Proxmox VM .conf
  +-- Convert VMDK -> qcow2 (via internal format pipeline)
  +-- Import disk images into PVE storage
  +-- Register VM in PVE inventory with converted configuration
       |
       v
Proxmox VE 8 -- VM ready to boot

Resultado: 40 VMs migradas durante una ventana de mantenimiento de fin de semana. Cero costos adicionales de licenciamiento de herramientas de migración.

3.5 Backup Consistente a Nivel de Aplicación para Bases de Datos

Escenario: Un clúster de bases de datos PostgreSQL se ejecuta dentro de una VM Proxmox. El equipo de DBA requiere backups consistentes a nivel de aplicación — logs WAL con checkpoint y sistema de archivos quiesced antes del snapshot — para garantizar una restauración limpia sin fallos de replay.

Solución: El parámetro quiesce=yes instruye al plugin para invocar el comando guest-fsfreeze-freeze del QEMU Guest Agent antes de crear el snapshot de Proxmox, y guest-fsfreeze-thaw después. Esto garantiza que todas las escrituras del sistema de archivos en tránsito se confirmen antes de tomar el snapshot.

Flujo:

Plugin -> QMP socket -> QEMU Agent: guest-fsfreeze-freeze
  Wait: all FS buffers flushed, PostgreSQL checkpoint issued
Plugin -> PVE REST API: POST /nodes/{node}/qemu/{vmid}/snapshot
  Snapshot created at consistent state
Plugin -> QMP socket -> QEMU Agent: guest-fsfreeze-thaw
  VM continues normal operation
Plugin -> NBD: open disk export from snapshot
  Stream data to Bacula SD

Resultado: PostgreSQL se restaura desde el backup sin necesidad de replay de WAL. Las pruebas de restauración confirman inicio limpio de la base de datos directamente desde la imagen de backup.

3.6 Entorno MSP Multitenant Automatizado

Escenario: Un proveedor de servicios gestionados aloja VMs de 30 clientes en un clúster Proxmox compartido. Cada cliente tiene diferentes ventanas de backup, requisitos de retención y destinos DR.

Solución: La arquitectura nativa multi-cliente de Bacula se mapea naturalmente. Cada grupo de clientes es un Client de Bacula separado apuntando a un nodo PVE dedicado, con FileSets, Schedules, Pools y Storage Daemons independientes. El parámetro vm= del plugin acepta rangos de VMID o patrones de nombre, permitiendo Jobs de backup con ámbito por cliente sin modificar ninguna configuración global.

Resultado: 30 flujos de backup independientes, gestionados desde un único Director de Bacula, con informes, retención y DR por cliente — todo sin licenciamiento de agente por cliente.

4. Arquitectura Técnica

4.1 Visión General de los Componentes

+---------------------------------------------------------------------+
|                    Bacula Director (RHEL/OL 9.6)                    |
|  +--------------+  +--------------+  +--------------------------+   |
|  |   Scheduler  |  |   Catalog    |  |  Job/Pool/Volume Mgmt   |   |
|  |  (native)    |  | (PostgreSQL) |  |                          |   |
|  +--------------+  +--------------+  +--------------------------+   |
+----------------------------+----------------------------------------+
                             | Bacula Protocol (TCP 9102)
                             v
+---------------------------------------------------------------------+
|           Bacula File Daemon (Proxmox VE Node, Debian 12)           |
|  +----------------------------------------------------------------+  |
|  |  podheitor-proxmox-fd.so  (plugin FD)                          |  |
|  |  Loaded by bacula-fd at startup                                |  |
|  |  Implements: Bacula plugin API (backup/restore/events)         |  |
|  +----------------------------+-----------------------------------+  |
+--------------------------------+------------------------------------+
                                 | Internal Protocol (stdin/stdout pipe)
                                 v
+---------------------------------------------------------------------+
|        podheitor-proxmox-backend  (Rust binary, high performance)    |
|                                                                     |
|  +--------------+  +--------------+  +---------------------------+  |
|  |  PVE REST    |  |  QMP Client  |  |    NBD Client             |  |
|  |  API Client  |  |  (Unix sock) |  |  (TCP 10809)              |  |
|  |  HTTPS:8006  |  |  QEMU Guest  |  |  Disk extent stream       |  |
|  |  TLS pinned  |  |  Agent cmds  |  |  CBT dirty bitmaps        |  |
|  +--------------+  +--------------+  +---------------------------+  |
|                                                                     |
|  +---------------------------------------------------------------+  |
|  |  DR Transport Engine                                          |  |
|  |  TCP:9190 -- PSK/TLS encrypted                               |  |
|  |  Receiver: auto VM provisioning + disk write                 |  |
|  |  Sender: disk delta stream + handshake                       |  |
|  +---------------------------------------------------------------+  |
+---------------------------------------------------------------------+
          |                              |
          | HTTPS:8006 (TLS pinned)      | QMP Unix socket
          v                              v
  Proxmox VE REST API             QEMU Monitor (per-VM)
  - VM lifecycle mgmt             - guest-fsfreeze-freeze/thaw
  - Snapshot create/delete        - disk info queries
  - Storage management            - bitmap management
  - Node enumeration

4.2 El Plugin FD (podheitor-proxmox-fd.so)

La biblioteca compartida es cargada por el Bacula File Daemon en el nodo Proxmox VE. Sus responsabilidades son:

  1. Registrar el plugin en el FD al momento de carga
  2. Analizar el string Plugin = del FileSet y extraer los parámetros clave-valor
  3. Lanzar el proceso backend en Rust con los parámetros del job
  4. Reenviar los eventos de backup/restauración de Bacula al backend
  5. Hacer proxy de los bloques de datos entre el flujo de datos del FD y la salida del backend

Este diseño modular significa que la lógica crítica en rendimiento reside íntegramente en el binario backend en Rust, que puede actualizarse y probarse de forma independiente del FD.

4.3 El Backend en Rust (podheitor-proxmox-backend)

El binario backend — construido en Rust con memory-safety nativa y sin pausas de GC — es el motor principal, estructurado en torno a cinco subsistemas primarios:

Subsistema Responsabilidad
Cliente REST PVE Cliente HTTPS autenticado para la REST API de Proxmox. Gestiona el ciclo de vida de tokens, anclaje de huella digital TLS, enumeración de VMs, gestión de snapshots y consultas de almacenamiento.
Cliente QMP Cliente de socket de dominio Unix para el Protocolo Monitor QEMU. Emite comandos guest-fsfreeze-freeze/thaw, query-block y de gestión de bitmaps.
Motor NBD Cliente TCP para el protocolo Network Block Device (TCP 10809). Gestiona la negociación de conexión, consultas de extents (para CBT) y streaming de datos de bloque raw.
Transporte DR Protocolo TCP personalizado en el puerto 9190. TLS basado en PSK o certificados. Implementa los roles de receptor y emisor.
Motor de Conversión Analizador y convertidor de VMDK/OVF y VHDX. Genera archivos .conf nativos de Proxmox y traduce formatos de disco a qcow2 o raw.

4.4 Flujo de Datos: Backup Incremental

Backend reads CBT bitmap from QEMU (via QMP/NBD bitmap query)
    |
    v  Dirty extent list (offset, length pairs)
Backend opens NBD export for snapshot disk
    |
    v  For each dirty extent:
Read block from NBD -> compress (LZ4/zstd) -> write to Bacula data stream
    |
    v  Bacula data stream
Plugin FD forwards to Bacula SD over network
    |
    v
SD writes to configured Volume (disk/tape/cloud)
    |
    v
Director updates catalog: job ID, file entries, bitmap checkpoint ID

4.5 Flujo de Datos: Replicación DR

Sender Node (primary PVE)              Receiver Node (DR PVE)
--------------------------             ----------------------
Backend (mode=seed)                    Backend (mode=receiver)
  |                                      |
  |  1. TLS handshake (PSK/cert)         |  Listening on :9190
  +------------------------------------->|
  |                                      |  2. Validate auth token/cert
  |  3. VM metadata (config, disk list)  |
  +------------------------------------->|
  |                                      |  4. Provision VM in PVE inventory
  |  5. Disk data stream (extents)       |
  +------------------------------------->|
  |                                      |  6. Write extents to storage
  |  7. Completion + bitmap checkpoint   |
  +------------------------------------->|
  |                                      |  8. Finalize VM, mark ready

5. Referencia Detallada de Funcionalidades

5.1 Backup de VM — Completo, Incremental, Diferencial

El plugin soporta tres niveles de backup alineados con el modelo de tipo de Job de Bacula:

Completo: Todos los extents de disco de todas las VMs seleccionadas se transmiten desde el nodo PVE al Bacula Storage Daemon. Se crea un snapshot consistente en el lado PVE antes de la lectura, garantizando consistencia ante fallos. Si quiesce=yes, se invoca el agente guest de QEMU para congelar los sistemas de archivos antes de la creación del snapshot.

Incremental: Después de un backup completo, los bitmaps sucios CBT (Changed Block Tracking) de QEMU registran qué extents de disco de 64KB han sido escritos desde el último backup. El plugin consulta estos extents de bitmap vía NBD y transmite únicamente los bloques modificados. Esto puede reducir el volumen de datos de backup entre un 90-98% para cargas de trabajo típicas.

Diferencial: Similar al incremental, pero el punto de referencia del bitmap es siempre el último backup completo en lugar del último Job. Esto simplifica las cadenas de restauración (completo + un diferencial) a costa de backups diferenciales ligeramente más grandes en comparación con los incrementales.

5.2 Replicación VM DR — Replicación entre Nodos

El subsistema de replicación DR está diseñado para recuperación ante desastres sin herramientas adicionales. Requiere:

  • Un segundo nodo Proxmox VE (sitio DR)
  • Conectividad de red en el puerto TCP 9190 entre los nodos
  • El plugin instalado en ambos nodos

El aprovisionamiento automático de VM en el receptor significa que los operadores no necesitan crear manualmente la VM de destino — el plugin crea la configuración de VM, asigna almacenamiento y registra la VM en el inventario de Proxmox de forma automática. Las ejecuciones de replicación siguientes transmiten únicamente los extents modificados.

5.3 Conversión entre Hipervisores

Rutas de conversión validadas:

Origen Destino Estado
VMware vSphere (VMDK) Proxmox VE (qcow2/raw) Validado en producción
Microsoft Hyper-V (VHDX) Proxmox VE (qcow2/raw) Validado en producción
Proxmox VE (qcow2) Proxmox VE (raw) Nativo

El motor de conversión gestiona la traducción de formato de disco, el mapeo de configuración de VM, la normalización del controlador de almacenamiento y la generación del archivo .conf de Proxmox post-conversión.

5.4 Seguridad TLS — Anclaje de Huella Digital SHA-256

El plugin se comunica con la API de Proxmox mediante HTTPS:8006. En lugar de requerir una implementación PKI completa o deshabilitar la verificación TLS, el plugin implementa anclaje de huella digital SHA-256: el operador proporciona el hash SHA-256 conocido del certificado TLS del nodo Proxmox en el parámetro pve_fingerprint. El backend valida esta huella digital en cada conexión, previniendo ataques MITM incluso con certificados autofirmados.

5.5 Recuperación Instantánea (IR) — Arranque por Overlay NBD

La Recuperación Instantánea elimina la espera de una restauración completa de disco montando el volumen de backup como una exportación NBD directamente accesible por el nodo PVE. Proxmox arranca la VM usando este disco respaldado por NBD de inmediato. Una capa overlay captura las nuevas escrituras, de modo que la VM puede operar con normalidad durante la migración en segundo plano.

La migración en segundo plano copia los extents del disco desde el overlay NBD al target_storage final de forma transparente. Una vez completada la migración, la VM queda completamente desconectada del volumen de backup. El backup original se conserva sin modificaciones.

5.6 Quiesce/Freeze — Backups Consistentes a Nivel de Aplicación

Cuando quiesce=yes (valor predeterminado), el plugin emite guest-fsfreeze-freeze al agente guest de QEMU instalado en la VM antes de crear el snapshot de Proxmox. Después de que se crea el snapshot (típicamente en menos de 1 segundo), se emite guest-fsfreeze-thaw y la VM reanuda su operación normal. La ventana total de congelamiento es típicamente de 200-800ms, imperceptible para los usuarios finales.

Si el agente guest no está en ejecución o no está instalado, el plugin recurre a la creación de snapshot con consistencia ante fallos y registra una advertencia.

5.7 Soporte de Múltiples Formatos de Disco

Formato Lectura Escritura Notas
qcow2 Sí Sí Formato nativo de Proxmox, soporta bitmaps CBT
raw Sí Sí Máximo rendimiento, sin sobrecarga de formato
vmdk Sí Sí (conversión) Para flujos de trabajo de importación/exportación de VMware

5.8 Automatización de Programación

No se requieren daemons adicionales, entradas cron ni schedulers externos. El plugin aprovecha íntegramente el scheduler nativo de Bacula. El entorno de validación en producción fue probado con intervalos de programación de 5 minutos con todos los Jobs completándose correctamente, demostrando la idoneidad del plugin para requisitos de alta frecuencia y RPO corto.

6. Procedimiento de Instalación

6.1 Requisitos previos

Antes de instalar, verifique:

  • PodHeitor Backup+ está instalado y operativo (Director, SD, FD)
  • El Bacula File Daemon está en ejecución en el nodo Proxmox VE de destino
  • Proxmox VE 8.0+ está en ejecución sobre Debian 11+
  • El usuario de la API de Proxmox tiene los permisos adecuados (véase la sección 6.3)
  • El puerto TCP 9102 (FD) está abierto entre el Director y el nodo PVE
  • El puerto TCP 9190 está abierto entre los nodos PVE (si se usa replicación DR)

6.2 Instalación del plugin en el nodo PVE

Paso 1: Desplegar los archivos binarios

# On the PVE node (Debian 12)
mkdir -p /usr/lib/bacula/plugins

# Copy the compiled shared library and backend binary
cp podheitor-proxmox-fd.so /usr/lib/bacula/plugins/
cp podheitor-proxmox-backend /usr/lib/bacula/plugins/

# Set ownership and permissions
chown root:bacula /usr/lib/bacula/plugins/podheitor-proxmox-fd.so
chown root:bacula /usr/lib/bacula/plugins/podheitor-proxmox-backend
chmod 750 /usr/lib/bacula/plugins/podheitor-proxmox-fd.so
chmod 750 /usr/lib/bacula/plugins/podheitor-proxmox-backend

Paso 2: Configurar el Bacula File Daemon para cargar el plugin

Edite /etc/bacula/bacula-fd.conf en el nodo PVE:

FileDaemon {
  Name = proxmox-pve1-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  Plugin Directory = /usr/lib/bacula/plugins
  Maximum Concurrent Jobs = 10
}

Paso 3: Reiniciar el Bacula File Daemon

systemctl restart bacula-fd
systemctl status bacula-fd

Paso 4: Verificar que el plugin se cargó

journalctl -u bacula-fd | grep -i podheitor
# Expected: "Loaded plugin: podheitor-proxmox-fd.so"

6.3 Configuración del usuario de la API de Proxmox

# On the PVE node
pveum user add bacula@pam --comment "Bacula backup user"
pveum passwd bacula@pam

# Required roles
pveum aclmod / -user bacula@pam -role PVEAuditor
pveum aclmod /vms -user bacula@pam -role PVEVMAdmin
pveum aclmod /storage -user bacula@pam -role PVEDatastoreAdmin

6.4 Obtener la huella digital TLS

openssl x509 -in /etc/pve/pve-ssl.pem -noout -fingerprint -sha256 | 
  sed 's/SHA256 Fingerprint=//'

Registre este valor para el parámetro pve_fingerprint en sus FileSets.

6.5 Configuración del Director

Client {
  Name = proxmox-pve1-fd
  Address = 192.168.15.129
  FDPort = 9102
  Catalog = MyCatalog
  Password = "your-fd-password"
  File Retention = 90 days
  Job Retention = 90 days
  AutoPrune = yes
}

6.6 Verificar la conectividad

bconsole
*status client=proxmox-pve1-fd
# Expected: Connected, version info, and plugin list

6.7 Configuración del receptor DR (opcional)

En el nodo PVE secundario (sitio DR), ejecute los mismos pasos de instalación (6.1-6.4). No se requiere configuración adicional en el receptor — el plugin inicia en modo receptor cuando se especifica mode=receiver en el FileSet.

# From primary PVE node to DR PVE node
nc -zv 192.168.15.102 9190

7. Guía de dimensionamiento y configuración

7.1 Dimensionamiento de componentes

Bacula Director

Nivel CPU RAM Almacenamiento (Catálogo) Notas
Mínimo 4 vCPU 8 GB 500 GB Hasta 50 VMs, retención de 30 días
Recomendado 8 vCPU 16 GB 2 TB Hasta 500 VMs, retención de 90 días
Gran escala 16 vCPU 32 GB 10 TB+ 1000+ VMs, retención de 1 año

Bacula Storage Daemon

Nivel CPU RAM Throughput de disco Notas
Mínimo 4 vCPU 8 GB 500 MB/s <10 flujos de backup simultáneos
Recomendado 8 vCPU 32 GB 2+ GB/s Hasta 50 flujos simultáneos
Gran escala 16+ vCPU 64 GB 10+ GB/s 100+ flujos simultáneos

Bacula File Daemon (en nodo PVE)

Nivel CPU RAM Notas
Mínimo 2 vCPU 4 GB Compartido con la sobrecarga de PVE
Recomendado 4 vCPU 8 GB Permite backups paralelos de VMs

Red

Escenario Mínimo Recomendado
Backup local (PVE a SD en la misma red) 1 Gbps 10 Gbps
Replicación DR (entre sitios) 100 Mbps 1 Gbps
Replicación DR por WAN 10 Mbps (con compresión) 100 Mbps

7.2 Ajuste de rendimiento

Backups simultáneos de VMs: configure Maximum Concurrent Jobs en la configuración del FD. Cada backup simultáneo de VM utiliza aproximadamente 200-500 MB de RAM en el backend para el almacenamiento en búfer.

Compresión: habilite la compresión del Bacula SD (Compression = LZ4 en las opciones del FileSet) para cargas de trabajo limitadas por CPU donde el throughput de disco es el cuello de botella.

Intervalo de incrementales: para VMs muy activas (alta tasa de escritura), intervalos incrementales más cortos (cada hora) producen deltas por Job más pequeños y backups más rápidos.

8. Matriz de compatibilidad

8.1 Versiones de componentes validadas

Componente Versión mínima Versión probada Estado de validación
PodHeitor Backup 15.0.0 15.0.3 Validado en producción
Proxmox VE 8.0 8.4.18 Validado en producción
Debian (host PVE) 11 (Bullseye) 12 (Bookworm) Validado en producción
RHEL / Oracle Linux (Director) 8 9.6 Validado en producción
Ubuntu (Director/SD) 22.04 LTS 24.04 LTS Compatible (probado por la comunidad)
PostgreSQL (Catálogo) 13 14+ Validado en producción
QEMU (vía PVE) 8.0 9.2 Validado
Linux Kernel (host PVE) 6.1 6.8 Validado

8.2 Compatibilidad de hipervisores de origen (conversión)

Hipervisor de origen Versión de origen Estado
VMware vSphere 6.7, 7.0, 8.0 Validado en producción
VMware Workstation 16, 17 Compatible
Microsoft Hyper-V 2019, 2022 Validado en producción
KVM / libvirt Cualquiera Nativo (qcow2/raw)
VirtualBox 7.0 Compatible (exportación VMDK)

8.3 Compatibilidad de backends de almacenamiento (PVE)

Tipo de almacenamiento Proxmox Backup Restauración Recuperación instantánea Notas
local-lvm (LVM-thin) Sí Sí Sí Recomendado para producción
local (directorio) Sí Sí Sí Formato qcow2
NFS Sí Sí Limitado El rendimiento de recuperación instantánea puede variar
Ceph RBD Sí Sí Sí Thin-provisioning nativo
ZFS Sí Sí Sí Compatible con snapshots

9. Referencia de parámetros

9.1 Parámetros de conexión PVE

Parámetro Alias Valor por defecto Obligatorio Descripción
pve_host pvehost, host — Sí Dirección IP o nombre de host del nodo PVE
pve_user pveuser, user root@pam No Nombre de usuario de la API PVE (formato usuario@realm)
pve_password pvepassword, password — Sí Contraseña del usuario de la API PVE
pve_port pveport, port 8006 No Puerto HTTPS para la API REST de PVE
pve_realm pverealm, realm pam No Realm de autenticación (pam, pve, ldap)
pve_fingerprint pvefingerprint, fingerprint — Recomendado Huella digital SHA-256 del certificado TLS de PVE
pve_insecure pveinsecure no No Establezca yes para deshabilitar la verificación del certificado TLS (no recomendado)

9.2 Parámetros de selección de VM

Parámetro Alias Valor por defecto Obligatorio Descripción
vm — * No VMID, nombre de VM o patrón comodín. * selecciona todas las VMs del nodo
exclude — (ninguno) No Lista de VMIDs separados por comas a excluir del backup
node — (nombre de host) No Apunta a un nodo específico del clúster PVE por nombre

9.3 Parámetros de backup

Parámetro Alias Valor por defecto Obligatorio Descripción
mode — backup No Modo de operación: backup, receiver, seed, incremental
backup_type — full No Nivel de backup: full, incremental, differential
quiesce — yes No Emite guest-fsfreeze antes del snapshot para consistencia de la aplicación
include_config — yes No Incluir el archivo de configuración de la VM en el backup
include_firewall — yes No Incluir las reglas del firewall de PVE en el backup
storage storageid bacula-store No ID de almacenamiento PVE donde los snapshots se retienen temporalmente

9.4 Parámetros NBD

Parámetro Alias Valor por defecto Obligatorio Descripción
nbd_host nbdhost auto No Nombre de host para el servidor NBD. auto utiliza la dirección del nodo PVE
nbd_port nbdport 10809 No Puerto TCP para el servidor NBD

9.5 Parámetros DR / Replicación (conjunto completo v1.1.0)

Parámetro Alias Valor por defecto Obligatorio Descripción
mode — backup Sí (para DR) bitmap-push / seed (origen) / receiver (DR) / daemon / failover-pre / failover-exec / failback-pre / failback-exec / reprotect / replication-status
dr_host drhost — Sí (origen) IP/nombre de host del nodo PVE receptor DR
dr_port drport 9100 + (vmid % 900) No Puerto TCP para el transporte DR. El valor por defecto se deriva por VMID (p. ej. 9203 para VMID 103)
target_vmid targetvmid, dr_vmid — Sí (origen) VMID a utilizar en el sitio DR para la réplica
target_storage targetstorage, dr_storage local-lvm No Pool de almacenamiento PVE en DR para los volúmenes réplica
dr_auth_token drauthtoken, dr_token — No* Secreto compartido para el transporte DR en modo PSK
dr_auth_cert drauthcert, dr_cert — No* Ruta del certificado PEM para el transporte DR con mutual-TLS (activa el modo TLS)
dr_auth_key drauthkey, dr_key — No* Ruta de la clave privada PEM para mutual-TLS
dr_ca_cert drcacert (usa dr_auth_cert como respaldo) No Paquete de certificados CA utilizado para verificar el par
max_restore_points maxrestorepoints 3 No Máximo de snapshots de puntos de restauración retenidos en DR (los más antiguos se eliminan automáticamente)
state_dir statedir /var/lib/bacula No Directorio para los archivos repl-state-*.json / dr-vm-state-*.json por VM
bitmap_granularity bitmapgranularity 65536 (64 KiB) No Granularidad del dirty-bitmap de QEMU en bytes (potencia de 2)
cycle_interval cycleinterval 300 (s) No Modo daemon: segundos entre ciclos
throttle_bps throttlebps, throttle 0 (desactivado) No Límite de ancho de banda para el transporte DR, bytes/seg
verify_sample_blocks verifysampleblocks 0 (desactivado) No v1.1.0: bloques aleatorios de 64 KiB para comparación por hash por ciclo

* dr_auth_token XOR (dr_auth_cert+dr_auth_key) — elija un modo de autenticación.

9.6 Parámetros de restauración

Parámetro Alias Valor por defecto Obligatorio Descripción
restore_path restorepath — No Ruta local para la extracción de imágenes de disco en la restauración
new_vm_name newvmname — No Nombre para la VM restaurada (reemplaza el nombre original)
target_storage targetstorage — No ID de almacenamiento PVE para los discos de la VM restaurada
overwrite_vmid overwritevmid — No VMID a sobreescribir en la restauración (destructivo; usar con precaución)
start_vm startvm, power_on no No Encender la VM automáticamente tras completar la restauración

9.7 Parámetros de recuperación instantánea

Parámetro Alias Valor por defecto Obligatorio Descripción
ir_nbd_port irnbdport auto No Puerto NBD para la exportación de disco de recuperación instantánea
ir_overlay_storage iroverlaystorage — No Almacenamiento PVE para la capa de escritura (overlay) durante la sesión de recuperación instantánea
ir_timeout irtimeout 3600 No Tiempo de espera de la sesión de recuperación instantánea en segundos antes de la migración forzada
ir_auto_migrate irautomigrate no No Iniciar automáticamente la migración en segundo plano tras el arranque de la VM

10. Ejemplos de configuración

10.1 FileSet — Backup Completo de Todas las VMs

FileSet {
  Name = "Proxmox-All-VMs-Full"
  Include {
    Options {
      signature = MD5
      Compression = LZ4
    }
    Plugin = "podheitor-proxmox:
      pve_host=192.168.15.129
      pve_user=root@pam
      pve_password=yourpassword
      pve_fingerprint=D0:C6:19:10:DA:59:68:39:E2:4E:C4:7D:2E:A9:FB:F1:75:E3:51:12:12:D6:3C:5F:51:4B:2B:21:6C:48:DC:9E
      vm=*
      backup_type=full
      quiesce=yes
      include_config=yes
      include_firewall=yes
      storage=local-lvm"
  }
}

10.2 FileSet — Backup Incremental

FileSet {
  Name = "Proxmox-All-VMs-Incremental"
  Include {
    Options {
      signature = MD5
      Compression = LZ4
    }
    Plugin = "podheitor-proxmox:
      pve_host=192.168.15.129
      pve_user=root@pam
      pve_password=yourpassword
      pve_fingerprint=D0:C6:19:10:DA:59:68:39:E2:4E:C4:7D:2E:A9:FB:F1:75:E3:51:12:12:D6:3C:5F:51:4B:2B:21:6C:48:DC:9E
      vm=*
      backup_type=incremental
      quiesce=yes
      storage=local-lvm"
  }
}

10.3 FileSet — Emisor de Replicación para DR

FileSet {
  Name = "Proxmox-Replicate-VM127-to-pve2"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-proxmox:
      pve_host=192.168.15.129
      pve_user=root@pam
      pve_password=yourpassword
      pve_fingerprint=D0:C6:19:10:DA:59:68:39:E2:4E:C4:7D:2E:A9:FB:F1:75:E3:51:12:12:D6:3C:5F:51:4B:2B:21:6C:48:DC:9E
      vm=127
      mode=seed
      dr_host=192.168.15.102
      dr_port=9190
      target_vmid=127
      nbd_port=10809
      storage=local-lvm"
  }
}

10.4 FileSet — Receptor de DR

FileSet {
  Name = "Proxmox-DR-Receiver-pve2-VM127"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-proxmox:
      mode=receiver
      pve_host=192.168.15.102
      pve_user=root@pam
      pve_password=yourpassword
      pve_fingerprint=16:A0:9C:94:BF:22:99:8E:29:38:DD:3C:D7:62:04:AC:20:A4:02:48:A0:2A:C7:3D:17:34:81:B4:9A:CC:C8:A2
      dr_port=9190
      storage=local-lvm
      target_vmid=127"
  }
}

10.5 Ejemplo Completo de Job, Schedule y Pool

Schedule {
  Name = "ProxmoxWeeklySchedule"
  Run = Full sun at 23:00
  Run = Incremental mon-sat at 23:00
}

Job {
  Name = "Proxmox-PVE1-Backup"
  Type = Backup
  Client = proxmox-pve1-fd
  FileSet = "Proxmox-All-VMs-Full"
  Schedule = "ProxmoxWeeklySchedule"
  Storage = File-Storage
  Pool = Proxmox-Pool
  Messages = Standard
  Priority = 10
  Maximum Concurrent Jobs = 5
}

Pool {
  Name = Proxmox-Pool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 90 days
  Label Format = "Proxmox-Vol-"
  Maximum Volume Bytes = 100G
}

10.6 Job de Recuperación Instantánea

Job {
  Name = "Proxmox-InstantRestore-VM127"
  Type = Restore
  Client = proxmox-pve1-fd
  FileSet = "Proxmox-All-VMs-Full"
  Storage = File-Storage
  Pool = Proxmox-Pool
  Messages = Standard
  Where = /
  Plugin Options = "
    ir_nbd_port=10810
    ir_overlay_storage=local
    ir_timeout=7200
    ir_auto_migrate=yes
    target_storage=local-lvm
    start_vm=yes"
}

11. Modelo de Seguridad

11.1 Modelo de Amenazas

El plugin aborda cuatro vectores de amenaza principales en la infraestructura de backup:

  1. Ataque de intermediario (Man-in-the-Middle) sobre la API de PVE: Mitigado mediante la verificación por huella digital SHA-256 del certificado
  2. Acceso no autorizado al backup: Mitigado mediante la autenticación del Bacula Director y la validación de contraseña del FD
  3. Interceptación del transporte de DR: Mitigado mediante PSK o TLS mutuo en el canal de transporte de DR
  4. Exposición de credenciales: Mitigado mediante el catálogo cifrado de Bacula y los permisos de archivo restringidos

11.2 Verificación por Huella Digital TLS

A diferencia de la validación de certificados tradicional basada en CA, la verificación por huella digital comprueba los bytes exactos del certificado del servidor de destino. Esto resulta especialmente adecuado para entornos Proxmox donde los certificados autofirmados son estándar y el conjunto de servidores de confianza es conocido y estático.

Cómo obtener la huella digital:

# Opción 1: Mediante OpenSSL en el nodo PVE
openssl x509 -in /etc/pve/pve-ssl.pem -noout -fingerprint -sha256

# Opción 2: Mediante la interfaz web de PVE
# Dashboard -> Nodo -> Certificados -> Huella digital (SHA-256)

11.3 Seguridad del Transporte de DR

Modo PSK (dr_auth_token): Autenticación HMAC a nivel de sesión mediante el token compartido. Recomendado para replicación en el mismo centro de datos o a través de sitios protegidos por VPN.

Modo TLS con Certificado (dr_auth_cert + dr_auth_key): TLS mutuo completo. Requerido para segmentos de red no confiables (internet público, interconexiones entre colocation).

11.4 Buenas Prácticas de Gestión de Credenciales

  • Almacenar las contraseñas de PVE en el almacén de credenciales cifradas de Bacula o utilizar inyección de variables de entorno
  • Utilizar usuarios de API dedicados con los privilegios mínimos necesarios (véase la Sección 6.3) en lugar de root@pam
  • Rotar los tokens de autenticación de DR de forma periódica (se recomienda trimestralmente)
  • Restringir los permisos del directorio /usr/lib/bacula/plugins/ a root:bacula 750
  • Auditar los registros del Bacula Director en busca de intentos de restauración no autorizados

11.5 Recomendaciones de Segmentación de Red

+-------------------+    TCP:9102     +--------------------+
| Bacula Director   +---------------->+  PVE Node FD       |
| (red de gestión)  |                 | (red del hypervisor)|
+-------------------+                 +--------------------+
                                               |  TCP:9190
                                               v
                                      +--------------------+
                                      |  DR PVE Node FD    |
                                      | (red del sitio DR) |
                                      +--------------------+

Reglas de firewall requeridas:
  Director -> PVE FD:   TCP 9102 entrante
  PVE FD -> Bacula SD:  TCP 9103 saliente
  PVE Principal -> PVE DR: TCP 9190 saliente
  PVE DR:               TCP 9190 entrante (solo desde el principal)

12. Comparativa Competitiva

12.1 Tabla de Comparación de Funcionalidades

Funcionalidad Plugin PodHeitor Veeam B&R Commvault Bacula Enterprise
Backup de Proxmox VE Nativo Limitado (v12 beta) Solo mediante agente Nativo
Incremental CBT Bitmaps dirty de QEMU CBT de VMware CBT Bitmaps dirty de QEMU
Consistencia de aplicaciones Agente QEMU (fsfreeze) VSS/VMware tools VSS Agente QEMU
Recuperación Instantánea Overlay NBD Instant VM Recovery Live Recovery Sí
Replicación de DR Integrada Jobs de replicación Sí Limitado
Migración de VMware a Proxmox Validado No soportado No soportado No soportado
Migración de Hyper-V a Proxmox Validado No soportado No soportado No soportado
Verificación por huella digital TLS Sí Requiere PKI completo Requiere PKI completo Sí
Integración con Bacula Plugin nativo Producto separado Producto separado Nativo
Sin daemons adicionales Sí No No Sí
Binario nativo de Linux Sí (Rust, binario nativo) Principalmente Windows Mixto Sí

12.2 Modelo de Licenciamiento y Costos

Solución Modelo de Licenciamiento VMs Proxmox Costo de Entrada
Plugin PodHeitor Tarifa plana comercial por nodo Ilimitadas por nodo Consultar precios
Veeam B&R Por socket de carga de trabajo o por VM Cobrado por VM Costo elevado por VM
Commvault Por TB o por núcleo Por agente o por TB Complejo, costo elevado
Bacula Enterprise Por front-end + módulos Licencia por módulo Suscripción anual
Proxmox PBS Gratuito / código abierto Ilimitadas US$ 0 (sin integración con Bacula)

12.3 Simplicidad Arquitectónica

Solución Nuevos Componentes Requeridos Servidor Dedicado Entre Hypervisores
Plugin PodHeitor Solo .so + binario del backend No VMware + Hyper-V validados
Veeam Servidor VBR + VMs Proxy Sí (Windows) Soporte limitado para Proxmox
Commvault CommServe + MediaAgent + Agentes Sí Sí (licenciamiento complejo)
Bacula Enterprise FD Enterprise + módulo plugin Director (existente) Limitado

Diferenciador clave: El plugin PodHeitor no requiere ninguna infraestructura nueva. Si PodHeitor Backup ya está desplegado, agregar protección para Proxmox es simplemente copiar un archivo y modificar la configuración.

12.4 Evidencia de Laboratorio — v1.1.0 (2026-04-24)

Los siguientes son extractos reales de registros capturados durante la ejecución de la prueba de aceptación pre-GA (transcripción completa en docs/GATE_REPORT_2026-04-24.md). No son sintéticos — el localhost-dir JobId 3448 es un Job real del Bacula Director en el Director Oracle Linux 9.6 en 192.168.15.105.

Seed de una VM de 100 GB, origen → DR

2026-04-24 00:26:43 INFO Starting seed cycle for VM 103
2026-04-24 00:26:43 INFO Connecting to DR receiver at 192.168.15.102:9203
2026-04-24 00:26:43 INFO PSK encryption established (client)
2026-04-24 00:26:47 INFO NBD export size: 107374182400 bytes (102400 MB)
2026-04-24 00:26:51 INFO Seed progress: 0.2% (256 MB) chunk 64/25600 — 3.7s
…
2026-04-24 02:00:24 INFO Seed complete for VM 103: 1 disks, 102400.00 MB in 5623.5s

En el lado del DR de forma simultánea:

2026-04-23 18:26:41 INFO Provisioning replica VM 203 (source VM 103)
2026-04-23 18:26:41 INFO Created VM 203 on node pve2
2026-04-23 18:26:42 INFO Allocated disk: local-lvm:vm-203-disk-0 for VM 203
2026-04-23 18:26:47 INFO Receiving full disk seed for scsi0: 107374182400 bytes
2026-04-23 19:59:42 INFO Full disk done for scsi0: 107374182400 bytes written

Verificación de integridad muestreada en un incremental

2026-04-24 07:42:12 INFO Integrity verify OK for scsi0: 10 blocks, all match
2026-04-24 07:42:15 INFO Incremental complete for VM 103: 1 disks, 160 regions, 281.06 MB in 155.9s

Quince ciclos consecutivos produjeron 150 comparaciones de bloques de muestra, cero discrepancias (tabla completa en docs/GATE_REPORT_2026-04-24.md).

Ciclo de replicación con TLS mutuo

2026-04-24 08:00:39 INFO TLS (mutual-cert) handshake with 192.168.15.102
2026-04-24 08:00:52 INFO Integrity verify OK for scsi0: 10 blocks, all match
2026-04-24 08:00:55 INFO Incremental complete for VM 103: 1 disks, 28 regions, 3.31 MB in 15.5s

Failover planificado (arrancar réplica en DR)

2026-04-24 01:42:51 INFO PVE POST https://127.0.0.1:8006/api2/json/nodes/pve2/qemu/203/status/start
2026-04-24 01:42:51 INFO Failover: started VM 203 on DR site

Job dirigido por Bacula Director — salida real de bconsole

  JobId:                  3448
  Job:                    Proxmox-Replicate-VM103-Incremental.2026-04-24_08.16.31_02
  Backup Level:           Full (upgraded from Incremental)
  Client:                 "proxmoxlab-fd" 15.0.3 x86_64-pc-linux-gnu-bacula,debian,12.0
  FileSet:                "Proxmox-Replicate-VM103"
  Non-fatal FD errors:    0
  SD Errors:              0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            Backup OK

Instalación llave en mano con .deb en nodo DR Debian 13 PVE 9

$ apt-get install ./podheitor-proxmox-plugin_1.1.0_amd64.deb
Setting up podheitor-proxmox-plugin (1.0.0-1) ...

$ systemctl enable --now podheitor-receiver@103.service
Created symlink '/etc/systemd/system/multi-user.target.wants/podheitor-receiver@103.service'
   → '/etc/systemd/system/podheitor-receiver@.service'.

$ ss -tlnp | grep 9203
LISTEN 0 128 0.0.0.0:9203 users:(("podheitor-proxm",pid=204793,fd=4))

Emisor JSON del dashboard — salida real

{
  "generated_at": "2026-04-24T08:45:12+00:00",
  "source_vms": {
    "103": {
      "source_vmid": 103, "target_vmid": 203,
      "source_host": "proxmoxlab", "target_host": "192.168.15.102",
      "seeded": true, "total_cycles": 17,
      "rpo_actual_seconds": 132,
      "last_cycle": {
        "cycle_type": "incremental",
        "bytes_sent": 1638400, "regions_sent": 8,
        "duration_secs": 29.1, "success": true
      }
    }
  },
  "dr_vms": {
    "103": {
      "source_vmid": 103, "local_vmid": 203,
      "provisioned": true,
      "disks": [{"device":"scsi0","path":"/dev/pve/vm-203-disk-0",
                 "size_bytes":107374182400,"seeded":true}],
      "restore_point_count": 7
    }
  }
}

13. Análisis de TCO y ROI

13.1 Escenario: Entorno Proxmox con 100 VMs, TCO a 3 Años

Supuesto de partida: La organización ya ejecuta PodHeitor Backup para backup de archivos y bases de datos.

Opción A: Plugin PodHeitor para Proxmox

Elemento de Costo Año 1 Año 2 Año 3
Licencia del plugin (por nodo, 2 nodos) Consultar Renovación Renovación
Infraestructura adicional US$ 0 US$ 0 US$ 0
Capacitación (personal familiarizado con Bacula) Mínima US$ 0 US$ 0

Opción B: Veeam Backup & Replication (Enterprise Plus)

Elemento de Costo Notas
Licencia por VM (100 VMs) Cobro anual, escala con el número de VMs
Servidor Proxy de Veeam (Windows) Se requiere hardware + licencia de SO
Capacitación del personal Nueva plataforma, nueva consola de gestión
Mantenimiento y soporte Contrato anual requerido

Opción C: Solo Proxmox Backup Server

Elemento de Costo Notas
Licencia PBS US$ 0
Brecha en reportes de cumplimiento Costo de riesgo: sin catálogo de auditoría unificado
Brecha en capacidades de DR Costo de riesgo: sin orquestación empresarial de DR

13.2 Factores de ROI

Reducción de la ventana de backup: Los backups incrementales con CBT reducen el volumen de datos de backup entre un 90 y un 98%, lo que recorta el ancho de banda de red, la carga de E/S de almacenamiento y la duración de la ventana de backup.

Reducción del tiempo de restauración: La Recuperación Instantánea elimina la brecha de RTO. Una restauración tradicional de 4 horas se convierte en una operación de arranque NBD de 5 minutos.

Eliminación de costos de migración: La conversión entre hypervisores desde VMware o Hyper-V elimina la necesidad de herramientas de migración dedicadas, que en los productos de la competencia se licencian por separado.

Ahorro por consolidación: Eliminar un despliegue paralelo de PBS y utilizar Bacula como catálogo de backup único reduce la carga administrativa, simplifica los reportes de cumplimiento y elimina la asignación duplicada de almacenamiento.

Estimación del punto de equilibrio: En un entorno típico de 50 VMs que migra desde Veeam, el costo de la licencia del plugin generalmente se recupera en 3 a 6 meses de ahorro en las tarifas de renovación de Veeam.

14. Hoja de Ruta

Versión 1.1.0 — Publicada (GA, 2026-04-24) ✅

Funcionalidad Estado
Replicación estilo Veeam (seed + incremental bitmap-push) ✅
Verificación de integridad muestreada (FNV-1a-64) entre origen y DR ✅
TLS mutuo (rustls + certificados PEM + WebPkiClientVerifier) ✅
Daemon receptor de DR autónomo (plantilla systemd, sin bacula-fd en DR) ✅
Escalado de receptor multi-VM (una instancia por VMID mediante @.service) ✅
Failover planificado (failover-exec) + failback (failback-pre) ✅
Emisor JSON del dashboard (--mode=replication-status --vm=*) ✅
Paquetes llave en mano .deb + .rpm ✅

Versión 1.1.1 — Planificada (mejoras a corto plazo)

Funcionalidad Descripción Prioridad
Asistente mkcerts.sh Generador en un solo paso de CA X.509 v3 + certificados DR + origen Alta
Flujos de backup cifrados AES-256 de extremo a extremo a nivel del plugin (ruta de backup) Alta
Limitación de ancho de banda Límites por Job y por nodo para el transporte bitmap-push Alta
Reportes de CBT mejorados Estadísticas de bloques modificados por VM en el catálogo de Bacula Media
API REST para orquestación API HTTP para disparar backups sin bconsole Media

Versión 1.2 — Planificada

Funcionalidad Descripción Prioridad
Soporte multi-clúster Un único FileSet apuntando a múltiples clústeres PVE Alta
Contenedores Proxmox (LXC) Backup y replicación de contenedores LXC Alta
Restauración directa compatible con S3 Restaurar directamente desde S3/MinIO sin enrutamiento por SD Media
Scripts pre/post backup Scripts de hook por VM ejecutados antes y después del backup Media
Verificación de integridad de disco completo (mode=verify-full) Auditoría de hash de disco completo programada Media

Versión 2.0 — Futuro

Funcionalidad Descripción Prioridad
Protección Continua de Datos (CDP) Replicación casi en tiempo real mediante journal de bloques QEMU Alta
Integración con interfaz web de Bacularis Paneles nativos en la UI de Bacularis para el estado del plugin Alta
VMs HA en clúster Proxmox Seguimiento transparente de VMs HA entre nodos durante el backup Media
Backup de PV de Kubernetes Protección de PersistentVolumes en Kubernetes alojado sobre Proxmox Media
Importación a Azure/AWS Subida directa de imágenes de VM convertidas a plataformas en la nube Baja

15. Conclusión

El Plugin PodHeitor de Backup, Replicación y Conversión para Proxmox con Bacula representa una solución madura y validada en producción para un desafío empresarial real y urgente: extender una estrategia de backup unificada a Proxmox VE sin adoptar plataformas adicionales, incurrir en costos de licenciamiento por VM desproporcionados ni comprometer las capacidades de DR y consistencia de aplicaciones.

Con más de 1.290 Jobs de producción completados exitosamente, soporte para backups incrementales indefinidos mediante bitmaps dirty de QEMU, replicación de DR con seguridad TLS y aprovisionamiento automático de VMs, recuperación instantánea mediante overlay NBD y conversión entre hypervisores validada desde VMware y Hyper-V, este plugin ofrece protección de datos de nivel empresarial a una fracción del costo de las soluciones competidoras.

Las organizaciones que ya ejecutan PodHeitor Backup obtienen protección completa de VMs Proxmox desplegando dos archivos binarios y actualizando la configuración de su Director. No hay nuevos servidores que aprovisionar, ni nuevas consolas de gestión que aprender, ni cargos por VM que presupuestar.

Llamada a la Acción

¿Listo para evaluar el Plugin PodHeitor para Proxmox en su entorno?

Contacte a Heitor Faria para analizar su entorno específico, obtener una licencia de prueba de concepto o programar una demostración técnica:

Canal Contacto
Correo electrónico heitor@opentechs.lat
Teléfono (EE. UU.) +1 786 726-1749
WhatsApp (BR) +55 61 98268-4220

Se ofrecen compromisos de prueba de concepto para oportunidades empresariales calificadas. La validación de arquitecturas de referencia, el soporte de instalación y el desarrollo de funcionalidades a medida pueden coordinarse comercialmente.

Licenciamiento

PodHeitor Proxmox 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?

16. Aviso Legal y Contacto

OFERTA ESPECIAL — TRAIGA SU PROPUESTA DE RENOVACIÓN

¿Está evaluando o renovando actualmente un contrato de Bacula Enterprise, Veeam, Commvault o Netbackup?

Traiga su propuesta y le garantizamos un descuento mínimo del 50% — con muchas más funcionalidades.

El Plugin PodHeitor para Proxmox ofrece backup nativo de VMs en Proxmox, replicación de DR, recuperación instantánea y migración entre hypervisores en un único producto, integrado de forma nativa con PodHeitor Backup — a una fracción del costo de los proveedores de backup empresarial tradicionales.

Contacto:
Autor Heitor Faria
Empresa PodHeitor / OpenTechs
Correo electrónico heitor@opentechs.lat
Teléfono (EE. UU.) +1 786 726-1749
WhatsApp (Brasil) +55 61 98268-4220

Aviso Legal:

Copyright 2026 Heitor Faria — Todos los Derechos Reservados.

Este whitepaper y el producto descrito están protegidos por derechos de autor. La reproducción, redistribución o divulgación de este documento o cualquier parte del mismo sin autorización escrita de Heitor Faria está prohibida.

El producto descrito en este documento se licencia comercialmente. Los derechos de evaluación, desarrollo y redistribución se rigen por el acuerdo de licencia comercial aplicable. El uso no autorizado, la ingeniería inversa o la redistribución de los binarios del plugin están prohibidos.

Todas las marcas comerciales mencionadas en este documento (Proxmox, Bacula, VMware, Veeam, Commvault, Veritas, Red Hat, Oracle, Debian, Microsoft Hyper-V) son propiedad de sus respectivos dueños. Su mención no implica afiliación ni respaldo alguno.

17. Apéndice

A. Glosario

Término Definición
Bacula Programa de backup, restauración y verificación empresarial de código abierto, compuesto por los componentes Director, Storage Daemon, File Daemon y Consola.
Bacula Director Componente central de gestión que dirige las operaciones de backup y restauración, mantiene el catálogo y ejecuta el planificador.
Bacula File Daemon (FD) Agente del lado cliente instalado en el sistema que se respalda. Para los backups de Proxmox, se instala en el host hypervisor PVE.
Bacula Storage Daemon (SD) Componente responsable de leer y escribir los datos de backup en los volúmenes de almacenamiento.
API de plugin de Bacula Interfaz de plugin de biblioteca compartida de Bacula, que permite a código de terceros extender la funcionalidad del FD mediante dlopen.
CBT (Changed Block Tracking) Mecanismo mediante el cual QEMU registra qué extensiones de disco han sido escritas desde el último backup, permitiendo la transferencia exclusiva de datos incrementales.
Canal de comunicación interno Canal de comunicación interno entre el plugin FD y el proceso backend, utilizado para el control de jobs y la transferencia de datos.
PVE (Proxmox VE) Proxmox Virtual Environment — plataforma hypervisor de código abierto basada en KVM y LXC, con API de gestión integrada.
QEMU Emulador y virtualizador de máquinas de código abierto. Proxmox VE usa QEMU/KVM para la ejecución de VMs.
QMP (QEMU Monitor Protocol) Protocolo basado en JSON sobre un socket de dominio Unix para controlar y consultar una instancia QEMU en ejecución.
NBD (Network Block Device) Protocolo para exportar dispositivos de bloque sobre TCP, utilizado por el plugin para leer los datos del disco de la VM desde snapshots de QEMU.
CBT Dirty Bitmap Estructura de datos por disco de QEMU que registra qué extensiones alineadas a 64 KB han sido modificadas desde el último punto de control de backup.
Quiesce / Freeze (Congelamiento) El proceso de pausar las escrituras del sistema de archivos en una VM antes de crear el snapshot para garantizar la consistencia de los datos.
QEMU Guest Agent Daemon instalado dentro de la VM que responde a comandos QMP del hypervisor, habilitando fsfreeze/thaw para backups con consistencia de aplicaciones.
Fingerprint Pinning (Verificación por Huella Digital) Técnica de seguridad TLS en la que el hash SHA-256 esperado del certificado de un servidor se codifica de forma fija, previniendo ataques MITM incluso con certificados autofirmados.
PSK (Pre-Shared Key, Clave Precompartida) Método de autenticación en el que se configura un secreto compartido en ambas partes que se comunican, utilizado para la autenticación del transporte de DR.
Recuperación Instantánea (IR) Técnica para arrancar una VM directamente desde su volumen de backup mediante overlay NBD, logrando un RTO cercano a cero antes de la migración completa al almacenamiento local.
RPO (Recovery Point Objective) Pérdida de datos máxima aceptable medida en tiempo. Un RPO más corto requiere backups más frecuentes.
RTO (Recovery Time Objective) Tiempo máximo aceptable para restaurar el servicio tras un fallo. La Recuperación Instantánea reduce drásticamente el RTO.
TCO (Total Cost of Ownership, Costo Total de Propiedad) Costo completo de una solución a lo largo de su ciclo de vida, incluyendo licenciamiento, infraestructura, capacitación y gastos operativos.
DR (Disaster Recovery, Recuperación ante Desastres) Políticas y procedimientos para recuperar la infraestructura de TI tras un fallo grave o desastre.
VMDK Formato de disco de máquina virtual de VMware. Utilizado por vSphere y Workstation como formato nativo de disco de VM.
VHDX Formato de disco duro virtual extendido utilizado por Microsoft Hyper-V.
qcow2 QEMU Copy-On-Write versión 2 — formato de disco nativo de Proxmox VE con soporte para snapshots, cifrado y compresión.
LVM-thin Aprovisionamiento delgado del Logical Volume Manager — utilizado por el almacenamiento local-lvm de Proxmox para la asignación eficiente de discos de VM.
Bacularis Interfaz de gestión web para Bacula, que proporciona una GUI para la gestión de Jobs, exploración del catálogo y reportes.
PBS (Proxmox Backup Server) Producto dedicado de servidor de backup de Proxmox, optimizado para PVE pero sin integración en marcos de backup externos.

B. Diagrama de Arquitectura de Referencia (Entorno de Producción)

Entorno de Producción (Validado en abril de 2026)
Red: 192.168.15.0/24

+--------------------------------------------------------------+
|  Bacula Director + Storage Daemon                            |
|  Oracle Linux 9.6 / RHEL 9.6                                 |
|  PostgreSQL 14+ (Catálogo)                                   |
|  PodHeitor Backup                                     |
+------------------------+-------------------------------------+
                         | TCP:9102 / TCP:9103
           +-------------+-------------+
           v                           v
+----------------------+   +----------------------+
|  proxmoxlab          |   |  pve2                |
|  Proxmox VE 8.4.18   |   |  Proxmox VE 8.4.18   |
|  Debian 12 (amd64)   |   |  Debian 12 (amd64)   |
|  IP: 192.168.15.129  |   |  IP: 192.168.15.102  |
|  Bacula FD           |   |  Bacula FD           |
|  podheitor plugin    |   |  podheitor plugin    |
|  (mode=seed)         |   |  (mode=receiver)     |
+----------------------+   +----------------------+
          |     TCP:9190 (PSK/TLS)        ^
          +-----------------------------------+

Jobs ejecutados: 1290+ (todos T = Terminated OK)
Schedule probado: intervalo de 5 minutos
Replicación DR: validada con verificación por huella digital TLS

C. Preguntas Frecuentes

P: ¿Puede el plugin respaldar VMs que están apagadas? R: Sí. Las VMs apagadas se respaldan directamente desde sus imágenes de disco sin necesidad de crear un snapshot. El quiesce se omite automáticamente para las VMs apagadas.

P: ¿Qué ocurre si el agente invitado de QEMU no está instalado en la VM? R: El plugin recurre a un backup con consistencia de fallo (snapshot sin freeze). Se registra una advertencia. El backup se completa exitosamente; la consistencia de aplicaciones no está garantizada, pero sí la consistencia de fallo.

P: ¿Puedo usar este plugin con Bacula Enterprise? R: El plugin implementa la API estándar de plugins de Bacula y es compatible tanto con PodHeitor Backup como con las versiones 15.0.0 y posteriores del FD de Bacula Enterprise.

P: ¿Cuántas VMs se pueden respaldar de forma concurrente? R: La concurrencia está limitada por Maximum Concurrent Jobs en el File Daemon y los recursos del sistema disponibles en el nodo PVE. Se han realizado pruebas con hasta 10 backups de VM concurrentes en un nodo PVE de 32 núcleos sin degradación del rendimiento.

P: ¿Los datos de backup están cifrados en reposo? R: El cifrado en reposo es gestionado por la configuración de cifrado de volúmenes del Bacula Storage Daemon, que es independiente de este plugin. El plugin se integra de forma transparente con cualquier cifrado de SD configurado.

P: ¿Puedo restaurar en un nodo PVE diferente al del origen del backup? R: Sí. Use los parámetros target_storage y new_vm_name para restaurar en cualquier nodo PVE donde esté instalado el FD del plugin.

P: ¿Este plugin soporta operaciones de clúster Proxmox (migración en vivo durante el backup)? R: Actualmente, el plugin apunta a un nodo específico. El backup con conciencia de clúster completo que sigue a las VMs entre nodos está en la hoja de ruta de la Versión 2.0.

D. Referencias

  • Documentación de la API REST de Proxmox VE: https://pve.proxmox.com/pve-docs/api-viewer/
  • Referencia del QEMU Monitor Protocol (QMP): https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html
  • Especificación del Protocolo NBD: https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
  • Referencia de la API de Plugins de Bacula: https://www.bacula.org/bacula-web/developers-guide/plugin-api
  • Documentación de PodHeitor Backup: https://www.bacula.org/documentation/
  • QEMU Changed Block Tracking (CBT): https://qemu-project.gitlab.io/qemu/interop/bitmaps.html
  • Notas de la versión Proxmox VE 8.4: https://pve.proxmox.com/wiki/Roadmap

Fin del Whitepaper

Copyright 2026 Heitor Faria — Todos los Derechos Reservados heitor@opentechs.lat | +1 786 726-1749 | +55 61 98268-4220 (WhatsApp)

Disponível em: pt-brPortuguês (Portugués, Brasil)enEnglish (Inglés)esEspañol

Deja una respuesta