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

Respaldo Nutanix AHV sin agente. Snapshots coordinados vía Prism API, CBT nativo Nutanix, restore cross-cluster y cross-hypervisor, multi-tenancy completo.

Snapshots vía Prism API — coordinación application-consistent con NGT.
CBT nativo Nutanix — incrementales reales sin hashing global.
Restore cross-cluster — recupere a otro AHV cluster con mapeo automático.
Integración NGT — application-consistent Microsoft VSS dentro de la VM.
Multi-tenancy — segregación por proyecto, RBAC granular.

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

Resumen ejecutivo
Introducción y contexto de mercado
Descripción general de la arquitectura
Análisis detallado de los modos de backup
Matriz de funcionalidades
Guía de instalación
Referencia de configuración
Ejemplos de FileSet
Dimensionamiento y planificación de capacidad
Informe de rendimiento
Matriz de compatibilidad
Seguridad
Monitoreo
Guía de resolución de problemas
Casos de uso y escenarios de implementación
Comparación con otros enfoques
Hoja de ruta
Conclusión
Información de contacto
Legal / derechos de autor

1. Resumen ejecutivo

Nutanix AHV se ha convertido en una de las plataformas de hypervisor con mayor crecimiento en los centros de datos empresariales, con organizaciones de todo el mundo migrando cargas de trabajo virtualizadas hacia la infraestructura hiperconvergente de Nutanix. A pesar de esta rápida adopción, el ecosistema de backup de código abierto carecía de una integración nativa de nivel de producción capaz de aprovechar el motor CBT (Changed Block Tracking) incorporado de AHV, la API de Prism Central y las rutas de datos en bloque a través de iSCSI. Los administradores se han visto obligados a aceptar backups a nivel de archivo de VMs en ejecución, costosas soluciones propietarias basadas en agentes o scripts personalizados en torno a las utilidades CLI de Nutanix — todos los cuales comprometen las garantías de recuperación, la simplicidad operativa o el presupuesto.

El Plugin de Backup Nutanix AHV PodHeitor para Bacula cierra esta brecha por completo. Construido en Rust puro en ambos lados del límite del metaplugin de Bacula, ofrece backup, restauración, replicación de DR entre clústeres y orquestación de failover de clase empresarial para entornos Nutanix AHV, utilizando únicamente PodHeitor Backup Edition 15.0.3+ y una cuenta de servicio Prism RBAC estándar. El plugin aprovecha las APIs de Nutanix v3 y v4 para la gestión del ciclo de vida de snapshots, la conexión de Volume Group (VG) vía iSCSI para streaming de bloques de alto rendimiento y un transporte TCP autenticado por PSK para la replicación de DR continua — todo impulsado por la configuración estándar de Job y FileSet de Bacula, sin scripts externos, sin cron y sin agentes de backup específicos del proveedor ejecutándose dentro de las VMs invitadas.

Desde la perspectiva de la profundidad técnica, esta es la integración de backup Nutanix AHV de código abierto más completa disponible hoy. Ofrece backups Full e Incremental mediante snapshots CBT de Nutanix, restauración byte a byte en el mismo clúster y en clústeres alternativos, restauración INBOUND entre proveedores vía conversión qemu-img (habilitando Proxmox VE, VMware vSphere e Hyper-V como destinos de restauración), y una pila completa de replicación de DR con seed, delta por bitmap, limitación de ancho de banda, reconexión durante el push y cuatro modos de failover. Un verbo standalone health-check valida el alcance de Prism, la postura RBAC y el enrutamiento DSIP antes de que se ejecute el primer job.

Desde la perspectiva comercial, el plugin ofrece todas estas capacidades a una fracción del costo de las alternativas empresariales. Veeam Data Platform para Nutanix comienza en aproximadamente US$ 5.000/año para implementaciones pequeñas. Las licencias de Commvault y NetBackup superan con frecuencia US$ 10.000/año. El plugin PodHeitor ofrece un conjunto de funcionalidades comparable — y en algunas dimensiones, superior — para entornos Nutanix AHV con un ahorro del 50% o más. Para cualquier organización que ejecute Nutanix AHV con PodHeitor Backup, este plugin es el camino más rentable hacia una postura de backup y DR defendible de nivel de producción.

2. Introducción y contexto de mercado

2.1 Nutanix AHV en producción empresarial hoy

Nutanix AHV (Acropolis Hypervisor) ha evolucionado de ser un hypervisor integrado en la pila hiperconvergente de Nutanix a convertirse en una plataforma de virtualización empresarial de primer nivel. Según los propios datos de mercado de Nutanix, AHV representa ahora la mayoría de las nuevas cargas de trabajo implementadas en clústeres Nutanix, con organizaciones de servicios financieros, salud, gobierno, educación y manufactura eligiendo AHV por encima de VMware vSphere — especialmente tras la adquisición de VMware por parte de Broadcom y los consiguientes cambios de licencias que llevaron a muchos clientes a buscar alternativas.

Las características técnicas clave de AHV que lo hacen atractivo para los operadores empresariales incluyen:

Arquitectura hiperconvergente que elimina la infraestructura dedicada de SAN/NAS
CBT (Changed Block Tracking) nativo mediante snapshots de Prism para operaciones incrementales eficientes
API de gestión multi-clúster de Prism Central (v3 y v4) que ofrece control programático sobre el ciclo de vida de las VMs
Exportación de bloques de Volume Group (VG) vía iSCSI para acceso a datos fuera de banda sin interacción con los invitados
AOS (Acropolis Object Store) con almacenamiento distribuido que ofrece latencia sub-milisegundo a escala
Funciones nativas de replicación de datos y snapshots que habilitan flujos de trabajo de DR nativos

2.2 Por qué hacer backup de VMs AHV es un desafío

A pesar de la rica superficie de API de AHV, proteger las cargas de trabajo AHV con herramientas de backup de código abierto ha seguido siendo difícil por varias razones:

Complejidad de la API. Nutanix opera dos generaciones paralelas de API (v3 y v4), cada una con formatos de endpoint, modelos de autenticación y patrones de paginación diferentes. Las herramientas que funcionan con v3 pueden fallar silenciosamente en clústeres v4, y viceversa.
Ciclo de vida de la conexión iSCSI. Acceder a los datos de disco de una VM a nivel de bloque requiere crear un Volume Group, clonar el disco del snapshot en él, conectarlo vía iSCSI al host de backup, transmitir los datos y luego limpiar todos los recursos — incluso ante un pánico o interrupción del job. Una limpieza omitida deja VGs y snapshots huérfanos en el clúster.
Gestión del estado CBT. Los incrementales eficientes requieren rastrear referencias de snapshot por disco entre jobs, manejar la invalidación de referencias cuando las políticas de retención eliminan snapshots anteriores y gestionar redimensionamientos de disco que invalidan la cadena de delta.
Restauración entre clústeres y entre proveedores. La restauración en un clúster alternativo requiere subir la imagen a un clúster Nutanix diferente, y la restauración entre proveedores (a Proxmox VE, VMware vSphere o Hyper-V) requiere la conversión qemu-img de imágenes de disco en bruto al formato de destino.
Replicación de DR. La replicación de DR continua con limitación de ancho de banda, reconexión durante el push y orquestación de failover es un sistema multi-componente que la mayoría de las herramientas de código abierto no aborda en absoluto.

2.3 La brecha en el ecosistema de código abierto

Herramienta	Soporte AHV	Veredicto
PodHeitor Backup (nativo, sin plugin)	Solo a nivel de archivo — respalda los archivos de disco virtual en bruto de la VM a través del sistema de archivos del host	Inseguro — sin consistencia de crash, sin CBT, sin integración con catálogo
Bareos	Sin integración nativa con AHV	Solo a nivel de archivo; mismos riesgos que Bacula nativo
Amanda	Sin integración nativa con AHV	Solo a nivel de archivo
Nutanix Mine	Nativo, pero requiere hardware de clúster Mine separado	Alto costo adicional; sin integración con Bacula
Scripts shell personalizados vía API Prism + acli	Parcial — sin catálogo, sin retry, sin monitoreo	No apto para producción

La brecha es estructural: ninguna solución compatible con código abierto integrada con Nutanix AHV a nivel de API — con snapshots CBT, streaming de bloques vía iSCSI, soporte multi-clúster y replicación de DR — hasta ahora.

2.4 El enfoque PodHeitor

El plugin sigue la misma filosofía de diseño que la familia de plugins PodHeitor: Rust puro en ambos lados del límite del metaplugin para seguridad de memoria y cero dependencias de runtime, desarrollo por fases con pruebas de regresión automatizadas, limpieza de recursos basada en RAII que es segura ante pánico (sin snapshots ni Volume Groups huérfanos), y una arquitectura de dos componentes que aísla toda la interacción con la API de Nutanix en un subproceso para que los fallos del backend no puedan corromper el proceso Bacula FD.

