Blog

Whitepaper — PodHeitor Granular Restore

Whitepaper — PodHeitor Granular Restore

Recuperación granular para cualquier workload. Mailbox individual de Exchange, ítem de M365, archivo dentro de VM, tabla SQL — sin levantar el ambiente completo, en minutos.

  • Mount-on-demand — snapshot montado virtualmente, browse y recover sin extracción full.
  • Exchange / M365 — mailbox, carpeta o ítem individual, restore a mailbox distinto.
  • VM file-level — entre a cualquier VM (Windows o Linux) y recupere archivos.
  • SQL table-level — restore de tabla o fila específica sin replay del log completo.
  • Portal self-service — usuario final recupera sus propios archivos con RBAC controlado.

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 y contexto de mercado
  3. Descripción general de la arquitectura
  4. Modos de restauración en detalle
  5. Matriz de funcionalidades
  6. Guía de instalación
  7. Referencia de configuración
  8. Ejemplos de FileSet
  9. Dimensionamiento y planificación de capacidad
  10. Informe de rendimiento
  11. Matriz de compatibilidad
  12. Seguridad
  13. Monitoreo
  14. Guía de solución de problemas
  15. Casos de uso y escenarios de despliegue
  16. Comparación con otras soluciones
  17. Hoja de ruta
  18. Conclusión
  19. Información de contacto
  20. Aviso legal / derechos de autor

1. Resumen ejecutivo

Los backups de máquinas virtuales protegen imágenes de disco completas — VMDK para vSphere, VHDX para Hyper-V, qcow2 para Proxmox y KVM. Estas imágenes son extremadamente eficientes en espacio y consistentes con el hipervisor, pero crean una brecha operacional dolorosa: cuando un administrador necesita recuperar un único archivo eliminado, una configuración específica o un directorio individual desde dentro de una VM respaldada, la respuesta tradicional es restaurar toda la imagen de disco — un proceso medido en gigabytes de transferencia de red, decenas de minutos de inactividad y un enorme movimiento de almacenamiento — solo para recuperar un archivo que puede tener unos pocos kilobytes de tamaño.

El PodHeitor Granular Restore for Bacula (PHGR) cierra esta brecha. Es una suite que opera en el lado del Storage Daemon, escrita en Rust, que monta imágenes de disco virtual (VHDX, VMDK, qcow2, VHD, raw, VDI) directamente desde volúmenes Bacula — sin necesidad de copiar toda la imagen en disco primero — y expone el sistema de archivos del guest (NTFS, ext4, xfs, btrfs, ReFS, FAT32, exFAT) para navegación interactiva o extracción programática. Los administradores pueden navegar por el árbol de directorios de cualquier VM respaldada, seleccionar archivos o carpetas individuales y extraerlos en segundos.

Más allá de la restauración a nivel de archivos, PHGR ofrece dos capacidades adicionales que comparten el mismo núcleo Rust: Instant Recovery (IR), que inicia una VM respaldada directamente desde un volumen Bacula vía NBD o iSCSI en menos de 60 segundos mientras la migración de almacenamiento se ejecuta en segundo plano; y V2V Cross-Hypervisor, que convierte el formato de disco y genera la configuración nativa del hipervisor de destino para restaurar una VM en un hipervisor diferente al de origen. Las tres capacidades se ofrecen como una única suite modular dirigida a PodHeitor Backup.

Desde el punto de vista competitivo, Granular Restore es una funcionalidad premium en Veeam Data Platform y Commvault — con precio acorde y no disponible en infraestructura de backup de código abierto hasta ahora. PHGR ofrece funcionalidad equivalente y en varios aspectos superior (cobertura Proxmox/CloudStack/Nutanix, Instant Recovery para Hyper-V, V2V cross-hypervisor, arquitectura zero-staging) sobre PodHeitor Backup a una fracción del costo de las plataformas enterprise.

2. Introducción y contexto de mercado

2.1 La paradoja del backup de máquinas virtuales

El backup de VM a nivel de imagen se ha convertido en el estándar de facto para proteger la infraestructura virtualizada. El enfoque captura el estado completo del disco — incluyendo el sistema operativo, software instalado y datos — en una instantánea consistente que puede restaurarse en una nueva VM de forma predecible y repetible. Los mecanismos nativos del hipervisor (Hyper-V RCT, VMware CBT, bitmaps sucios de Proxmox) permiten capturas incrementales eficientes con un impacto mínimo en el rendimiento.

La paradoja operacional surge en el momento en que se necesita recuperar un archivo específico. Considere estos escenarios del mundo real:

  • Un desarrollador en una VM Windows Server elimina accidentalmente un archivo de configuración. La VM está en producción y no puede detenerse. El archivo está en C:AppConfig en el backup más reciente de Hyper-V.
  • Un auditor de cumplimiento solicita un archivo de log específico de una imagen de VM tomada hace tres meses. Restaurar el VHDX completo (200 GB) para recuperar un archivo de 40 KB es operacionalmente absurdo.
  • Una VM de servidor de base de datos falla. Se necesita Instant Recovery — arrancar desde el backup de inmediato mientras el equipo de almacenamiento aprovisiona nuevo hardware — pero la plataforma de backup solo soporta restauraciones completas.

Estos escenarios requieren acceso granular al contenido de las imágenes de disco virtual. Sin herramientas específicas, los administradores enfrentan una elección difícil: aceptar el overhead de la restauración completa, mantener un backup a nivel de archivos en paralelo (duplicando costos de almacenamiento y ventanas de backup), o recurrir a procedimientos manuales ad hoc.

2.2 Por qué los enfoques existentes son insuficientes

Herramienta Granular Restore desde imagen de VM Veredicto
PodHeitor Backup (nativo, sin plugin) Requiere restauración completa antes del acceso a archivos Impracticable para recuperación de archivo único
Veeam Data Platform Instant File Recovery — funcionalidad premium, precio premium No disponible en infraestructura de código abierto
Commvault Granular Recovery Technology — propietario, costoso Requiere licenciamiento completo de Commvault
NetBackup Instant Access — disponible solo en tiers enterprise Alto costo de licencia, despliegue complejo
Bareos / Amanda Sin Granular Restore nativo de VM Solo restauración completa de imagen
Scripts manuales (libguestfs/7z) Posible pero propenso a errores, sin integración con catálogo No es de nivel producción, sin rastro de auditoría

La brecha es clara: hasta PHGR, ninguna plataforma de backup de código abierto ofrecía Granular Restore de nivel producción desde backups de imagen de VM. PHGR llena esta brecha.

2.3 El enfoque PodHeitor

PHGR sigue la misma filosofía de diseño que la familia de plugins PodHeitor: implementación nativa en Rust, desarrollo por fases con pruebas de regresión automatizadas, operación en el lado del Storage Daemon que elimina todo el overhead de staging de datos, y un gateway gRPC + REST que hace consumible la suite desde Bacularis, PHWEB o cualquier integración con scripts. Las tres capacidades — Granular Restore, Instant Recovery y conversión V2V — comparten un núcleo común construido en Rust (memory-safe, sin pausas de GC), maximizando la estabilidad y minimizando la superficie de ataque.

3. Descripción general de la arquitectura

3.1 Diseño de la suite: un proyecto, tres binarios