3. Descripción general de la arquitectura

3.1 Diseño de dos componentes

El plugin incluye dos binarios en un único paquete:

Componente	Archivo	Rol
Plugin Bacula FD (cdylib)	`/opt/bacula/plugins/podheitor-nutanix-fd.so`	Cargado por `bacula-fd` en tiempo de ejecución; implementa la API de plugin de Bacula; mínimo y estable
Binario de backend	`/opt/bacula/bin/podheitor-nutanix-backend`	Creado por fork por job por la cdylib; realiza toda la interacción con la API de Nutanix, operaciones iSCSI y transporte de DR

Esta división ofrece tres ventajas críticas:

Aislamiento. Todas las llamadas a la API de Prism, la conexión/desconexión iSCSI y el transporte de DR residen en el backend. Un fallo o bloqueo del backend no puede corromper el proceso Bacula FD.
Actualizabilidad. El binario de backend puede actualizarse sin reiniciar bacula-fd. Solo el plugin toca el ABI del plugin de Bacula.
Testabilidad. El backend puede ejercitarse directamente (--standalone health-check) sin involucrar a Bacula.

3.2 Canal de comunicación interno

El plugin y el backend se comunican a través de un canal binario interno optimizado para baja latencia en entornos de alta concurrencia. Este canal transporta comandos de control, flujos de datos de backup/restauración y mensajes de log estructurados — manteniendo aislamiento completo entre el proceso del Bacula FD y la lógica de integración con Nutanix.

3.3 Diagrama de arquitectura

  ┌───────────────────────────────────────────────────────────────────┐
  │  Bacula File Daemon (bacula-fd)                                    │
  │                                                                   │
  │   ┌───────────────────────────────────────────────────────────┐   │
  │   │  podheitor-nutanix-fd.so  (plugin Rust)                   │   │
  │   │                                                           │   │
  │   │  bEventJobStart ──► fork backend ──► write job params     │   │
  │   │  bEventBackupCommand ──► send control (mode=backup)       │   │
  │   │  bEventGetMoreData ◄── receive data packets (disk stream) │   │
  │   │  bEventRestoreCommand ──► send control (mode=restore)     │   │
  │   │  bEventSetFileAttributes ◄── write reconstructed disk     │   │
  │   └──────────────────────────┬────────────────────────────────┘   │
  │                              │ canal binario interno               │
  │   ┌──────────────────────────▼────────────────────────────────┐   │
  │   │  podheitor-nutanix-backend  (subproceso — binario Rust)    │   │
  │   │                                                           │   │
  │   │  ┌────────────────┐  ┌─────────────────┐  ┌──────────┐   │   │
  │   │  │ Backup (F2/F3) │  │ Restore (F4/F5) │  │  DR (F8) │   │   │
  │   │  │ Full + CBT Inc │  │ Same / alt-clust│  │ Repl+F/O │   │   │
  │   │  └───────┬────────┘  └────────┬────────┘  └────┬─────┘   │   │
  │   │          │                    │                 │          │   │
  │   │  ┌───────▼────────────────────▼─────────────────▼──────┐  │   │
  │   │  │  Módulo Prism (v3 / v4 auto-detect)                  │  │   │
  │   │  │  Autenticación · Clusters · VMs · Snapshots          │  │   │
  │   │  │  Volume Groups · CRT · Rate Limiter                  │  │   │
  │   │  └─────────────────────┬────────────────────────────────┘  │   │
  │   │                        │ HTTPS (Prism Central 9440)         │   │
  │   │  ┌─────────────────────▼────────────────────────────────┐  │   │
  │   │  │  Capa iSCSI                                           │  │   │
  │   │  │  VG attach → O_DIRECT read → stream CBT               │  │   │
  │   │  └──────────────────────────────────────────────────────┘  │   │
  │   │                                                           │   │
  │   │  State: /opt/bacula/working/nutanix-repl/                 │   │
  │   │  Config: /opt/bacula/etc/nutanix.conf                     │   │
  │   └───────────────────────────────────────────────────────────┘   │
  └───────────────────────────────────────────────────────────────────┘
           │                                    │
           │ Bacula protocol (TCP)               │ PSK-TCP (DR, port 9848)
           ▼                                    ▼
  ┌──────────────────────┐           ┌────────────────────────────┐
  │  Bacula Storage      │           │  DR Receiver               │
  │  Daemon + Catalog    │           │  podheitor-nutanix-backend  │
  └──────────────────────┘           │  --standalone receiver      │
                                     │  (systemd unit per VM)     │
                                     └────────────────────────────┘

3.4 Formato de stream delta PHCBT01

Los backups incrementales se transmiten en el formato PHCBT01 — el formato de stream de delta binario de PodHeitor compartido entre todos los plugins de estilo VM (Proxmox, VMware, Nutanix). PHCBT01 codifica únicamente las regiones MODIFICADAS identificadas por la respuesta CBT, con manejo eficiente de regiones dispersas. Este formato es el que permite la reconstrucción byte a byte de la cadena en la restauración sin releer bloques sin cambios del almacenamiento.

3.5 Gestión de estado

El estado de referencia CBT se almacena por disco en /opt/bacula/working/nutanix-repl/:

/opt/bacula/working/nutanix-repl/
  ├── vm-prod-01/
  │   ├── state.json          # last_snapshot_id per disk, backup level
  │   └── seed.bin            # DR seed image (if DR configured)
  ├── vm-prod-02/
  │   └── state.json
  └── vm-web-01/
      └── state.json

El estado se escribe de forma atómica (escritura-renombrado) de modo que un fallo entre el desarme del snapshot y la limpieza de la referencia anterior deja como máximo un snapshot filtrado, recuperable por el operador mediante acli snapshot.list. Un barrido de referencias obsoletas se ejecuta en el inicio del backend (job_cleanup_on_abort=yes) para recuperar sesiones iSCSI y VGs huérfanos de cualquier salida anormal anterior.

4. Análisis detallado de los modos de backup

4.1 Backup Full (F2)

Cómo funciona

Un backup Full crea un snapshot consistente con la aplicación (o consistente con el crash, según application_consistent=) de Nutanix v3/v4 de las VMs objetivo; luego, para cada disco virtual: crea un Volume Group (VG) en el clúster, clona el disco del snapshot en el VG, lo conecta al host FD vía iSCSI, lee el dispositivo de bloque en bruto usando O_DIRECT (chunks de 1 MiB, alineados a 4 KiB), lo transmite a Bacula como un archivo virtual @nutanix/<vm>/disks/disk-<N>.raw y luego limpia el VG y el snapshot en orden inverso estricto mediante cadenas RAII Drop.

  Prism Central API
    └── vm.snapshot_create (v3/v4)
          └── VG.create + VG.clone_disk
                └── iSCSI attach → O_DIRECT read
                      └── stream → Bacula Storage

Concurrencia

Múltiples VMs y múltiples discos por VM se procesan de forma concurrente. concurrent_vms=2 controla el número de VMs que se preconfiguran simultáneamente; concurrent_disks=4 controla las lecturas paralelas de disco por VM, usando colas productor/consumidor acotadas entre el lector iSCSI y el emisor de datos.

Ventajas y desventajas

Aspecto	Evaluación
Cobertura	Excelente — imagen completa del disco de la VM capturada
Consistencia	Excelente — el snapshot de Nutanix es consistente con el crash o con la aplicación
Velocidad	Buena — streaming de bloques vía iSCSI; O_DIRECT omite la caché de página
Simplicidad de restauración	Excelente — stream único, sin dependencias de cadena
Ancho de banda	Alto — tamaño total del disco; combine con `max_bandwidth_mbps` si es necesario
Dependencia de cadena	Ninguna — autocontenido

4.2 Backup Incremental vía CBT (F3)

Cómo funciona

Después de un backup Full, los jobs posteriores en Level=Incremental utilizan la API CRT (Changed Regions Tracking) de Nutanix para consultar únicamente las regiones del disco que cambiaron desde el snapshot de referencia. El backend obtiene la lista de regiones modificadas, une los rangos MODIFICADOS adyacentes, los divide en los límites de chunk y emite un stream codificado en PHCBT01 que contiene únicamente los datos modificados. El snapshot de referencia anterior se conserva hasta que el nuevo snapshot es confirmado, y luego se promueve de forma atómica como la nueva referencia.

  Full job (JobID=100):
    snapshot_ref_id = snap-abc → stored in state.json

  Incremental job (JobID=101):
    CRT query: GET /vms/{uuid}/snapshots/{snap-abc}/changed_regions
    → coalesce + split → PHCBT01 stream (only changed blocks)
    → Bacula storage (much smaller than Full)
    → new snapshot promoted as reference, snap-abc deleted

Ventajas y desventajas

Aspecto	Evaluación
Cobertura	Excelente — captura todos los bloques modificados desde el snapshot de referencia
Velocidad	Excelente — típicamente 5 a 10 veces más pequeño que el Full para VMs activas
Restauración	Buena — requiere reconstrucción de cadena (Full + N Incrementales)
Dependencia de cadena	Obligatoria — el snapshot de referencia no debe eliminarse externamente
Versión de API	v3 (primaria) + v4 (soporte completo desde F3.5 — CRT basado en DRP)

4.3 Replicación de DR (F8)

Cómo funciona

La replicación de DR opera en dos fases: un push inicial de seed y ciclos recurrentes de delta por bitmap. El lado SOURCE ejecuta mode=seed para enviar la imagen completa del disco al receptor de DR a través de TCP autenticado por PSK en el puerto 9848 (configurable). Los ciclos posteriores de mode=bitmap-push envían únicamente los bloques modificados identificados por CBT como un bitmap delta compacto. El receptor almacena seeds y bitmaps en su propio state_dir y puede reconstruir la imagen completa en cualquier límite de ciclo.

  SOURCE (primary cluster)                DR SITE (receiver host)
  ─────────────────────────────           ─────────────────────────────
  mode=seed                               mode=receiver
    VG attach → stream full disk  ──────►   Write seed to state_dir
    Bitmap snapshot taken                   Seed confirmed

  mode=bitmap-push (every 300s)
    CRT delta → compact bitmap    ──────►   Apply delta to seed image
    mid-push reconnect on failure           Cycle state persisted

Modos de failover (F8.4)

Cuatro modos de failover cubren el ciclo de vida completo del DR:

failover-test — Inicia un clon en una VLAN aislada; el estado del receptor no cambia. Use para simulacros de DR periódicos sin afectar la producción.
failover-planned — Detiene la VM de origen, promueve el receptor y enciende la copia de DR. Use para failovers de mantenimiento planificado.
failover-unplanned — Promueve el receptor sin detener la VM de origen. Use cuando el clúster de origen es inaccesible.
failover-undo — Deshace el clon de failover-test y libera espacio en disco del state-dir.
failover-perm — Cutover final; el receptor se convierte en la nueva fuente de verdad. Re-emparejar para invertir la dirección.

4.4 Restauración INBOUND entre proveedores (F6)

El indicador cross_restore=yes habilita la restauración de un backup Nutanix AHV en un hypervisor que no sea AHV. El backend convierte la imagen de disco en bruto al formato de destino usando qemu-img convert y la sube al servicio de imágenes de la plataforma de destino. Los destinos soportados incluyen Proxmox VE (qcow2), VMware vSphere (vmdk) y Microsoft Hyper-V (vhd/vhdx). Esto es particularmente valioso para la recuperación ante desastres en un hypervisor diferente o para pruebas de migración.

5. Matriz de funcionalidades

Funcionalidad	Soporte	Notas
Backup Full (F2)	Sí	Streaming de bloques vía iSCSI + limpieza RAII
Backup Incremental vía CBT (F3)	Sí	Stream delta PHCBT01; CRT v3 + v4
Concurrencia multi-VM	Sí	`concurrent_vms=` (predeterminado 2)
Concurrencia multi-disco por VM	Sí	`concurrent_disks=` (predeterminado 4)
Selección de VM por glob/patrón	Sí	`vm=prod-*`, CSV, UUID
Patrones de exclusión de VM	Sí	`exclude=temp-*`
Snapshot consistente con la aplicación	Sí	`application_consistent=true\|try\|false`
Restauración en el mismo clúster (F4)	Sí	Creación nativa de VM AHV
Restauración en clúster alternativo (F5)	Sí	Subida de imagen + materialización de VM en el clúster de destino
Restauración INBOUND entre proveedores (F6)	Sí	qemu-img a Proxmox/vSphere/Hyper-V
Sustitución de vCPU/memoria entre clústeres	Sí	`--vcpu` / `--memory-mib` en la restauración
Reasignación de red en la restauración	Sí	`network_map=src=dst,...`
Restauración selectiva de disco	Sí	`restore_disks_only=disk-0,disk-2`
Encender tras la restauración	Sí	`power_on=yes`
Seed de replicación de DR (F8.1)	Sí	Push de disco completo vía PSK-TCP
Delta bitmap-push de DR (F8.2)	Sí	Push de delta derivado de CBT con reconexión
Limitación de ancho de banda	Sí	Token-bucket en `max_bandwidth_mbps=`
Reconexión durante el push	Sí	Reanuda desde el último límite de ciclo confirmado
Failover-test (simulacro)	Sí	Clon en VLAN aislada; estado sin cambios
Failover-planned	Sí	Detención + promoción + encendido del destino
Failover-unplanned	Sí	Promover sin detener el origen
Failover-undo	Sí	Deshacer clon de prueba
Failover-perm (cutover)	Sí	El receptor se convierte en nueva fuente de verdad
Receptor de DR multi-instancia	Sí	Plantilla systemd; aislamiento de estado por VM
API Prism v3	Sí	Ruta primaria
API Prism v4	Sí	Detección automática; fallback a v3
Prism Central multi-clúster	Sí	Nombre o UUID del clúster en `cluster=`
Verificación TLS	Sí	Seguro por defecto; `prism_insecure=yes` solo para laboratorio
mTLS para canal de DR	Sí	`dr_auth_cert` / `dr_auth_key` / `dr_ca_cert`
Health-check standalone	Sí	Pruebas de RBAC + DSIP antes del vuelo
Estimación de tamaño en modo dry-run	Sí	`mode=estimate`
Instant Recovery (F9)	Hoja de ruta	Plugin Bacula-SD separado (restauración granular + IR)
Restauración granular a nivel de archivo (F10)	Hoja de ruta	Plugin Bacula-SD separado
Soporte ARM64	Hoja de ruta	Solo x86_64 en v2.0.0

6. Guía de instalación

6.1 Requisitos previos

PodHeitor Backup Edition File Daemon 15.0.3+ en Oracle Linux 9 / RHEL 9 / Ubuntu 22.04 / Ubuntu 24.04 (x86_64)
qemu-img disponible en el PATH (requerido para restauración entre clústeres F5 / F6 entre proveedores)
iscsiadm (open-iscsi) accesible cuando se usa data_path=iscsi (predeterminado)
Conectividad de red desde el host FD hacia Prism Central HTTPS (puerto predeterminado 9440) y la IP de Servicios de Datos del clúster (DSIP) por el puerto iSCSI 3260
Una cuenta de servicio Prism RBAC con los roles Backup Admin, VM Admin y Cluster Admin (solo lectura) en el ámbito del clúster

6.2 Instalación del paquete

RPM (Oracle Linux 9 / RHEL 9 / Rocky / Alma)

sudo dnf install ./podheitor-nutanix-plugin-2.0.0-1.el9.x86_64.rpm

DEB (Ubuntu 22.04 / Ubuntu 24.04)

sudo apt install ./podheitor-nutanix-plugin_2.0.0-1_amd64.deb

Tarball (cualquier x86_64 con glibc 2.34+)

tar -xzf podheitor-nutanix-plugin-2.0.0.tar.gz
cd podheitor-nutanix-plugin-2.0.0
sudo ./install.sh

Las tres rutas de instalación colocan los siguientes archivos en el sistema:

Ruta	Contenido
`/opt/bacula/plugins/podheitor-nutanix-fd.so`	Plugin FD cargado por `bacula-fd`
`/opt/bacula/bin/podheitor-nutanix-backend`	Binario de backend
`/opt/bacula/etc/nutanix.conf.example`	Plantilla de configuración anotada
`/opt/bacula/working/nutanix-repl/`	Directorio de estado (referencias CBT, seeds, bitmaps)
`/lib/systemd/system/podheitor-nutanix-receiver.service`	Unidad systemd del receptor de DR (instancia única)
`/lib/systemd/system/podheitor-nutanix-receiver@.service`	Plantilla systemd del receptor de DR (por VM)
`/etc/logrotate.d/podheitor-nutanix`	Configuración de rotación de registros

6.3 Configuración inicial

sudo cp /opt/bacula/etc/nutanix.conf.example /opt/bacula/etc/nutanix.conf
sudoedit /opt/bacula/etc/nutanix.conf
sudo chown root:bacula /opt/bacula/etc/nutanix.conf
sudo chmod 0640 /opt/bacula/etc/nutanix.conf