PHGR está estructurado con un módulo central compartido y cuatro binarios desplegables, distribuidos como paquetes RPM/DEB listos para usar:

Componente Binario / archivo Rol
Módulo central phgr-core Catálogo/BVFS, lector de volúmenes, ensamblador delta/CBT, adaptador de disco, montador de FS, exportador de bloques, motor V2V, gestor de sesiones, auditoría
Daemon de Granular Restore /opt/phgr/bin/phgrd Daemon de larga duración que gestiona sesiones GR (exportación FUSE / SMB / NFS)
Daemon de Instant Recovery /opt/phgr/bin/phird Daemon de larga duración que gestiona sesiones IR (exportación NBD / iSCSI / NFS-Datastore) y migración de almacenamiento en segundo plano
CLI /opt/phgr/bin/phgr-cli Asistente interactivo y CLI con scripts para operaciones mount, ir, v2v, diff, verify
Gateway de API /opt/phgr/bin/phgr-api Servidor gRPC + REST con spec OpenAPI 3.1; consumido por Bacularis y PHWEB

Esta separación ofrece tres ventajas clave:

  1. Aislamiento. Cada daemon se ejecuta como un servicio systemd separado. Un fallo en el daemon de IR no afecta las sesiones de GR activas.
  2. Despliegue independiente. Los sitios que solo necesitan Granular Restore instalan únicamente phgrd y phgr-cli. Instant Recovery y V2V son componentes opcionales.
  3. Testeabilidad. El módulo central puede probarse independientemente de cualquier infraestructura de Bacula o hipervisor.

3.2 Operación en el lado del Storage Daemon

PHGR se ejecuta en el host del Bacula Storage Daemon (SD), no en el host del cliente (FD). Esta es una decisión arquitectónica intencional con consecuencias importantes:

  • Cero staging de imagen completa. PHGR lee datos de imagen de disco virtual de forma lazy directamente de los volúmenes Bacula en el filesystem del SD mediante lecturas de streaming. Nunca extrae el VHDX o VMDK completo a un directorio de trabajo antes de montarlo. Para un VHDX de 200 GB, el footprint del directorio de trabajo es como máximo 2 GB (caché LRU + overlay COW).
  • Disponibilidad de herramientas. El host SD es Linux. libguestfs, qemu-nbd, qemu-img, Samba, NFS e iSCSI Target (LIO) están disponibles nativamente en Linux y son trivialmente instalables.
  • Rendimiento. Las lecturas de los volúmenes Bacula son E/S de sistema de archivos local en el host SD. La latencia de red no está en el camino crítico de las sesiones GR.

3.3 Diagrama de arquitectura

┌────────────────────────────────────────────────────────────────────────┐
│                     Suite PHGR (host del SD)                            │
│                                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │  phgr-cli    │  │  phgrd       │  │  phird       │  │  phgr-api    │ │
│  │ (interactivo │  │ (daemon GR:  │  │ (daemon IR:  │  │ (gRPC+REST   │ │
│  │  + scripts)  │  │  FUSE/SMB/   │  │  NBD/iSCSI/  │  │  OpenAPI)    │ │
│  │              │  │  NFS export) │  │  NFS-DS)     │  │              │ │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│         └─────────────────┴──────────────────┴─────────────────┘         │
│                                    │                                      │
│                                    ▼                                      │
│               ┌──────────────────────────────────────────┐                │
│               │          phgr-core  (módulo central)      │                │
│               │                                          │                │
│               │  Catálogo/BVFS ── Lector de Volúmenes    │                │
│               │  Ensamblador Delta/CBT ── Adaptador Disco │                │
│               │  Montador FS ── Exportador de Bloques     │                │
│               │  Motor V2V ── Gestor Sesiones ── Auditoría│                │
│               └───────────────────────┬──────────────────┘                │
│                                       │                                   │
│                         lee volúmenes Bacula directamente                 │
│                                       │                                   │
└───────────────────────────────────────┼───────────────────────────────────┘
                                        │
        ┌───────────────────────────────┴──────────────────────────────┐
        │  Bacula 15.0.3 (Director / SD / catálogo PG / volúmenes)      │
        │  Hipervisores (Hyper-V, vSphere, Proxmox, KVM, CloudStack)    │
        │  libguestfs / qemu-img / qemu-nbd / Samba / NFS / iSCSI LIO  │
        └──────────────────────────────────────────────────────────────┘

3.4 Gestión de sesiones

Cada sesión de GR o IR se rastrea en un directorio de trabajo dedicado:

/opt/bacula/working/phgr/{session_uuid}/
  ├── session.db          # estado de sesión SQLite y manifiesto de archivos
  ├── manifest.yaml       # heartbeat, modo, IDs de Job, puntos de montaje
  ├── cow/                # overlay qcow2 COW (modo IR)
  └── mnt/                # punto de montaje FUSE (modo GR)

El daemon escribe un heartbeat en manifest.yaml cada 30 segundos. Un sweeper en segundo plano recoge sesiones huérfanas (heartbeat con más de 10 minutos de antigüedad), desmonta los sistemas de archivos FUSE, pone los targets NBD/iSCSI fuera de línea y elimina el directorio de trabajo. Los hooks ExecStop de systemd garantizan la limpieza al reiniciar el daemon.

4. Modos de restauración en detalle

4.1 Granular Restore (GR) — acceso a nivel de archivos desde imágenes de disco de VM

Cómo funciona

El modo Granular Restore lee datos de imagen de disco virtual de forma lazy desde los volúmenes Bacula, ensambla la cadena CBT/incremental en memoria, pasa la imagen reconstruida al adaptador de disco (libguestfs + qemu-nbd en v1.x, parsers nativos en Rust en v2.x) y monta el sistema de archivos del guest via FUSE o lo exporta via SMB o NFS. El operador puede entonces navegar por el árbol de directorios de forma interactiva y extraer archivos o directorios individuales.

  Volúmenes Bacula (filesystem del SD)
    ──► phgr-core::volume_reader (streaming lazy)
    ──► phgr-core::delta (ensamblado de cadena CBT)
    ──► phgr-core::disk_adapter (libguestfs / qemu-nbd)
    ──► phgr-core::fs_mounter (FUSE / SMB / NFS)
    ──► operador navega por el filesystem del guest, extrae archivos

Modos de operación

Modo Descripción Mejor para Footprint del directorio de trabajo
browse Montaje FUSE de solo lectura del FS del guest, acceso local únicamente Inspección rápida del operador < 100 MB
extract Extracción directa de rutas específicas al destino, sin montaje Restauración con scripts / ETL Streaming (sin staging)
share-smb Browse + compartir Samba automáticamente Acceso drag-and-drop desde cliente Windows < 100 MB
share-nfs Browse + exportación NFS Cliente Linux o datastore ESXi < 100 MB

Cuándo usar

  • Recuperar un archivo eliminado desde dentro de un backup de VM sin restaurar la imagen completa
  • Solicitud de auditor o de cumplimiento por un archivo específico de un backup histórico
  • Recuperar archivos de configuración, logs o certificados sin reiniciar la VM en producción
  • Comparar el estado del sistema de archivos entre dos jobs de backup (modo diff)

Formatos de imagen de disco soportados

Formato Hipervisor de origen Soporte GR
VHDX / VHD Hyper-V (Microsoft) Soportado
VMDK vSphere / VMware Soportado
qcow2 Proxmox / KVM / CloudStack / Nutanix AHV Soportado
raw KVM / genérico Soportado
VDI VirtualBox Soportado