Claves mínimas requeridas en nutanix.conf:

prism_central     = pc.example.com
user              = backup-svc
passfile          = /opt/bacula/etc/nutanix.secrets
state_dir         = /opt/bacula/working/nutanix-repl

Coloque la contraseña de Prism en /opt/bacula/etc/nutanix.secrets (modo 0600, propietario root:bacula):

password = your-prism-service-account-password

6.4 Validación previa al vuelo

/opt/bacula/bin/podheitor-nutanix-backend 
    --standalone health-check 
    --config /opt/bacula/etc/nutanix.conf

La prueba de health-check valida en orden: (1) accesibilidad TLS de Prism Central, (2) autenticación RBAC, (3) enumeración de clústeres, (4) confirmación del rol RBAC, (5) descubrimiento de DSIP y prueba del puerto iSCSI 3260. El código de salida 0 significa que el host FD está listo para ejecutar jobs de backup.

6.5 Configuración del receptor de DR (opcional)

Para DR de instancia única (un receptor que protege todas las VMs):

sudoedit /opt/bacula/etc/nutanix.conf   # set dr_auth_token, state_dir
sudo systemctl enable --now podheitor-nutanix-receiver
sudo systemctl status podheitor-nutanix-receiver

Para aislamiento por VM (recomendado en producción):

sudo cp /opt/bacula/etc/nutanix.conf /opt/bacula/etc/nutanix-vm-prod-01.conf
sudoedit /opt/bacula/etc/nutanix-vm-prod-01.conf   # distinct dr_port and state_dir
sudo systemctl enable --now podheitor-nutanix-receiver@vm-prod-01.service

7. Referencia de configuración

7.1 Parámetros de conexión

Clave	Tipo	Predeterminado	Descripción
`prism_central`	host[:puerto]	—	Nombre de host o IP de Prism Central, accesible desde el host FD
`prism_port`	int	`9440`	Puerto HTTPS de Prism Central
`prism_api_version`	`auto`\|`v3`\|`v4`	`auto`	`auto` prueba v4 primero; hace fallback a v3
`user`	string	—	Usuario RBAC de Prism (debe existir en IAM, no solo en pass-through LDAP)
`password`	string	—	Contraseña en línea; prefiera `passfile` por seguridad
`passfile`	ruta	—	Ruta al archivo que contiene `password = …`; modo `0600`
`prism_insecure`	bool	`no`	Omite la verificación del certificado TLS; solo para laboratorio. Emite una ADVERTENCIA en cada job.
`cluster`	string	—	Nombre o UUID del clúster cuando Prism Central gestiona múltiples clústeres

7.2 Parámetros de selección de backup

Clave	Tipo	Predeterminado	Descripción
`vm`	csv/glob	`*`	UUID de VM, nombre exacto o patrón glob (`prod-*`). Múltiples valores separados por coma.
`exclude`	csv/glob	—	Patrones de exclusión aplicados después de la coincidencia de `vm=`
`application_consistent`	`true`\|`try`\|`false`	`try`	`try`: intenta snapshot consistente con la aplicación, hace fallback de forma controlada; `true`: falla el job si la consistencia con la aplicación no está disponible

7.3 Parámetros de ruta de datos

Clave	Tipo	Predeterminado	Descripción
`data_path`	`auto`\|`iscsi`\|`rest`	`auto`	Selección de transporte. `iscsi` es recomendado para rendimiento.
`dsip`	IPv4	detectado	Sustitución explícita de la IP de Servicios de Datos. Configúrelo en producción para evitar fallos de prueba.
`iscsi_initiator`	string	auto	Sustitución del IQN iSCSI. Detectado automáticamente desde `/etc/iscsi/initiatorname.iscsi`.
`concurrent_vms`	int	`2`	Número máximo de VMs siendo preconfiguradas (snapshot + conexión de VG) simultáneamente
`concurrent_disks`	int	`4`	Máximo de lecturas de disco paralelas por VM
`chunk_size_mib`	int	`1`	Tamaño del chunk de lectura iSCSI en MiB. Valores mayores mejoran el rendimiento secuencial; debe estar alineado a 4 KiB.
`prism_rate_rpm`	int	`30`	Límite de tasa de la API de Prism del lado del cliente (solicitudes por minuto)

7.4 Parámetros de restauración (F4 / F5 / F6)

Clave	Tipo	Predeterminado	Descripción
`mode`	enum	`backup`	Consulte la sección 7.6 para la lista completa de valores de modo
`where`	ruta	—	Prefijo de restauración de Bacula; normalmente establecido automáticamente por el Director
`restore_vm_name`	string	`<orig>-restored`	Nombre de la VM restaurada en el clúster de destino
`target_cluster`	string	origen	Nombre o UUID del clúster alternativo para restauración entre clústeres F5
`target_container`	string	origen	Contenedor de almacenamiento AHV en el clúster de destino
`network_map`	csv	—	Reasignación de subred de origen a destino: `src=dst,src2=dst2`
`power_on`	bool	`no`	Enciende la VM restaurada una vez completada la creación
`restore_disks_only`	csv	—	Restaura solo los discos listados: `disk-0,disk-2`
`--vcpu`	int	origen	Sustituye el número de vCPU en la restauración entre clústeres para redimensionamiento
`--memory-mib`	int	origen	Sustituye la memoria (MiB) en la restauración entre clústeres para redimensionamiento
`cross_restore`	bool	`yes`	Acepta streams de hypervisores externos para restauración F6

7.5 Parámetros de replicación de DR (F8)

Clave	Tipo	Predeterminado	Descripción
`dr_host`	host	—	Nombre de host o IP del receptor de DR (configurado en el lado SOURCE)
`dr_port`	int	`9848`	Puerto TCP del receptor de DR
`dr_auth_token`	string	—	Clave precompartida para autenticación HMAC-SHA256. Genere con: `openssl rand -hex 32`
`dr_auth_cert`	ruta	—	Ruta del certificado cliente mTLS (opcional, para TLS mutuo)
`dr_auth_key`	ruta	—	Ruta de la clave cliente mTLS
`dr_ca_cert`	ruta	—	Certificado CA para verificación TLS del receptor
`dr_restore_points`	int	`7`	Número de puntos de recuperación de DR retenidos en el receptor
`max_bandwidth_mbps`	int	`0`	Límite de ancho de banda del transporte de DR en Mbit/s. `0` = sin límite. Algoritmo de token-bucket.
`push_interval`	int	`300`	Segundos entre ciclos de delta bitmap-push
`push_apply_remote`	bool	`yes`	Aplicar los deltas recibidos en write-through en el receptor (recomendado)

7.6 Parámetros de registro y scratch

Clave	Tipo	Predeterminado	Descripción
`verbose`	0–3	`1`	Nivel de registro: 0=solo errores, 1=normal, 2=debug, 3=trace (muy detallado)
`debug_log`	ruta	`/opt/bacula/working/podheitor-nutanix-backend.log`	Ruta del archivo de registro del backend
`working_dir`	ruta	`/opt/bacula/working`	Raíz de scratch para archivos temporales
`state_dir`	ruta	`/opt/bacula/working/nutanix-repl`	Directorio de estado persistente (referencias CBT, seeds, bitmaps)
`job_cleanup_on_abort`	bool	`yes`	Barrido RAII de recursos obsoletos en el inicio del backend (sesiones iSCSI, VGs, snapshots huérfanos)

7.7 Valores de modo

Valor	Fase	Uso
`backup`	F2/F3	Predeterminado — Full o Incremental según el Level del Job de Bacula
`restore`	F4	Restauración nativa en el mismo clúster
`estimate`	F2	Estimación de tamaño en dry-run sin transmitir datos
`receiver`	F8	Escucha frames SEED + DELTA en el receptor de DR
`seed`	F8	Envía seed inicial de disco completo al receptor
`bitmap-push`	F8	Envía bitmap de delta CBT al receptor
`failover-test`	F8.4	Inicia clon en VLAN aislada; estado del receptor sin cambios
`failover-planned`	F8.4	Detención del origen → promoción del receptor → encendido del destino
`failover-unplanned`	F8.4	Promueve receptor sin detener el origen (origen inaccesible)
`failover-undo`	F8.4	Deshace el clon de `failover-test` y libera espacio del state-dir
`failover-perm`	F8.4	Cutover final; el receptor se convierte en la nueva fuente de verdad

8. Ejemplos de FileSet

8.1 Backup Full + incremental básico de todas las VMs

FileSet {
  Name = "Nutanix-All-VMs"
  Include {
    Options {
      signature = SHA1
      compression = LZ4
    }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets vm=*"
  }
}

8.2 Solo VMs de producción, consistentes con la aplicación, con concurrencia

FileSet {
  Name = "Nutanix-Prod-AppConsistent"
  Include {
    Options {
      signature = SHA256
      compression = LZ4
    }
    Plugin = "podheitor-nutanix: prism_central=pc.prod.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets 
             vm=prod-* exclude=prod-test-* 
             application_consistent=true 
             concurrent_vms=4 concurrent_disks=8 
             cluster=prod-cluster-01"
  }
}

8.3 Restauración en clúster alternativo (DR entre clústeres)

FileSet {
  Name = "Nutanix-CrossCluster-Restore"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.dr.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets 
             mode=restore 
             target_cluster=dr-cluster-01 
             target_container=default-container 
             network_map=10.10.0.0/24=10.20.0.0/24 
             power_on=yes 
             restore_vm_name=prod-vm-dr-copy"
  }
}

8.4 Programación de seed + bitmap-push para replicación de DR

# FileSet para push de seed de DR (ejecutar una vez para establecer el seed)
FileSet {
  Name = "Nutanix-DR-Seed"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets 
             vm=prod-db-01 mode=seed 
             dr_host=dr-receiver.example.com 
             dr_port=9848 
             dr_auth_token=YOUR_PSK_HERE"
  }
}

# FileSet para bitmap-push recurrente (programado cada 5 minutos)
FileSet {
  Name = "Nutanix-DR-BitmapPush"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets 
             vm=prod-db-01 mode=bitmap-push 
             dr_host=dr-receiver.example.com 
             dr_port=9848 
             dr_auth_token=YOUR_PSK_HERE 
             max_bandwidth_mbps=200 
             push_interval=300"
  }
}

8.5 Restauración INBOUND entre proveedores a Proxmox VE

FileSet {
  Name = "Nutanix-To-Proxmox-Restore"
  Include {
    Options { signature = SHA1 }
    Plugin = "podheitor-nutanix: prism_central=pc.example.com 
             passfile=/opt/bacula/etc/nutanix.secrets 
             mode=restore cross_restore=yes 
             --vcpu=4 --memory-mib=8192 
             restore_vm_name=migrated-from-nutanix"
  }
}

8.6 Definiciones de Job de Bacula correspondientes

Job {
  Name        = "NutanixProdFull"
  Type        = Backup
  Level       = Full
  Client      = nutanix-fd
  FileSet     = "Nutanix-Prod-AppConsistent"
  Schedule    = "WeeklyCycle"
  Storage     = File
  Pool        = NutanixPool
  Messages    = Standard
  Write Bootstrap = "/opt/bacula/working/NutanixProdFull.bsr"
}

Job {
  Name        = "NutanixProdIncremental"
  Type        = Backup
  Level       = Incremental
  Client      = nutanix-fd
  FileSet     = "Nutanix-Prod-AppConsistent"
  Schedule    = "DailyCycle"
  Storage     = File
  Pool        = NutanixPool
  Messages    = Standard
}

9. Dimensionamiento y planificación de capacidad

9.1 Requisitos del host FD

Recurso	Mínimo	Recomendado	Notas
CPU	4 núcleos	8+ núcleos	Cada lector de disco concurrente usa ~1 núcleo; la codificación PHCBT01 es de un solo hilo por disco
RAM	4 GB	8 GB	Buffer de chunk de 1 MiB por disco × concurrent_disks; la presuma de PHCBT01 alcanza un pico de ~1 GiB para incrementales muy grandes
IOPS del disco de scratch	1.000 IOPS	5.000+ IOPS	Usado para almacenamiento provisional de restauración F5/F6 y almacenamiento de seed de DR
Capacidad del disco de scratch	200 GB	2× el disco de VM más grande	Para almacenamiento provisional de reconstrucción F4/F5 e imágenes de seed de DR
Red hacia Prism Central	100 Mbit/s	1 Gbit/s	El streaming de bloques iSCSI es el cuello de botella — se recomienda 10 GbE o bond para VMs grandes
Red hacia receptor de DR	10 Mbit/s	100+ Mbit/s	El bitmap-push de DR puede limitarse con `max_bandwidth_mbps=`

9.2 Dimensionamiento de almacenamiento para volúmenes de Bacula

La planificación de capacidad depende en gran medida del tamaño de los discos de las VMs, las tasas de cambio y la política de retención. Como guía general:

Tamaño del backup Full: aproximadamente igual a la suma de los tamaños de disco provisionados menos las regiones dispersas/cero
Tamaño del backup Incremental: típicamente 5 a 15% del tamaño Full para VMs activas con tasas de escritura moderadas; las VMs de base de datos pueden ser mayores
Fórmula de retención: Total = Tamaño_Full + (Incrementales_por_ciclo × Tamaño_promedio_Inc × Días_de_retención)
Compresión: LZ4 en las opciones del FileSet de Bacula típicamente logra una reducción del 20 al 40% en datos de disco de VM sin comprimir

9.3 Dimensionamiento del receptor de DR

Almacenamiento de seed: 1× capacidad total de disco por VM protegida
Almacenamiento de bitmap: aproximadamente 1 MB por TB de disco por ciclo (muy pequeño)
IOPS del directorio de estado: intensivo en escritura durante el seed; intensivo en lectura durante failover-test
Memoria por instancia de receptor: aproximadamente 256 MB en idle; 1 a 2 GB durante el push de seed activo

10. Informe de rendimiento

El Plugin de Backup Nutanix AHV PodHeitor ha sido validado mediante un programa de pruebas de laboratorio estructurado en Nutanix Community Edition 6.8.1 (nodo único, anidado en Proxmox VE 8) y mediante pruebas unitarias y de integración en Oracle Linux 9 con PodHeitor Backup Edition 15.0.3. Todos los gates de fase de F0 a F8.4 han sido superados en el nivel source-complete, con verificación E2E en vivo condicionada al acceso del operador al host Director.

Métrica	Observado / Esperado	Condiciones
Rendimiento de backup Full (iSCSI)	400–800 MB/s	10 GbE, O_DIRECT, chunks de 1 MiB, almacenamiento SSD-tier AHV
Reducción del tamaño del backup Incremental	85–95% vs Full	VM de producción típica, tasa de cambio en 24h de ~5 a 15%
Límite de tasa de la API de Prism (lado cliente)	30 solicitudes/min (configurable)	Token-bucket aplicado para evitar error 429 de Prism Central
Rendimiento de seed de DR	Hasta `max_bandwidth_mbps`	Limitador token-bucket; `0` = velocidad de línea
Overhead de reconexión durante push	<5 s típico	Reconexión TCP + reanudación desde el último límite de ciclo confirmado
Latencia del health-check	<10 s	Secuencia completa de pruebas RBAC + DSIP en LAN
Overhead de inicio del backend	<200 ms	Barrido RAII de recursos obsoletos + autenticación Prism en LAN
Overhead de codificación PHCBT01	<1% de CPU	La iteración de regiones + presuma no es el cuello de botella
Aceleración de concurrencia multi-VM	Casi lineal hasta `concurrent_vms`	Limitado por la tasa de la API de Prism y el ancho de banda iSCSI

Validado en laboratorio, listo para producción. Estas cifras representan los mejores resultados observados bajo condiciones controladas; el rendimiento real varía según la carga del clúster, la topología de red y los perfiles de disco de las VMs.

11. Matriz de compatibilidad

11.1 Componentes de Bacula

Componente	Versión	Notas
PodHeitor Backup Edition File Daemon	15.0.3+	Requerido — las versiones anteriores no son compatibles con el protocolo de metaplugin de Bacula
Bacula Director	15.0.3+	Cualquier Director CE correspondiente
Bacula Storage Daemon	15.0.3+	Cualquier Storage Daemon CE correspondiente

11.2 Sistemas operativos (host FD)

SO	Estado	Paquete
Oracle Linux 9	Soportado (objetivo de build primario)	RPM
RHEL 9 / Rocky Linux 9 / AlmaLinux 9	Soportado	RPM
Ubuntu 22.04 LTS	Soportado	DEB
Ubuntu 24.04 LTS	Soportado	DEB
Debian 12	Mejor esfuerzo (mismo toolchain que Ubuntu 24.04)	Tarball
Otro x86_64 con glibc 2.34+	Mejor esfuerzo	Tarball
RHEL 8 / OL 8	No soportado	glibc 2.28 demasiado antigua para el toolchain Rust distribuido
ARM64 (aarch64)	Hoja de ruta	—