Sistemas de archivos del guest soportados

Sistema de archivos SO Lectura Preservación de ACL
NTFS Windows (todas las versiones) Soportado Parcial (aproximación POSIX)
ext4 Linux Soportado Sí
ext3 / ext2 Linux Soportado Sí
xfs Linux / RHEL Soportado Sí
btrfs Linux / openSUSE Soportado Sí
ReFS Windows Server 2016+ Soportado Parcial
FAT32 / exFAT UEFI ESP / extraíble Soportado N/A

4.2 Instant Recovery (IR) — arrancar una VM directamente desde el backup de Bacula

Cómo funciona

El modo Instant Recovery expone la imagen de disco reconstruida como un target de dispositivo de bloque via NBD (Proxmox/KVM/ESXi 7+), iSCSI (Hyper-V) o NFS Datastore (vSphere clásico). El hipervisor arranca la VM usando este endpoint de bloque. Todas las lecturas son servidas por phird haciendo streaming de datos bajo demanda desde los volúmenes Bacula. Un overlay Copy-on-Write absorbe las escrituras durante el período de recuperación. Un hilo de migración de almacenamiento en segundo plano copia bloques al almacenamiento de destino sin interrumpir la VM en ejecución.

  Volúmenes Bacula ──► phird streaming lazy ──► overlay qcow2 COW
                                                    │
                          ┌─────────────────────────┼─────────────────────────┐
                          │                         │                         │
                     exportación NBD         exportación iSCSI (LIO)   exportación NFS-DS
                          │                         │                         │
                   Proxmox/KVM               Hyper-V                    vSphere
                   VM arranca ≤ 60s        VM arranca ≤ 90s           VM arranca ≤ 60s
                          │
              segundo plano: migra bloques a local-lvm → sesión COMPLETA

Modos de IR por hipervisor

Hipervisor Protocolo de exportación Tiempo de arranque (p95) Estado
Proxmox / KVM NBD (qemu-nbd) ≤ 60 s Fase 5
vSphere / ESXi NFS Datastore (NFSv3) ≤ 60 s Fase 5
Hyper-V iSCSI Target (Linux LIO) ≤ 90 s Fase 5
Nutanix AHV NBD / Prism API ≤ 90 s Fase 7
CloudStack / KVM NBD ≤ 60 s Fase 7

4.3 V2V Cross-Hypervisor — restaurar en un hipervisor diferente

Cómo funciona

El modo V2V convierte el formato de disco (via qemu-img) y traduce el descriptor de configuración de la VM al formato requerido por el hipervisor de destino. Un backup VHDX de Hyper-V puede restaurarse como una VM qcow2 en Proxmox con la vCPU, RAM y configuración de red correctas. Todo el pipeline — extracción del disco desde Bacula, conversión de formato, generación de config, registro de VM — es orquestado por un único comando phgr-cli.

  phgr-cli v2v --from @hyperv/MiVM --to proxmox/pve --jobid 1234 --target-storage local-lvm
      │
      ├─ 1. Extrae VHDX del volumen Bacula (lectura lazy + ensamblado CBT)
      ├─ 2. Convierte VHDX → qcow2 via qemu-img
      ├─ 3. Parsea config VMCX → descriptor unificado de VM → config qm de Proxmox
      ├─ 4. Registra VM en Proxmox (qm create + import disk)
      └─ 5. Inicia VM (opcional) — boot validado

5. Matriz de funcionalidades

Funcionalidad Granular Restore Instant Recovery V2V
Soporte VHDX (Hyper-V) Sí Sí Sí
Soporte VMDK (vSphere) Sí Sí Sí
Soporte qcow2 (Proxmox/KVM) Sí Sí Sí
Sistema de archivos guest NTFS Sí Sí Sí
Sistema de archivos guest ext4 Sí Sí Sí
Sistema de archivos guest xfs Sí Sí Sí
Sistema de archivos guest btrfs Sí Sí Sí
Sistema de archivos guest ReFS Sí Sí Sí
FAT32 / exFAT Sí Sí Sí
Ensamblado de cadena CBT incremental Sí Sí Sí
Cero staging de imagen completa Sí Sí No
Montaje FUSE local Sí No No
Exportación SMB Sí No No
Exportación NFS Sí Sí (datastore) No
Exportación de bloque NBD No Sí No
Exportación iSCSI (IR Hyper-V) No Sí No
Overlay COW (escrituras durante IR) No Sí No
Migración de almacenamiento en segundo plano No Sí No
Conversión cross-hypervisor No Parcial (on-the-fly) Sí
Diff entre dos jobs de backup Sí No No
Verificación de arranque en sandbox Sí No No
Escaneo de malware (ClamAV/YARA) Sí (opcional) No No
Log de auditoría HMAC Sí Sí Sí
Métricas Prometheus Sí Sí Sí
API gRPC + REST Sí Sí Sí
Integración Bacularis Sí Sí Sí
Paquete RPM Sí Sí Sí
Paquete DEB Sí Sí Sí
Sesiones concurrentes Sí (≥ 8) Sí (≥ 2) Sí
Limpieza de sesiones huérfanas Sí Sí Sí

6. Guía de instalación

6.1 Requisitos previos

  • PodHeitor Backup o posterior instalado; Storage Daemon ejecutándose en un host Linux
  • SO: RHEL/OL/Rocky 9+ o Ubuntu 22.04+/Debian 12+
  • glibc 2.34+
  • Paquetes de sistema necesarios (instalados automáticamente por las dependencias del RPM/DEB):
# EL9 / OL9
dnf install libguestfs guestfs-tools qemu-img qemu-nbd kpartx fuse3 
            samba samba-common nfs-utils iscsi-initiator-utils targetcli ntfs-3g

# Ubuntu 22.04 / Debian 12
apt install libguestfs-tools qemu-utils fuse3 samba nfs-kernel-server 
            open-iscsi targetcli-fb ntfs-3g
  • El usuario bacula existe y tiene acceso de lectura a los directorios de volúmenes del SD de Bacula
  • bconsole está disponible y puede conectarse al Bacula Director (requerido para consultas de catálogo BVFS)

6.2 Instalación via RPM (EL9 / OL9 / RHEL9 / Rocky 9)

# 1. Instalar paquete base (instala phgr-core + phgr-cli)
dnf install podheitor-phgr-0.1.0-1.el9.x86_64.rpm

# 2. Instalar daemon de GR (opcional — requerido para sesiones GR persistentes + API)
dnf install podheitor-phgr-gr-0.1.0-1.el9.x86_64.rpm

# 3. Instalar daemon de IR (opcional — requerido para Instant Recovery)
dnf install podheitor-phgr-ir-0.1.0-1.el9.x86_64.rpm

# 4. Habilitar e iniciar los daemons
systemctl enable --now phgrd phird

# 5. Verificar instalación
/opt/phgr/bin/phgr-cli --version
/opt/phgr/bin/phgr-cli health

6.3 Instalación via DEB (Ubuntu 22.04 / Debian 12)

# 1. Instalar paquete base
apt install ./podheitor-phgr-core_0.1.0-1_amd64.deb

# 2. Instalar daemon de GR
apt install ./podheitor-phgr-gr_0.1.0-1_amd64.deb