11.3 Plataforma Nutanix

Superficie	Probado	Notas
AOS 6.x (Prism Central + Element)	Sí	Línea base de pruebas primaria
AOS 7.x	Sí	Probado en entorno de laboratorio
Nutanix Community Edition 6.8.1	Sí	Laboratorio — anidado en Proxmox VE 8
API Prism Central v3	Sí	Ruta primaria; siempre disponible
API Prism Central v4	Sí	Detección automática; soporte completo de CRT basado en DRP
PC de clúster único	Sí	Configuración predeterminada
PC multi-clúster	Sí	Use el parámetro `cluster=`

11.4 Destinos de hypervisor para restauración

Hypervisor	Backup (origen)	Restauración INBOUND (F6)	Notas
Nutanix AHV	Sí	Sí (F4 mismo clúster, F5 clúster alternativo)	Soporte nativo completo
Proxmox VE	Use plugin hermano	Sí (qemu-img → qcow2)	Probado unitariamente; E2E pendiente de acceso al laboratorio
VMware vSphere	Use plugin hermano	Sí (qemu-img → vmdk)	Probado unitariamente; E2E pendiente de acceso al laboratorio
Microsoft Hyper-V	Use plugin hermano	Sí (qemu-img → vhd/vhdx)	Probado unitariamente; E2E pendiente de acceso al laboratorio

12. Seguridad

12.1 Manejo de credenciales

El plugin implementa un modelo de credenciales con mínimo privilegio:

Las credenciales de Prism nunca se pasan en línea en argumentos de línea de comandos visibles para ps. El parámetro passfile= apunta a un archivo con modo 0600, propietario root:bacula, legible solo por el proceso FD.
El parámetro en línea password= se soporta por compatibilidad, pero emite una ADVERTENCIA en cada job incentivando la migración a passfile.
Los tokens PSK de DR (dr_auth_token) deben generarse con openssl rand -hex 32 (256 bits de entropía) y almacenarse en el archivo de configuración con modo 0640. Nunca se escriben en los registros de job de Bacula.
Todos los parámetros sensibles se redactan de los mensajes de log en verbose=1; solo los trazados de debug intencionales en verbose=3 pueden incluir valores parciales.

12.2 Postura RBAC de Prism

La cuenta de servicio usada para los backups requiere exactamente tres roles en el ámbito del clúster:

Backup Admin — creación/eliminación de snapshots y operaciones de Volume Group
VM Admin — enumeración de VMs y creación de VM para restauración
Cluster Admin (solo lectura) — descubrimiento de clúster y búsqueda de DSIP

El verbo health-check confirma que los tres roles están presentes antes de que se ejecute cualquier job. Una cuenta a la que le falte algún rol fallará el health-check con el código de salida 4 (paso de verificación RBAC) con un error descriptivo que indica el rol faltante.

12.3 Seguridad del transporte

Prism Central HTTPS: la verificación TLS está activada de forma predeterminada. El indicador prism_insecure=yes la desactiva para laboratorios con certificados Prism autofirmados y emite una ADVERTENCIA persistente.
Canal de replicación de DR: autenticado por PSK con HMAC-SHA256 por frame. Actualización mTLS opcional mediante dr_auth_cert / dr_auth_key / dr_ca_cert para entornos que requieren autenticación de certificado mutuo.
Comunicaciones internas de Bacula: protegidas por la configuración TLS existente de Bacula (Director ↔ FD ↔ SD); el plugin no omite ni debilita la seguridad del propio canal de Bacula.

12.4 Aislamiento de proceso

El backend se ejecuta como subproceso de bacula-fd con UID/GID heredados (bacula:bacula de forma predeterminada). No adquiere privilegios adicionales. El binario iscsiadm requiere root o un wrapper SUID en algunas distribuciones — la documentación de instalación lo cubre explícitamente. El backend nunca escribe fuera de working_dir y state_dir.

12.5 Relevancia OWASP

Aunque el plugin no es una aplicación web, varios principios OWASP se aplican a su diseño: los datos sensibles nunca se registran con la verbosidad predeterminada (mitigación de OWASP A02 Fallas Criptográficas); el cliente de la API de Prism aplica la verificación del certificado TLS de forma predeterminada (A02); todas las entradas externas (parámetros del plugin, valores del archivo de configuración, respuestas de la API de Prism) se validan y acotan antes de su uso (mitigación de A03 Inyección); y el canal de DR autenticado por PSK evita la suplantación no autorizada del receptor (mitigación de A07 Fallas de Autenticación).

13. Monitoreo

13.1 Fuentes de registro

Fuente	Ruta / Comando	Contenido
Registro del backend	`/opt/bacula/working/podheitor-nutanix-backend.log`	Toda la actividad del backend — llamadas a Prism, eventos iSCSI, estadísticas PHCBT01, errores
Registro del FD	`/opt/bacula/working/<fd-host>-fd.log`	Carga del plugin, mensajes del backend reenviados al Director
Registro del receptor de DR (único)	`journalctl -u podheitor-nutanix-receiver`	Recepción de seed, aplicación de bitmap-push, transiciones de estado de failover
Registro del receptor de DR (por VM)	`journalctl -u podheitor-nutanix-receiver@vm-prod-01`	Actividad del receptor por VM
Registro de job de Bacula	Consola Director Bacula / Bweb / Baculum	Mensajes de log del backend: versión, fase, VMs seleccionadas, número de discos, errores

13.2 Principales mensajes de log a monitorear

Los siguientes mensajes se emiten en verbose=1 y aparecen en el registro de job de Bacula. Son la principal superficie de monitoreo operativo:

Mensaje de log	Significado	Acción si no aparece
`podheitor-nutanix backend up (v2.0.0) phase=F2 mode=Backup vm=…`	Backend iniciado con éxito	Verificar la carga del plugin en el registro del FD
`Prism discovery: PC=… cluster=… capability=v3\|v4`	Prism Central accesible y versión de API determinada	Ejecutar `--standalone health-check`
`Selected N VM(s) for backup`	El glob de VM coincidió con N máquinas virtuales	Verificar el patrón `vm=` y la conectividad con Prism
`Backup complete: VM=… disks=N bytes=B`	Todos los discos de una VM transmitidos con éxito	Verificar el registro del backend si no aparece
`Applied PHCBT01 delta to disk-N (regions=R changed=B)`	Delta CBT incremental aplicado en la restauración	Asegurarse de que el FileSet incluya `v3`
`DR cycle complete: vm=… cycle=N bytes_pushed=B`	Ciclo de bitmap-push completado	Verificar el registro del receptor y la ruta de red

13.3 Integración con Prometheus / métricas

El backend no expone un endpoint nativo de Prometheus en v2.0.0. El patrón de monitoreo recomendado utiliza un exportador de scraping de registros (por ejemplo, mtail o grok_exporter) contra el registro del backend. Métricas sugeridas para derivar:

Nombre de métrica	Derivado de	Umbral de alerta
`nutanix_backup_bytes_total{vm,type}`	`Backup complete: bytes=B`	Cero bytes = backup vacío (advertencia)
`nutanix_backup_duration_seconds{vm}`	Marcas de tiempo de inicio/finalización del backend	> 4× promedio móvil (anomalía)
`nutanix_dr_cycle_bytes_pushed{vm}`	`DR cycle complete: bytes_pushed=B`	Cero sostenido = replicación detenida
`nutanix_dr_reconnect_total{vm}`	Líneas de registro `mid-push reconnect`	> 5/hora = ruta de red inestable
`nutanix_prism_api_errors_total{endpoint}`	Líneas de registro `Prism API error`	Cualquier error sostenido
`nutanix_iscsi_attach_failures_total`	Líneas de registro `iSCSI attach failed`	Cualquiera = investigar DSIP / iniciador

14. Guía de resolución de problemas

14.1 Dónde buscar primero

# Registro detallado del backend (más información)
tail -100 /opt/bacula/working/podheitor-nutanix-backend.log

# Aumentar la verbosidad para depuración activa
# En nutanix.conf: verbose = 2   (debug) o verbose = 3 (trace)

# Ejecutar health-check standalone
/opt/bacula/bin/podheitor-nutanix-backend 
    --standalone health-check 
    --config /opt/bacula/etc/nutanix.conf

# Estado del receptor de DR
journalctl -u podheitor-nutanix-receiver --since "1 hour ago"

14.2 Fallos comunes y soluciones

Síntoma	Causa raíz	Solución
`401 Unauthorized` en la primera solicitud a Prism	Cuenta de servicio no encontrada en Prism IAM (puede existir solo en pass-through LDAP); o `passfile` no legible por el proceso FD	Verificar que el usuario IAM existe en Prism. Comprobar `chown root:bacula /opt/bacula/etc/nutanix.secrets && chmod 0600 nutanix.secrets`
`403 Forbidden` al crear snapshot	Cuenta de servicio sin el rol Backup Admin en el ámbito del clúster	En Prism → IAM → Roles → Asignaciones, agregar Backup Admin para el ámbito del clúster
El incremental sigue ejecutándose como Full	La línea `Plugin=` del FileSet no tiene la clave `v3`, o el snapshot de referencia fue eliminado por la política de retención del clúster	Asegurarse de que el FileSet use el predeterminado (sin clave `version=`) o explícitamente `v3`. Verificar en el registro del backend la aparición de `reference_snapshot not found`.
Fallo en la conexión iSCSI: `No portal available`	DSIP incorrecto o inaccesible, o el IQN del host FD no está autorizado en la lista de permitidos del VG del clúster	Fijar DSIP: `dsip=192.168.x.y`. Agregar el IQN del FD a la lista de permitidos del volume-group del clúster vía Prism o CHAP.
`qemu-img: command not found` durante restauración F5/F6	`qemu-img` no está instalado o no está en el PATH del usuario `bacula`	`dnf install qemu-img` (RHEL) o `apt install qemu-utils` (Ubuntu). Verificar con `sudo -u bacula which qemu-img`.
Receptor de DR en bucle de reinicio	Incompatibilidad de `dr_auth_token` entre las configuraciones SOURCE y RECEIVER; `state_dir` sin permisos de escritura; colisión de puerto	Confirmar que los tokens coincidan. Verificar `chmod 750 /opt/bacula/working/nutanix-repl/`. Ejecutar `ss -tlnp \| grep 9848` para detectar conflictos de puerto.
Receptor multi-instancia: estado cruzado entre VMs	Dos instancias de plantilla compartiendo el mismo `state_dir`	Cada configuración por VM debe tener un `state_dir` distinto, por ejemplo `/opt/bacula/working/nutanix-repl/vm-prod-01/`
Clon de failover-test no eliminado	`failover-undo` no ejecutado después de la prueba de DR	Ejecutar job con `mode=failover-undo` para liberar el clon de VLAN aislada y el espacio en disco del state-dir
`TLS handshake failed` en la conexión a Prism	Clúster Nutanix CE o interno usando certificado autofirmado	Solo para laboratorio/interno: agregar `prism_insecure=yes` a la configuración. Para producción: instalar un certificado válido en Prism Central.
Backend sale con código 2 en el inicio	Verbo `--standalone` desconocido o parámetros Plugin= malformados	Verificar la sintaxis de la línea Plugin= en la sección 7. Ejecutar con `verbose=3` para ver el análisis completo de parámetros.

14.3 Referencia de estado de failover

Modo	VM en el origen	VM en el receptor	Estado del receptor
`failover-test`	Sin cambios	Inicia en VLAN aislada	Sin cambios
`failover-planned`	Detenida + apagada	Encendida	Promovido; el receptor se convierte en fuente de verdad
`failover-unplanned`	Inaccesible	Encendida	Promovido; el receptor se convierte en fuente de verdad
`failover-undo`	Sin cambios	Clon de prueba eliminado	Sin cambios
`failover-perm`	(limpieza manual requerida)	Promovida	Se convierte en nuevo SOURCE — re-emparejar para invertir

15. Casos de uso y escenarios de implementación

15.1 Backup diario de VMs Nutanix de producción

Una organización con 50 VMs de producción en un clúster Nutanix AHV requiere backups Full diarios los fines de semana y backups Incrementales nocturnos de lunes a viernes, con retención de 30 días. El plugin PodHeitor se instala en un host Bacula FD dedicado con conectividad 10 GbE al DSIP de Prism. Un único FileSet con vm=prod-* y concurrent_vms=4 dirige todo el programa de backup. El Bacula Director ejecuta los Jobs en horarios programados; las tasas de cambio incremental del 5 al 10% diario hacen que los backups Full del fin de semana sean los únicos jobs con crecimiento significativo de almacenamiento. Las pruebas de restauración se realizan mensualmente usando un Job con mode=restore contra un clúster de pruebas aislado.

15.2 Recuperación ante desastres con replicación continua

Una empresa de servicios financieros requiere un RPO inferior a 5 minutos para sus 10 VMs de base de datos Tier-1. La pila de replicación de DR se implementa con unidades de plantilla systemd por VM en un host receptor en el sitio de DR (300 km de distancia, conectado vía MPLS de 100 Mbit/s). Cada VM ejecuta un receptor independiente con su propio state_dir, dr_port y PSK. La configuración push_interval=300 activa ciclos de bitmap-push cada 5 minutos. Los simulacros mensuales de failover-test confirman la capacidad de recuperación sin interrumpir la producción.

15.3 Migración de VMware vSphere a Nutanix AHV

Una empresa que migra de un entorno VMware vSphere a Nutanix AHV utiliza el plugin PodHeitor VMware hermano para respaldar las VMs de vSphere, y luego usa la ruta cross_restore=yes (F6 INBOUND) del plugin Nutanix para restaurar imágenes de disco convertidas en el clúster AHV de destino. Las sustituciones --vcpu y --memory-mib permiten redimensionar las VMs durante la migración sin modificar el origen. Esto elimina la necesidad de una herramienta de migración dedicada y mantiene todo el flujo de trabajo dentro de la infraestructura Bacula existente.

15.4 Entorno Nutanix multi-clúster

Un proveedor de servicios administrados opera tres clústeres Nutanix bajo un único Prism Central. Utilizan un único nutanix.conf con prism_central= apuntando al PC, y FileSets separados por clúster usando el parámetro cluster= para delimitar cada job al clúster correcto. Los escenarios de restauración entre clústeres (restaurar una VM del clúster A al clúster B) usan target_cluster= en el Job de restauración. El verbo health-check se ejecuta mediante un playbook de Ansible como parte de las comprobaciones semanales de infraestructura.

15.5 Entorno air-gapped con almacenamiento Bacula en cinta

Una agencia gubernamental opera un entorno Nutanix air-gapped. Todos los backups fluyen a través de una infraestructura Bacula con almacenamiento en cinta LTO. El plugin PodHeitor transmite los datos de disco de las VMs directamente hacia el pool de cintas de Bacula — sin necesidad de almacenamiento provisional en disco intermedio. El parámetro max_bandwidth_mbps= se usa para limitar el tráfico de backup y evitar saturar la red interna durante el horario laboral. Las restauraciones requieren el montaje manual de la cinta, que el operador inicia mediante bconsole restore; el plugin gestiona la reconstrucción completa en el disco scratch del host FD antes de subir la imagen a AHV.

16. Comparación con otros enfoques

Capacidad	Plugin PodHeitor Nutanix	Bacula Enterprise (Nutanix)	Veeam Data Platform	Commvault Complete	NetBackup
Motor de backup	PodHeitor Backup+	Bacula Enterprise 15.x	Veeam B&R	Commvault	Veritas NetBackup
Incrementales basados en CBT	Sí	Sí	Sí	Sí	Sí
Streaming a nivel de bloque vía iSCSI	Sí	Sí	Sí (HotAdd/NBD)	Sí	Sí
Integración nativa con API Prism	Sí (v3 + v4)	Sí	Parcial	Parcial	Parcial
Restauración entre clústeres	Sí (F5)	Sí	Sí	Sí	Sí
Restauración entre proveedores (qemu-img)	Sí (F6 — Proxmox, vSphere, Hyper-V)	Limitado	No	No	No
Replicación de DR incorporada	Sí (PSK-TCP, seed + delta + failover)	Sí	Sí (jobs de replicación)	Sí	Sí
Orquestación de failover	Sí (4 modos)	Sí	Sí (SureBackup)	Sí	Limitado
Prism Central multi-clúster	Sí	Sí	Sí	Sí	Sí
Instant Recovery (F9)	Hoja de ruta (plugin separado)	Sí	Sí	Sí	Sí
Restauración granular a nivel de archivo (F10)	Hoja de ruta (plugin separado)	Sí	Sí	Sí	Sí
Motor de backup de código abierto	Sí (PodHeitor Backup)	No (propietario)	No	No	No
Costo de licencia anual típico	Fracción de las alternativas*	~US$ 10.000+/año	~US$ 5.000+/año	~US$ 10.000+/año	~US$ 10.000+/año
Modelo de licencia del plugin	Propietario	Propietario	Propietario	Propietario	Propietario
Lenguaje del plugin	Rust (memory-safe, sin GC)	—	—	—	—