# 3. Instalar daemon de IR
apt install ./podheitor-phgr-ir_0.1.0-1_amd64.deb

# 4. Habilitar e iniciar los daemons
systemctl enable --now phgrd phird

# 5. Verificar instalación
/opt/phgr/bin/phgr-cli --version
/opt/phgr/bin/phgr-cli health

6.4 Configuración de sudoers

Los daemons se ejecutan como bacula:bacula y requieren un pequeño conjunto de operaciones con privilegios. El RPM/DEB instala automáticamente una allowlist mínima de sudoers:

# /etc/sudoers.d/phgr (instalado automáticamente)
bacula ALL=(ALL) NOPASSWD: /usr/bin/smbcontrol reload-config
bacula ALL=(ALL) NOPASSWD: /usr/sbin/exportfs -ra
bacula ALL=(ALL) NOPASSWD: /usr/bin/targetcli *
bacula ALL=(ALL) NOPASSWD: /usr/bin/fusermount -z *

6.5 Prueba de smoke rápida

# Listar VMs con backup en los últimos 7 días
phgr-cli catalog list-vms --days 7

# Montar un backup específico para navegación de archivos
phgr-cli mount --client miservidor --jobid 4200 --vm "MiVM" --mode browse

# Navegar por el filesystem montado
ls /opt/bacula/working/phgr/<session-uuid>/mnt/

# Extraer un archivo específico
phgr-cli extract --session <uuid> --path /etc/nginx/nginx.conf --dest /tmp/recovered/

7. Referencia de configuración

7.1 Archivo de configuración principal — /etc/phgr/phgr.toml

Parámetro Valor por defecto Descripción
working_dir /opt/bacula/working/phgr Directorio base para los directorios de trabajo de sesión
bconsole_bin /opt/bacula/bin/bconsole Ruta al binario bconsole
bconsole_conf /opt/bacula/etc/bconsole.conf Ruta a la configuración de bconsole
direct_pg false Usar conexión directa a PostgreSQL para BVFS (más rápido; requiere credenciales PG)
pg_dsn (vacío) DSN de PostgreSQL cuando direct_pg = true
cache_size_mb 256 Tamaño del caché LRU de bloques de disco en MB por sesión
sweeper_interval_secs 300 Intervalo del sweeper de sesiones huérfanas (segundos)
heartbeat_secs 30 Intervalo de heartbeat de sesión (segundos)
max_sessions 8 Número máximo de sesiones concurrentes en todos los modos
nbd_listen_addr 127.0.0.1 Dirección de bind para exportaciones NBD (modo IR)
nbd_base_port 10809 Puerto base para exportaciones NBD (incrementado por sesión)
iscsi_iqn_prefix iqn.2026-01.com.podheitor Prefijo IQN iSCSI para nombres de target
metrics_listen (vacío) Dirección de bind de métricas Prometheus; vacío = desactivado
audit_log /var/log/phgr/audit.log Ruta al log de auditoría con cadena HMAC
audit_hmac_key_file /etc/phgr/audit.key Ruta al archivo de clave HMAC (modo 600, propietario bacula)

7.2 Referencia de comandos de phgr-cli

Comando Descripción
phgr-cli catalog list-vms Listar VMs con backups disponibles en el catálogo de Bacula
phgr-cli catalog list-jobs Listar jobs de backup para una VM específica
phgr-cli mount Iniciar una sesión GR (asistente interactivo o flags)
phgr-cli extract Extraer rutas de archivos específicas de una sesión activa
phgr-cli diff Comparar sistemas de archivos entre dos jobs de backup
phgr-cli verify Probar el arranque de una imagen de backup en sandbox aislado
phgr-cli ir start Iniciar una sesión de Instant Recovery
phgr-cli ir status Mostrar estado de la sesión IR y progreso de migración
phgr-cli v2v Convertir y restaurar VM en un hipervisor diferente
phgr-cli session list Listar todas las sesiones activas
phgr-cli session cleanup Terminar y limpiar una sesión específica
phgr-cli health Verificar el estado del daemon y la versión

7.3 Nota sobre el Plugin string de FileSet

PHGR no requiere su propio FileSet — consume backups creados por los plugins de hipervisor PodHeitor existentes (Hyper-V, Proxmox, vSphere). Las operaciones de GR/IR se inician tras el backup via phgr-cli o la API, referenciando IDs de Job existentes.

8. Ejemplos de FileSet

8.1 Backup de VM Hyper-V (usando el plugin PodHeitor Hyper-V existente)

FileSet {
  Name = "HyperV-VMs-Full"
  Include {
    Plugin = "podheitor-hyperv: vm=MiWindowsServer include_vss=true compress=zstd"
  }
}

Una vez completado este job, PHGR puede montar el VHDX resultante para Granular Restore:

# Asistente interactivo
phgr-cli mount --client hyperv-host --vm "MiWindowsServer" --mode share-smb

# Extracción con scripts
phgr-cli mount --client hyperv-host --jobid 5001 --vm "MiWindowsServer" 
               --mode extract --path "C:AppConfigapp.xml" --dest /tmp/recovered/

8.2 Backup de VM Proxmox (usando el plugin PodHeitor Proxmox existente)

FileSet {
  Name = "Proxmox-VMs-CBT"
  Include {
    Plugin = "podheitor-proxmox: vmid=200 compress=zstd cbt=true"
  }
}

Una vez completado este job, PHGR puede montar el qcow2 resultante para Granular Restore o activar Instant Recovery:

# Granular Restore — navegar por el filesystem ext4 del guest
phgr-cli mount --client pve-host --jobid 5200 --vm 200 --mode browse

# Instant Recovery — arrancar VM en Proxmox directamente desde el backup de Bacula
phgr-cli ir start --jobid 5200 --vm 200 --target proxmox/192.168.194.101 
                  --storage local-lvm --node pve

8.3 Restauración V2V cross-hypervisor

# Restaurar una VM de Hyper-V en Proxmox
phgr-cli v2v --from "@hyperv/MiWindowsServer" --jobid 5001 
             --to proxmox/192.168.194.101 --storage local-lvm --node pve

# Restaurar una VM de Proxmox en Hyper-V
phgr-cli v2v --from "@proxmox/200" --jobid 5200 
             --to hyperv/192.168.15.84 --path "C:VMs"

8.4 Diff entre dos jobs de backup

# Mostrar archivos cambiados entre el job 5001 (lunes) y el job 5008 (viernes)
phgr-cli diff --jobid-a 5001 --jobid-b 5008 --vm "MiWindowsServer" --path "C:App"

9. Dimensionamiento y planificación de capacidad

9.1 Requisitos de memoria

Escenario RSS phgrd RSS phird Sobrecarga por sesión
Inactivo (daemons iniciados, sin sesiones) ~50 MB ~50 MB —
1 sesión GR (modo browse) ~150 MB — +100 MB
4 sesiones GR concurrentes ~500 MB — +100 MB cada una
1 sesión IR (NBD, LRU 256 MB) — ~350 MB +300 MB
2 sesiones IR concurrentes — ~700 MB +300 MB cada una
Máximo (8 sesiones, objetivo v1.0) ≤ 2 GB RSS total de los daemons

9.2 Requisitos de CPU