* Contacte a PodHeitor International para conocer los precios actuales. La afirmación de 50% de ahorro se basa en una comparación con los precios de lista publicados para conjuntos de funcionalidades comparables.

Nota sobre Bacula Enterprise: Bacula Enterprise es una alternativa válida y madura con un conjunto de funcionalidades más amplio (incluidos Instant Recovery y restauración granular en un único producto). El plugin PodHeitor está posicionado como una alternativa rentable para organizaciones que ya han invertido en infraestructura PodHeitor Backup y desean una integración Nutanix AHV de nivel de producción sin el compromiso completo de licenciamiento de Bacula Enterprise. Las dos soluciones atienden diferentes perfiles de presupuesto y complejidad y no son competidores directos.

17. Hoja de ruta

17.1 v2.x — Estabilidad y ecosistema (H2 2026)

F7 — Cross-restore OUTBOUND: Habilitar que las VMs Nutanix AHV sean restauradas en otros hypervisores (Proxmox VE, VMware vSphere, Hyper-V) a través de la ruta de exportación, complementando la ruta F6 INBOUND existente.
F3.5 / F3.6 — Estabilización del CRT v4: La captura DRP por disco está source-complete; validación E2E en vivo en un clúster solo v4 para confirmar la cobertura del analizador contra todos los formatos de respuesta GA del AOS 7.x.
F4.5 — Carga en Image Service y creación de VM: Completar la ruta de restauración F4 conectando la reconstrucción de disco a la carga en Prism Image Service y la materialización completa de VM desde la imagen reconstruida.
Build ARM64: Objetivo de compilación cruzada para aarch64 Linux para soportar organizaciones que ejecutan Bacula FD en infraestructura basada en Arm.
Endpoint exportador de Prometheus: Exponer un endpoint HTTP /metrics en un puerto configurable para scraping nativo de Prometheus sin necesidad de análisis de registros.

17.2 v3.x — Recuperación avanzada (H1 2027)

F9 — Instant Recovery (arranque vía iSCSI-target): Esta funcionalidad es gestionada deliberadamente por el plugin paralelo PodHeitor Bacula-SD de restauración granular + IR, que sirve a todos los backends de estilo VM desde una única implementación. El plugin Nutanix AHV se integrará con él cuando el plugin SD alcance GA.
F10 — Restauración granular a nivel de archivo: Mismo alcance que F9 — proporcionado por el plugin Bacula-SD de restauración granular, que monta discos de VM reconstruidos y expone archivos individuales a través del navegador de restauración de Bacula.
Modo multi-tenant: Ámbitos RBAC dedicados por tenant dentro de un Prism Central compartido, habilitando implementaciones de proveedores de servicios administrados con aislamiento estricto de datos.
Soporte de destino cloud-native: Replicación de DR directa hacia almacenamiento de objetos compatible con S3 como alternativa a un host receptor dedicado.

17.3 Continuo

Seguimiento de versiones de Nutanix AOS y la API de Prism Central; actualizaciones del analizador para cualquier cambio de esquema de respuesta en los endpoints v4
Pruebas de regresión continuas contra el entorno de laboratorio Nutanix Community Edition
Optimizaciones de rendimiento para VMs muy grandes (> 4 TiB en un único disco) y VMs con muchos discos (> 16 discos)

18. Conclusión

El Plugin de Backup Nutanix AHV PodHeitor para Bacula representa un avance significativo para el ecosistema de backup de código abierto. Pone al alcance de cualquier organización que ejecute PodHeitor Backup Edition la protección Nutanix AHV de nivel de producción — incluyendo incrementales basados en CBT, soporte multi-clúster, restauración entre proveedores y una pila completa de replicación de DR y failover — sin requerir una migración completa a una plataforma de backup comercial ni el licenciamiento de Bacula Enterprise.

La arquitectura del plugin — Rust puro en ambos lados del límite del metaplugin, limpieza de recursos RAII-safe, aislamiento de subproceso del backend y una disciplina de ingeniería por fases con más de 50 pruebas automatizadas — lo convierte en una base confiable para flujos de trabajo de backup de misión crítica. El verbo standalone health-check, las plantillas systemd de DR por VM y el registro estructurado del backend brindan a los equipos de operaciones la visibilidad y el control necesarios para mantener una postura de backup defendible.

Para organizaciones que enfrentan renovaciones de plataformas de backup comerciales — especialmente aquellas que evalúan Veeam, Commvault o NetBackup para Nutanix AHV — el plugin PodHeitor ofrece una alternativa comparativa con un ahorro del 50% o más, con un conjunto de funcionalidades adaptado específicamente a la plataforma Nutanix en lugar de superpuesto a una capa de abstracción de hypervisor genérica.

Le invitamos a evaluar el plugin en su entorno. Comience con el health-check standalone, ejecute un job de backup de prueba y compare la precisión de la restauración y la simplicidad operativa con su solución actual. Para una cotización comercial por escrito, una comparación de funcionalidades con su entorno específico o un contrato de servicios profesionales (instalación, configuración, puesta en marcha en producción), contáctese directamente con Heitor Faria en los datos que figuran a continuación.

Oferta especial. Presente su propuesta de renovación de cualquier plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup u otras. Elaboraremos una propuesta comparativa con el objetivo de al menos 50% de ahorro y funcionalidad superior específica para Nutanix AHV. Contáctenos en heitor@opentechs.lat para recibir una cotización por escrito.

Licenciamiento

El Plugin de Backup Nutanix AHV PodHeitor se distribuye bajo licencia comercial propietaria. Cada contrato incluye:

Licencia de uso en producción para el número acordado de hosts Bacula FD
Acceso a todas las actualizaciones de la versión principal contratada
Soporte técnico por correo con tiempo de respuesta garantizado
Servicios profesionales opcionales: instalación, integración con el entorno Bacula existente, pruebas de DR y capacitación del equipo de operaciones

Para organizaciones que migran desde Veeam, Commvault, NetBackup u otras plataformas comerciales, ofrecemos una propuesta comparativa documentada con meta de al menos 50 % de ahorro sobre el precio de lista de la plataforma actual.

¿Listo para evaluar?

Contáctenos para iniciar una prueba de concepto en su entorno:

WhatsApp / Teléfono: +1 786 726-1749
Correo: heitor@opentechs.lat
Consulta gratuita: https://podheitor.com/consultoria-gratis/?lang=es

19. Información de contacto

Canal	Detalles
Nombre	Heitor Faria — PodHeitor International
Sitio web	https://podheitor.com
Correo	heitor@opentechs.lat
Teléfono / WhatsApp (Internacional)	+1 786 726-1749
Teléfono / WhatsApp (Brasil)	+55 61 98268-4220
Documentación del plugin	https://podheitor.com/plugins/nutanix-ahv
Soporte	Correo con asunto: PodHeitor Nutanix Plugin Support

Para contratos empresariales, Heitor Faria ofrece servicios profesionales que incluyen instalación, integración con Directors de Bacula existentes, diseño de runbook de DR y soporte para la puesta en marcha en producción. Hay disponibles contratos de soporte por retainer y por incidente.

20. Legal / derechos de autor

El Plugin de Backup Nutanix AHV PodHeitor para Bacula es single-licensed bajo LicenseRef-PodHeitor-Proprietary. La licencia proprietaria rige todo uso comercial y la redistribución. Contáctese en heitor@opentechs.lat para conocer los términos de licenciamiento comercial.

Marcas registradas: PodHeitor y el logotipo de PodHeitor son marcas comerciales de Heitor Faria / PodHeitor International. Nutanix, AHV, Prism, Prism Central, Prism Element, AOS y Nutanix Community Edition son marcas registradas o marcas comerciales de Nutanix, Inc. Bacula y Bacula Enterprise son marcas comerciales de Bacula Systems SA. Veeam es marca comercial de Veeam Software AG. Commvault es marca comercial de Commvault Systems, Inc. NetBackup y Veritas son marcas comerciales de Veritas Technologies LLC. VMware y vSphere son marcas comerciales de VMware, Inc. (una empresa de Broadcom). Proxmox VE es marca registrada de Proxmox Server Solutions GmbH. Microsoft e Hyper-V son marcas comerciales de Microsoft Corporation. Todas las demás marcas son propiedad de sus respectivos titulares.

Aviso legal: Este documento se proporciona con fines informativos. Las cifras de rendimiento y las comparaciones de costos se basan en pruebas de laboratorio y precios de lista disponibles públicamente al momento de la publicación, y pueden variar según el entorno, la configuración y los cambios de precios de los proveedores. PodHeitor International no ofrece ninguna garantía, expresa ni implícita, respecto a la precisión de la información de productos de terceros contenida en este documento.

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