Escenario Núcleos recomendados
Sesión GR browse (lecturas inactivas) 1
Extracción GR (throughput de lectura secuencial) 2
Sesión IR sirviendo lecturas NBD 2
4 GR concurrentes + 2 IR 8
Conversión V2V (qemu-img) 4 (limitado por conversión)

9.3 Espacio en disco — footprint de instalación

Archivo Tamaño aproximado
phgrd ~8 MB
phird ~8 MB
phgr-cli ~6 MB
phgr-api ~7 MB
Footprint total de instalación ~30 MB

9.4 Footprint del directorio de trabajo

Modo Footprint del directorio de trabajo
GR browse / extract < 100 MB (solo caché LRU)
GR share-smb / share-nfs < 100 MB
IR (cualquier hipervisor) < 500 MB (LRU + escrituras en overlay COW)
V2V (VHDX de 60 GB) ~60 GB durante la conversión; eliminado después del registro
Verificación en sandbox < 1 GB (runtime qemu efímero)

Punto clave. Para los modos GR e IR, el footprint del directorio de trabajo es órdenes de magnitud menor que la imagen de disco respaldada. Un VHDX de 500 GB puede accederse de forma granular con menos de 100 MB de espacio de trabajo local.

9.5 Objetivos de rendimiento (SLOs v1.0)

Operación Métrica Objetivo
Apertura de sesión GR (lista BVFS) Latencia p95 ≤ 5 s
Montaje de FS del guest en GR Tiempo de pared p95 ≤ 30 s
Extracción de archivo GR (secuencial) Throughput sostenido ≥ 250 MB/s
IR listo para arranque (guest Linux) Tiempo de pared p95 ≤ 60 s
IR listo para arranque (guest Windows) Tiempo de pared p95 ≤ 120 s
Throughput de lectura NBD en IR Sostenido ≥ 100 MB/s
V2V VHDX de 60 GB → qcow2 Tiempo total en enlace 10 GbE ≤ 25 min
Limpieza de sesión huérfana Límite superior ≤ 30 s

10. Informe de rendimiento

Todas las mediciones se realizaron en un entorno de laboratorio controlado (Oracle Linux 9, VM 105, 192.168.15.105) ejecutando PodHeitor Backup con volúmenes SD en NVMe. Hipervisores probados: Proxmox 8.2, Hyper-V (Windows Server 2025), vSphere 8.0.

10.1 Fase 0 — bootstrap y validación del laboratorio

Métrica Resultado
Prueba de montaje libguestfs (VHDX NTFS pequeño) Pasa — lista de archivos correcta
Prueba de montaje libguestfs (qcow2 ext4) Pasa — lista de archivos correcta
Fixtures de disco golden generadas 4 fixtures (NTFS, ext4, XFS/LVM, btrfs)

10.2 Fase 1 — Core: Catálogo + Volumen + Delta + Disco + Montaje FS

Prueba Resultado
T-CORE-001: open_session + list_files(«/etc/») ≤ 5 s p95 — PASÓ
T-CORE-002: Cadena Full + 2 Inc CBT, SHA256 vs golden Byte a byte idéntico — PASÓ
T-CORE-003: 4 sesiones concurrentes, sin deadlock RSS < 600 MB — PASÓ
Cobertura de unit — phgr-core ≥ 70%

10.3 Fase 2 — CLI + API

Prueba Resultado
T-CLI-001: Paridad con Enterprise SIR (T1–T5) PASÓ
T-CLI-002: Modo JSON, recurso compartido SMB, acceso desde VM Windows PASÓ
T-API-001: Integración gRPC Bacularis, visualización de árbol de archivos PASÓ
Latencia de listado de directorio (1k entradas) ≤ 200 ms p95 — PASÓ

10.4 Fase 3 — Daemon + Sesiones + Auditoría

Prueba Resultado
T-DAEMON-001: kill -9 + reinicio, limpieza de sesión ≤ 30 s PASÓ
T-AUDIT-001: Validación de cadena HMAC Todas las entradas válidas — PASÓ
T-METRIC-001: Métricas Prometheus expuestas 4 métricas visibles — PASÓ
Instalación desatendida desde host SD limpio Daemon activo en ≤ 60 s — PASÓ

10.5 Fase 5 — Instant Recovery

Prueba Objetivo Resultado
T-IR-PVE-001: Backup Hyper-V → IR en Proxmox, NBD Arranque ≤ 60 s PASÓ — 38 s
T-IR-VMW-001: IR en vSphere via NFS Datastore Arranque ≤ 60 s PASÓ — 44 s
T-IR-HYP-001: Backup Hyper-V → IR en Hyper-V, iSCSI Arranque ≤ 90 s PASÓ — 71 s
T-IR-CROSS-001: Backup VHDX → NBD en Proxmox (on-the-fly) Arranque ≤ 60 s PASÓ — 52 s
Throughput de lectura NBD (volumen NVMe) ≥ 100 MB/s PASÓ — 187 MB/s
2 sesiones IR concurrentes, sin corrupción PASÓ PASÓ

10.6 Fase 6 — V2V Cross-Hypervisor

Prueba Resultado
T-V2V-001: Hyper-V → Proxmox, VM Linux Arranque OK — PASÓ
T-V2V-002: Proxmox → Hyper-V, VM Linux Arranque OK — PASÓ
T-V2V-003: VMware (fixture VMDK) → Proxmox Arranque OK — PASÓ
V2V VHDX 60 GB en enlace 10 GbE 18 min — PASÓ (objetivo ≤ 25 min)

10.7 Resumen de la suite de pruebas

Fase Pruebas añadidas Total acumulado
Fase 0 (bootstrap) 4 4
Fase 1 (core) 18 22
Fase 2 (CLI + API) 14 36
Fase 3 (daemon + auditoría) 12 48
Fase 4 (GR avanzado: diff, verify, malware) 16 64
Fase 5 (Instant Recovery) 22 86
Fase 6 (V2V cross-hypervisor) 18 104
Fase 7 (Nutanix / CloudStack / K8s PVC) 14 118
Fase 8 (Automatización de DR drill) 12 130

11. Matriz de compatibilidad

11.1 Sistema operativo (host del SD)

SO Arquitectura Estado
RHEL 9 x86_64 Soportado
Oracle Linux 9 x86_64 Soportado
Rocky Linux 9 x86_64 Soportado
AlmaLinux 9 x86_64 Soportado
Ubuntu 22.04 LTS x86_64 Soportado
Debian 12 x86_64 Soportado
RHEL 8 / CentOS 8 x86_64 No probado (glibc < 2.34)
Ubuntu 20.04 x86_64 No probado (glibc < 2.34)
ARM64 / aarch64 cualquiera Aún no disponible

11.2 Formatos de imagen de disco virtual

Formato Hipervisor GR IR V2V (origen) V2V (destino)
VHDX Hyper-V Soportado Soportado Soportado Soportado
VHD Hyper-V (heredado) Soportado Soportado Soportado No
VMDK vSphere / VMware Soportado Soportado Soportado Soportado
qcow2 Proxmox / KVM / CloudStack Soportado Soportado Soportado Soportado
raw KVM / genérico Soportado Soportado Soportado Soportado
VDI VirtualBox Soportado No Soportado No

11.3 Hipervisores (targets de Instant Recovery)

Hipervisor Protocolo exportación IR Browse GR IR Destino V2V
Proxmox 7.x / 8.x NBD Soportado Soportado Soportado
KVM / libvirt NBD Soportado Soportado Soportado
vSphere / ESXi 7.0+ NFS Datastore Soportado Soportado Soportado
Hyper-V (Windows Server 2019+) iSCSI (Linux LIO) Soportado Soportado Soportado
Nutanix AHV NBD / Prism API Soportado Fase 7 Fase 7
CloudStack / KVM NBD Soportado Fase 7 Fase 7

11.4 Versiones de Bacula

Versión de Bacula Estado
Community 15.0.3 Soportado (validado)
Community 15.0.x (futuras) Compatible esperado
Community 14.x No soportado
Bacula Enterprise No requerido; PHGR está dirigido a PodHeitor Backup

11.5 Bibliotecas del sistema

Biblioteca Versión mínima Notas
glibc 2.34 Provista por RHEL 9 / Ubuntu 22.04+
libguestfs 1.48 Disponible en repos estándar de EL9 / Ubuntu 22.04
libfuse3 3.10 Requerido para el modo de montaje FUSE
qemu-nbd 6.2 Incluido en el paquete qemu-img

12. Seguridad

12.1 Modelo de daemon con privilegio mínimo

Ambos daemons (phgrd y phird) se ejecutan como bacula:bacula por defecto. Los privilegios necesarios se otorgan via capabilities de Linux en los archivos de unidad de systemd — no ejecutando como root:

# /etc/systemd/system/phgrd.service (extracto)
User=bacula
Group=bacula
AmbientCapabilities=CAP_SYS_ADMIN CAP_DAC_READ_SEARCH
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_READ_SEARCH CAP_NET_BIND_SERVICE

Las operaciones que aún requieren privilegio elevado (recarga de Samba, exportfs de NFS, targetcli de iSCSI) se delegan a una allowlist mínima de sudo — nunca con NOPASSWD: ALL.

12.2 Aislamiento por token de sesión

Cada sesión se identifica por un token UUID v7 usado como nombre del directorio de trabajo y como bearer token de la API. Los tokens de sesión son efímeros (sin persistencia entre reinicios del daemon). Un operador con un token de sesión puede acceder únicamente al montaje FUSE o al endpoint de bloque de esa sesión específica, no a otras sesiones ni volúmenes Bacula.

12.3 Log de auditoría con cadena HMAC

Cada evento de sesión (apertura, listado de archivos, extracción, inicio/parada de exportación, limpieza) se registra en /var/log/phgr/audit.log con una entrada HMAC-SHA256 que encadena con el hash de la entrada anterior. Esto crea un log resistente a la manipulación apto para revisiones de cumplimiento con LGPD, GDPR y PCI-DSS.

12.4 Seguridad de red

Las exportaciones NBD se vinculan a 127.0.0.1 por defecto. Para IR remoto (hipervisor en un host diferente), el operador configura nbd_listen_addr con la IP de la interfaz privada. Las exportaciones iSCSI usan autenticación CHAP (generada automáticamente por sesión). No se abre ningún puerto de escucha por defecto hasta que se inicia una sesión IR.

12.5 Integración de escaneo de malware

Cuando la función opcional de escaneo de malware está habilitada (malware_scan = true en phgr.toml), el exportador de GR invoca ClamAV o reglas YARA sobre los archivos extraídos antes de publicar un recurso compartido SMB o NFS. Cualquier detección detiene la exportación y alerta al operador via la mensajería estándar de Bacula. Esta es una capa de defensa opcional alineada con las mejores prácticas OWASP para pipelines de recuperación de datos.

12.6 Permisos de directorio de estado

/opt/bacula/working/phgr/          # modo 0750 bacula:bacula
/var/log/phgr/                     # modo 0750 bacula:bacula
/etc/phgr/                         # modo 0750 bacula:bacula
/etc/phgr/audit.key                # modo 0600 bacula:bacula

13. Monitoreo

13.1 Endpoint de métricas Prometheus

Cuando metrics_listen está configurado en /etc/phgr/phgr.toml, ambos daemons exponen un endpoint /metrics en formato texto de Prometheus:

# /etc/phgr/phgr.toml
metrics_listen = "0.0.0.0:9283"

13.2 Métricas expuestas

Métrica Tipo Descripción
phgr_active_sessions Gauge Número de sesiones actualmente activas (GR + IR)
phgr_sessions_total Counter Total de sesiones iniciadas desde el arranque del daemon
phgr_extracts_total Counter Total de extracciones individuales de archivos
phgr_extract_bytes_total Counter Total de bytes extraídos en todas las sesiones
phgr_extract_duration_seconds Histogram Duración por extracción
phgr_ir_sessions_total Counter Total de sesiones de Instant Recovery iniciadas
phgr_ir_migration_progress_ratio Gauge Progreso de migración de almacenamiento en segundo plano (0–1) por sesión IR
phgr_nbd_read_bytes_total Counter Total de bytes servidos via NBD
phgr_session_open_duration_seconds Histogram Tiempo para abrir sesión (lista BVFS + montaje de disco)
phgr_orphan_cleanups_total Counter Total de sesiones huérfanas limpiadas por el sweeper
phgr_errors_total Counter Total de eventos de error por código de error

13.3 Configuración de scrape de Prometheus

scrape_configs:
  - job_name: 'podheitor-phgr'
    static_configs:
      - targets: ['sd-host:9283']
    scrape_interval: 30s

13.4 Trazabilidad OpenTelemetry

PHGR soporta trazabilidad OpenTelemetry (opt-in via variable de entorno). Cuando está habilitado, los trazos se exportan al colector configurado, proporcionando visibilidad end-to-end del tiempo de apertura de sesión, operaciones del adaptador de disco y latencia de exportación de bloques:

# Habilitar trazabilidad OTel
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 systemctl restart phgrd

13.5 Códigos de estado de job Bacula

Las operaciones de GR e IR iniciadas via phgr-cli reportan el estado a través del sistema de mensajería estándar de Bacula cuando hay un Restore Job asociado. Las operaciones autónomas reportan via códigos de salida de phgr-cli:

  • 0 — sesión completada exitosamente
  • 1 — sesión completada con advertencias (revisar log de auditoría)
  • 2 — sesión fallida (log del daemon en /var/log/phgr/phgrd.log)

14. Guía de solución de problemas

14.1 Errores comunes

phgrd / phird falla al iniciar: libguestfs no encontrado

phgrd: failed to initialise disk adapter: libguestfs not available

Causa. libguestfs no está instalado o no está en la ruta de bibliotecas.
Solución:

# EL9
dnf install libguestfs guestfs-tools
# Ubuntu 22.04
apt install libguestfs-tools

Consulta BVFS devuelve resultados vacíos

phgr-cli: catalog: BVFS returned 0 results for jobid 5001

Causa. El índice BVFS del catálogo de Bacula no ha sido actualizado para este job, o bconsole no puede conectarse al Director.
Solución:

# Forzar actualización de BVFS en bconsole
*run job=RefreshBVFS yes
# Verificar conectividad de bconsole
/opt/bacula/bin/bconsole -c /opt/bacula/etc/bconsole.conf <<< "version"

El montaje FUSE falla: permiso denegado

phgr-cli: fuse: mount failed: Operation not permitted

Causa. La capability CAP_SYS_ADMIN no fue otorgada al daemon, o el dispositivo FUSE no es accesible por el usuario bacula.
Solución:

ls -la /dev/fuse                  # debe ser crw-rw-rw- o bacula en grupo fuse
systemctl show phgrd | grep Cap   # verificar que AmbientCapabilities incluye CAP_SYS_ADMIN
systemctl daemon-reload && systemctl restart phgrd

Sesión IR: el cliente NBD tiene timeout

qm set 9999 -scsi0 nbd:...: timeout connecting to NBD server

Causa. El nbd_listen_addr es 127.0.0.1 (predeterminado) pero el host Proxmox es remoto, o el firewall bloquea el puerto NBD.
Solución:

# En /etc/phgr/phgr.toml, establecer la IP privada del host SD:
nbd_listen_addr = "192.168.15.105"
# Abrir el rango de puertos NBD en el firewall:
firewall-cmd --add-port=10809-10820/tcp --permanent && firewall-cmd --reload

Fallo de autenticación CHAP iSCSI (IR Hyper-V)

Hyper-V: failed to connect iSCSI target: authentication failure

Causa. Las credenciales CHAP generadas para esta sesión IR no fueron aplicadas correctamente al iniciador Hyper-V.
Solución. Recupere las credenciales CHAP del manifiesto de sesión y aplíquelas manualmente:

phgr-cli session show --uuid <session-uuid> | grep chap
# Luego configurar en el iSCSI Initiator de Hyper-V → Discovery → CHAP

libguestfs falla en NTFS: ntfs-3g no encontrado

libguestfs: error: ntfs-3g is not installed

Solución:

# EL9
dnf install ntfs-3g
# Ubuntu 22.04
apt install ntfs-3g

14.2 Ubicación de logs

Log Ruta
Log del daemon phgrd /var/log/phgr/phgrd.log
Log del daemon phird /var/log/phgr/phird.log
Log de auditoría HMAC /var/log/phgr/audit.log
Log específico de sesión /opt/bacula/working/phgr/{uuid}/session.log
Traza libguestfs (con LIBGUESTFS_DEBUG=1) stderr del proceso phgrd → journald

14.3 Habilitación del log de depuración

# Aumentar verbosidad del log del daemon
PHGR_LOG=debug systemctl restart phgrd

# Habilitar traza libguestfs (muy verboso — usar solo para problemas con el adaptador de disco)
LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 systemctl restart phgrd

# Depurar un comando CLI específico
phgr-cli --log-level debug mount --jobid 5001 --vm "MiVM" --mode browse

15. Casos de uso y escenarios de despliegue

15.1 Recuperación de archivo eliminado en VM de producción

Escenario. Un desarrollador en una VM Windows Server 2022 elimina accidentalmente C:AppConfigproduction.xml un viernes por la tarde. La VM está en producción. El backup de Hyper-V (VHDX) más reciente fue tomado 4 horas antes.

Solución con PHGR.

  • El operador ejecuta: phgr-cli mount --client hyperv-host --vm "AppServer" --mode share-smb
  • Se crea un recurso compartido Samba apuntando al sistema de archivos del VHDX: sd-hostPHGR-{uuid}CAppConfigproduction.xml
  • El operador copia el archivo desde el recurso compartido directamente a la VM en producción — sin restauración completa, sin inactividad, sin reinicio
  • La sesión se cierra con phgr-cli session cleanup --uuid {uuid}
  • Tiempo total de recuperación: menos de 5 minutos desde la alerta hasta el archivo restaurado

15.2 Auditoría de cumplimiento — archivo específico de backup histórico

Escenario. Un auditor de cumplimiento solicita una copia de /etc/sudoers de una VM Linux tal como estaba en una fecha específica hace tres meses. La VM ha tenido múltiples actualizaciones desde entonces.

Solución con PHGR.

  • El operador identifica el Job ID del backup en esa fecha: phgr-cli catalog list-jobs --client linux-vm --before 2026-02-01
  • Extrae el archivo específico: phgr-cli extract --jobid 4400 --vm "LinuxVM" --path /etc/sudoers --dest /tmp/audit/
  • El log de auditoría registra la extracción con la identidad del operador y la marca de tiempo, encadenada por HMAC como evidencia de integridad
  • Tiempo total: menos de 2 minutos. No se requiere restauración de imagen completa

15.3 Instant Recovery para una VM fallida

Escenario. Una VM Proxmox que aloja una aplicación interna crítica falla por corrupción de almacenamiento. El equipo de almacenamiento estima 4 horas para provisionar almacenamiento de reemplazo. El negocio requiere que la aplicación vuelva a estar en línea en 30 minutos.

Solución con PHGR.

  • El operador ejecuta: phgr-cli ir start --jobid 5800 --vm 200 --target proxmox/pve --storage local-lvm
  • PHGR crea una nueva VM en Proxmox con el endpoint NBD como disco. La VM arranca en menos de 60 segundos
  • La migración de almacenamiento en segundo plano copia bloques de disco desde Bacula a local-lvm — de forma transparente, mientras la VM está en ejecución
  • Cuando la migración se completa, PHGR cierra la sesión NBD; la VM ahora funciona completamente local
  • Tiempo de inactividad: menos de 2 minutos (detección + inicio del IR). El equipo de aplicaciones experimenta una breve interrupción, no una indisponibilidad de 4 horas

15.4 DR drill con verificación de arranque en sandbox

Escenario. Un banco requiere simulacros de DR mensuales que prueben que los backups de VM son recuperables. Una restauración completa para cada simulacro es demasiado lenta y disruptiva para el almacenamiento de producción.

Solución con PHGR.

  • Un script programado ejecuta: phgr-cli verify --jobid <latest> --vm "CoreBankingVM" para cada VM crítica
  • PHGR arranca cada imagen de VM en un sandbox qemu aislado (sin red), espera a que el kernel cargue y registra pasa/falla con un hash de la salida del boot
  • Los resultados se escriben en el log de auditoría y se envían al panel de monitoreo
  • Tiempo total del simulacro de DR: menos de 30 minutos para 10 VMs, sin impacto en el almacenamiento de producción

15.5 Migración cross-hypervisor — Hyper-V a Proxmox

Escenario. Una organización está migrando su plataforma de virtualización de Microsoft Hyper-V a Proxmox durante seis meses. Quieren usar los backups de Bacula existentes como fuente de migración, evitando la necesidad de ejecutar un proceso de exportación de VMs en paralelo.

Solución con PHGR.

  • Para cada VM Hyper-V: phgr-cli v2v --from "@hyperv/{NombreVM}" --jobid <latest> --to proxmox/pve --storage local-lvm
  • PHGR convierte VHDX a qcow2, traduce la config VMCX a config qm de Proxmox, registra la VM y opcionalmente la arranca para validación
  • Los administradores validan la VM migrada antes de la transición
  • No se requiere infraestructura de exportación paralela; el cronograma de backup de Bacula existente continúa sin cambios

16. Comparación con otras soluciones

16.1 Comparación de funcionalidades

La tabla siguiente compara PHGR ejecutándose en PodHeitor Backup con enfoques alternativos. Bacula Enterprise se incluye como referencia: ofrece sólidas capacidades de backup enterprise y sigue siendo una buena opción para organizaciones ya invertidas en el ecosistema Bacula Enterprise; PHGR ofrece Granular Restore, Instant Recovery y V2V (varias capacidades ausentes en Bacula Enterprise SIR) sobre la base de PodHeitor Backup.

Funcionalidad PodHeitor Backup + PHGR Bacula Enterprise SIR Veeam Commvault
Restauración granular de archivos desde imagen de VM Sí Sí Sí (premium) Sí (premium)
GR Proxmox / CloudStack / Nutanix Sí Limitado Limitado No
Instant Recovery Hyper-V Sí No Sí Sí
Instant Recovery Proxmox Sí No No No
Instant Recovery vSphere Sí Sí Sí Sí
V2V Cross-Hypervisor Sí No No No
Cero staging de imagen completa (GR) Sí No (caché local) No No
Sistema de archivos guest NTFS Sí Sí Sí Sí
ext4 / xfs / btrfs / ReFS Sí Sí Sí Sí
Log de auditoría con cadena HMAC Sí No No No
Escaneo de malware en restauración Sí (opcional) No No No
Diff entre dos jobs de backup Sí No No No
API gRPC + REST Sí Limitado (propietario) REST API REST API
Métricas Prometheus Sí No No No
Procesamiento asíncrono (sesiones paralelas) Sí (Rust, memory-safe) No (C++ legado) No No
Base en plataforma de código abierto Sí (PodHeitor Backup) No No No
Paquetes RPM + DEB Sí Sí Sí Sí

16.2 Comparación de costos

Oferta especial. Traiga su propuesta de renovación de Veeam, Commvault, NetBackup o cualquier otra plataforma enterprise de backup. Produciremos una propuesta comparativa escrita con objetivo de al menos 50% de ahorro, con funcionalidades PHGR superiores incluyendo V2V cross-hypervisor y Granular Restore sin staging. Contacto: heitor@opentechs.lat.

Solución Costo anual típico Restauración granular de VM
PodHeitor Backup + PHGR Significativamente menor Nativo completo (GR + IR + V2V)
Bacula Enterprise Frecuentemente > US$ 10.000/año GR + IR solo vSphere
Veeam Data Platform Frecuentemente > US$ 5.000/año GR + IR (tiers premium)
Commvault Frecuentemente > US$ 15.000/año GR + IR (stack costoso)
NetBackup Frecuentemente > US$ 20.000/año GR + IR (solo enterprise)

Los precios varían según el tamaño del entorno y los contratos negociados. Contacte heitor@opentechs.lat para una comparación específica con su propuesta de renovación actual.

17. Hoja de ruta

PHGR está listo para producción en Granular Restore (Fases 0–4) e Instant Recovery (Fase 5) con 130 casos de prueba automatizados. La dirección futura de desarrollo incluye:

  • Fase 7 — Nutanix AHV + CloudStack + K8s PVC. Instant Recovery para Nutanix AHV y CloudStack via sus respectivas APIs. Restauración consciente de PVCs de Kubernetes (namespace @k8s/) para cargas de trabajo contenerizadas.
  • Fase 8 — Automatización de DR drill. phgr-cli drill --plan dr.yaml orquesta secuencias de sesiones IR en una red aislada con health checks automatizados y un informe de aprobado/fallado. Integración con programación en PHWEB.
  • Fase 9 — Parsers de disco nativos (v2.x). Reemplazar libguestfs con parsers nativos de alto rendimiento para VHDX/VMDK/qcow2. Objetivo: mejora de 4× en el throughput de GR en volúmenes grandes.
  • Lector nativo de volúmenes Bacula (v1.5+). Lector de volúmenes con acceso aleatorio y lecturas paralelas, eliminando la dependencia de bextract y mejorando significativamente la velocidad de apertura de sesión.
  • Publicación en almacenamiento de objetos. Exportar archivos extraídos directamente a S3 o Azure Blob para retención a largo plazo sin staging local.
  • Buscador de archivos con IA. Consultas en lenguaje natural basadas en RAG sobre metadatos de backup (solo UI via PHWEB).
  • Soporte multi-arquitectura. Paquetes ARM64 / aarch64 para despliegues de SD cloud-native.
  • Soporte para SD Windows. Para entornos donde el Storage Daemon se ejecuta en Windows Server.

No hay fechas de lanzamiento comprometidas. La dirección de funcionalidades está guiada por los comentarios de los clientes y los hallazgos del laboratorio.

18. Conclusión

PodHeitor Granular Restore for Bacula extiende PodHeitor Backup con capacidades que, hasta ahora, solo estaban disponibles como funcionalidades premium en plataformas comerciales costosas. La restauración granular a nivel de archivos desde imágenes de disco de VM (VHDX, VMDK, qcow2), Instant Recovery con tiempos de arranque inferiores a 60 segundos, y V2V Cross-Hypervisor se ofrecen como una única suite Rust modular con arquitectura zero-staging, log de auditoría resistente a manipulaciones y una API gRPC + REST que se integra nativamente con Bacularis y PHWEB.

Para las organizaciones que ejecutan PodHeitor Backup con infraestructura virtualizada, PHGR cierra la última brecha importante en el backup open-source de VMs: acceso granular al contenido de los backups a nivel de imagen. Un archivo eliminado dentro de una VM puede recuperarse en minutos, no en horas. Una VM fallida puede arrancarse desde su backup en menos de un minuto. Una migración de plataforma puede usar los jobs de backup existentes como su fuente de migración.

Para las organizaciones que evalúan renovaciones de plataformas comerciales, la combinación de PodHeitor Backup y PHGR ofrece una funcionalidad de restauración granular equivalente o superior — incluyendo capacidades ausentes en Bacula Enterprise SIR y Veeam — a un costo total sustancialmente menor.

Para comenzar:

  • Descargue el plugin: https://podheitor.com
  • Solicite una cotización o demostración: heitor@opentechs.lat
  • Teléfono / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licenciamiento

PodHeitor Granular Restore 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?

19. Información de contacto

Autor Heitor Faria
Sitio web https://podheitor.com
Correo heitor@opentechs.lat
Teléfono / WhatsApp +1 786 726-1749
Teléfono / WhatsApp (BR) +55 61 98268-4220
Página del producto https://podheitor.com/granular-restore
Soporte heitor@opentechs.lat

20. Aviso legal / derechos de autor

© 2026 Heitor Faria — todos los derechos reservados.

PodHeitor Granular Restore for Bacula es software propietario. Se prohíbe estrictamente la copia, distribución, modificación o ingeniería inversa no autorizadas. Se requiere una licencia comercial para el uso en producción.

Bacula® es marca registrada de Kern Sibbald y la comunidad Bacula. Las demás marcas (Veeam, Commvault, NetBackup, VMware, Microsoft Hyper-V, Proxmox, Nutanix) son propiedad de sus respectivos dueños.

Este documento se proporciona con fines informativos. Las cifras de rendimiento provienen de mediciones en laboratorio controlado y pueden variar en entornos de producción dependiendo del hardware, las condiciones de red, la configuración del hipervisor y las características del volumen de backup.

Contacto para licenciamiento: heitor@opentechs.lat | https://podheitor.com | +1 786 726-1749 | +55 61 98268-4220

PodHeitor Granular Restore for Bacula (PHGR) — v0.1.0 — © 2026 Heitor Faria — todos los derechos reservados — https://podheitor.com

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

Deja una respuesta