Blog

Whitepaper técnico — PodHeitor Nutanix AHV para Bacula

Whitepaper técnico — PodHeitor Nutanix AHV para Bacula

Whitepaper Técnico — Versão 2.0.0 — Maio de 2026

Autor: Heitor Faria · Website: https://podheitor.com · E-mail: heitor@opentechs.lat · Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Oferta especial. Traga sua proposta de renovação de qualquer plataforma comercial de backup corporativo — Veeam, Commvault, NetBackup ou outras. Elaboraremos uma proposta comparativa com meta de pelo menos 50% de economia e funcionalidade superior específica para Nutanix AHV. Entre em contato pelo e-mail heitor@opentechs.lat para receber um orçamento por escrito.

Sumário

  1. Resumo executivo
  2. Introdução e contexto de mercado
  3. Visão geral da arquitetura
  4. Análise detalhada dos modos de backup
  5. Matriz de funcionalidades
  6. Guia de instalação
  7. Referência de configuração
  8. Exemplos de FileSet
  9. Dimensionamento e planejamento de capacidade
  10. Relatório de desempenho
  11. Matriz de compatibilidade
  12. Segurança
  13. Monitoramento
  14. Guia de solução de problemas
  15. Casos de uso e cenários de implantação
  16. Comparação com outras abordagens
  17. Roadmap
  18. Conclusão
  19. Informações de contato
  20. Legal / direitos autorais

1. Resumo executivo

O Nutanix AHV emergiu como uma das plataformas de hypervisor com crescimento mais acelerado em data centers corporativos, com organizações do mundo inteiro migrando cargas de trabalho virtualizadas para a infraestrutura hiperconvergente Nutanix. Apesar dessa adoção rápida, o ecossistema de backup open source carecia de uma integração nativa de nível de produção capaz de aproveitar o mecanismo CBT (Changed Block Tracking) embutido do AHV, a API do Prism Central e os caminhos de dados em bloco via iSCSI. Os administradores eram obrigados a aceitar backups em nível de arquivo de VMs em execução, soluções proprietárias caras baseadas em agentes ou scripts sob medida em torno dos utilitários CLI do Nutanix — todos comprometendo garantias de recuperação, simplicidade operacional ou orçamento.

O Plugin de Backup Nutanix AHV PodHeitor para Bacula fecha completamente essa lacuna. Construído em Rust puro em ambos os lados da fronteira do metaplugin Bacula, ele oferece backup, restauração, replicação de DR entre clusters e orquestração de failover de classe empresarial para ambientes Nutanix AHV, usando apenas o Bacula Community Edition 15.0.3+ e uma conta de serviço Prism RBAC padrão. O plugin aproveita as APIs Nutanix v3 e v4 para gerenciamento do ciclo de vida de snapshots, conexão de Volume Group (VG) via iSCSI para streaming de blocos de alta taxa de transferência e um transporte TCP autenticado por PSK para replicação de DR contínua — tudo acionado pela configuração padrão de Job e FileSet do Bacula, sem scripts externos, sem cron, e sem agentes de backup específicos do fornecedor executando dentro de VMs convidadas.

Do ponto de vista de profundidade técnica, esta é a integração de backup Nutanix AHV open source mais completa disponível hoje. Ela oferece backups Full e Incremental via snapshots CBT do Nutanix, restauração byte-a-byte no mesmo cluster e em clusters alternativos, restauração INBOUND entre fornecedores via conversão qemu-img (habilitando Proxmox VE, VMware vSphere e Hyper-V como destinos de restauração), e uma pilha completa de replicação de DR com seed, delta por bitmap, limitação de largura de banda, reconexão durante o push e quatro modos de failover. Um verbo standalone health-check valida o alcance do Prism, a postura RBAC e o roteamento DSIP antes que o primeiro job seja executado.

Do ponto de vista comercial, o plugin oferece todas essas capacidades a uma fração do custo das alternativas corporativas. O Veeam Data Platform para Nutanix começa em aproximadamente US$ 5.000/ano para implantações pequenas. As licenças Commvault e NetBackup frequentemente ultrapassam US$ 10.000/ano. O plugin PodHeitor oferece um conjunto de funcionalidades comparável — e em algumas dimensões, superior — para ambientes Nutanix AHV com economia de 50% ou mais. Para qualquer organização que executa Nutanix AHV com Bacula Community, este plugin é o caminho mais econômico para uma postura de backup e DR defensável em nível de produção.

2. Introdução e contexto de mercado

2.1 Nutanix AHV em produção corporativa hoje

O Nutanix AHV (Acropolis Hypervisor) cresceu de um hypervisor integrado na pilha hiperconvergente Nutanix para uma plataforma de virtualização corporativa de primeira classe. De acordo com os próprios dados de mercado da Nutanix, o AHV agora responde pela maioria das novas cargas de trabalho implantadas em clusters Nutanix, com organizações de serviços financeiros, saúde, governo, educação e manufatura escolhendo o AHV em vez do VMware vSphere — especialmente após a aquisição da VMware pela Broadcom e as subsequentes mudanças de licenciamento que levaram muitos clientes a buscar alternativas.

As principais características técnicas do AHV que o tornam atraente para operadores corporativos incluem:

  • Arquitetura hiperconvergente que elimina infraestrutura dedicada de SAN/NAS
  • CBT (Changed Block Tracking) nativo por meio de snapshots Prism para operações incrementais eficientes
  • API de gerenciamento multi-cluster do Prism Central (v3 e v4) oferecendo controle programático sobre o ciclo de vida das VMs
  • Exportação de blocos de Volume Group (VG) via iSCSI para acesso a dados fora da banda sem interação com os convidados
  • AOS (Acropolis Object Store) com armazenamento distribuído que oferece latência sub-milissegundo em escala
  • Recursos nativos de replicação de dados e snapshots habilitando fluxos de trabalho de DR nativos

2.2 Por que fazer backup de VMs AHV é desafiador

Apesar da rica superfície de API do AHV, proteger cargas de trabalho AHV com ferramentas de backup open source permaneceu difícil por vários motivos:

  • Complexidade da API. O Nutanix opera duas gerações paralelas de API (v3 e v4), cada uma com formatos de endpoint, modelos de autenticação e padrões de paginação diferentes. Ferramentas que funcionam com v3 podem falhar silenciosamente em clusters v4, e vice-versa.
  • Ciclo de vida de conexão iSCSI. Acessar dados de disco de VM em nível de bloco requer criar um Volume Group, clonar o disco do snapshot nele, conectar via iSCSI ao host de backup, transmitir os dados e depois limpar todos os recursos — inclusive em caso de pânico ou interrupção do job. Uma limpeza perdida deixa VGs e snapshots órfãos no cluster.
  • Gerenciamento de estado CBT. Incrementais eficientes requerem rastreamento de referências de snapshot por disco entre jobs, tratamento de invalidação de referências quando políticas de retenção deletam snapshots anteriores e gerenciamento de redimensionamentos de disco que invalidam a cadeia de delta.
  • Restauração entre clusters e entre fornecedores. A restauração em um cluster alternativo requer upload da imagem para um cluster Nutanix diferente, e a restauração entre fornecedores (para Proxmox VE, VMware vSphere ou Hyper-V) requer conversão qemu-img de imagens de disco brutas para o formato de destino.
  • Replicação de DR. Replicação de DR contínua com limitação de largura de banda, reconexão durante o push e orquestração de failover é um sistema multi-componente que a maioria das ferramentas open source não aborda de forma alguma.

2.3 A lacuna no ecossistema open source

Ferramenta Suporte a AHV Veredicto
Bacula Community (nativo, sem plugin) Somente nível de arquivo — faz backup dos arquivos de disco virtual brutos da VM pelo sistema de arquivos do host Inseguro — sem consistência de crash, sem CBT, sem integração com catálogo
Bareos Sem integração nativa com AHV Somente nível de arquivo; mesmos riscos que o Bacula nativo
Amanda Sem integração nativa com AHV Somente nível de arquivo
Nutanix Mine Nativo, mas requer hardware separado de cluster Mine Alto custo adicional; sem integração com Bacula
Scripts shell personalizados via API Prism + acli Parcial — sem catálogo, sem retry, sem monitoramento Não adequado para produção

A lacuna é estrutural: nenhuma solução compatível com open source integrada ao Nutanix AHV em nível de API — com snapshots CBT, streaming de blocos via iSCSI, suporte multi-cluster e replicação de DR — até agora.

2.4 A abordagem PodHeitor

O plugin segue a mesma filosofia de design da família de plugins PodHeitor: Rust puro em ambos os lados da fronteira do metaplugin para segurança de memória e zero dependências de runtime, desenvolvimento em fases com testes de regressão automatizados, limpeza de recursos baseada em RAII que é segura contra pânico (sem snapshots ou Volume Groups órfãos), e uma arquitetura de protocolo PTCOMM que isola toda a interação com a API Nutanix em um subprocesso para que falhas do backend não possam corromper o processo Bacula FD.

3. Visão geral da arquitetura

3.1 Design de dois componentes

O plugin fornece dois binários em um único pacote:

Componente Arquivo Função
Plugin Bacula FD (cdylib) /opt/bacula/plugins/podheitor-nutanix-fd.so Carregado pelo bacula-fd em runtime; implementa a API de plugin do Bacula; mínimo e estável
Binário de backend /opt/bacula/bin/podheitor-nutanix-backend Criado por fork por job pela cdylib; executa toda a interação com a API Nutanix, operações iSCSI e transporte de DR

Essa divisão oferece três vantagens críticas:

  1. Isolamento. A cdylib é uma cdylib Rust mínima sem código-fonte AGPLv3 do Bacula vinculado estaticamente — limpa sob direitos autorais. Todas as chamadas à API Prism, anexação/desanexação iSCSI e transporte de DR residem no backend. Uma falha ou travamento do backend não pode corromper o processo Bacula FD.
  2. Atualizabilidade. O binário de backend pode ser atualizado sem reiniciar o bacula-fd. Apenas a cdylib toca o ABI do plugin Bacula.
  3. Testabilidade. O backend pode ser exercitado diretamente (--standalone health-check) sem envolver o Bacula, e todos os testes unitários são executados contra o binário do backend em isolamento.

3.2 Protocolo PTCOMM

A cdylib e o backend se comunicam pelo canal stdin/stdout do subprocesso usando o PTCOMM (PodHeitor Transport Communications), um protocolo de enquadramento binário com tag de comprimento compartilhado em toda a família de plugins PodHeitor:

┌────────────────────────────────────────────────────────┐
│  PTCOMM Frame (8-byte header + payload)                │
│                                                        │
│  Offset  Size  Field                                   │
│  ──────  ────  ─────                                   │
│  0       4     Magic  (0x50544300)                     │
│  4       4     Payload length (u32, big-endian)        │
│  8       N     Payload (JSON command or binary data)   │
└────────────────────────────────────────────────────────┘

Packet types (direction cdylib ↔ backend):
  I-packet  — Info/log line (backend → cdylib → Bacula job log)
  E-packet  — Error message  (backend → cdylib)
  D-packet  — Data chunk     (bidirectional, for backup/restore streams)
  C-packet  — Control / command + parameters (cdylib → backend)
  OK-ack    — Metaplugin acknowledgement (backend → cdylib, after createFile-EOD
              and after data-stream-EOD, per Bacula metaplugin protocol)

A máquina de estados no backend processa o fluxo PTCOMM por estados bem definidos: Handshake → JobInfo → Despacho de modo (Backup / Restauração / DR) → Streaming de dados → Limpeza → Saída. Cada transição de estado é registrada em verbose=2.

3.3 Diagrama de arquitetura

  ┌───────────────────────────────────────────────────────────────────┐
  │  Bacula File Daemon (bacula-fd)                                    │
  │                                                                   │
  │   ┌───────────────────────────────────────────────────────────┐   │
  │   │  podheitor-nutanix-fd.so  (cdylib — pure Rust, ~50 LOC)   │   │
  │   │                                                           │   │
  │   │  bEventJobStart ──► fork backend ──► write job params     │   │
  │   │  bEventBackupCommand ──► send C-packet (mode=backup)      │   │
  │   │  bEventGetMoreData ◄── receive D-packets (disk stream)    │   │
  │   │  bEventRestoreCommand ──► send C-packet (mode=restore)    │   │
  │   │  bEventSetFileAttributes ◄── write reconstructed disk     │   │
  │   └──────────────────────────┬────────────────────────────────┘   │
  │                              │ stdin/stdout (PTCOMM frames)        │
  │   ┌──────────────────────────▼────────────────────────────────┐   │
  │   │  podheitor-nutanix-backend  (subprocess — Rust binary)     │   │
  │   │                                                           │   │
  │   │  ┌────────────────┐  ┌─────────────────┐  ┌──────────┐   │   │
  │   │  │ Backup (F2/F3) │  │ Restore (F4/F5) │  │  DR (F8) │   │   │
  │   │  │ Full + CBT Inc │  │ Same / alt-clust│  │ Repl+F/O │   │   │
  │   │  └───────┬────────┘  └────────┬────────┘  └────┬─────┘   │   │
  │   │          │                    │                 │          │   │
  │   │  ┌───────▼────────────────────▼─────────────────▼──────┐  │   │
  │   │  │  Prism Module (v3 / v4 auto-detect)                  │  │   │
  │   │  │  auth.rs · cluster.rs · vms.rs · snapshots.rs        │  │   │
  │   │  │  volume_groups.rs · crt.rs · rate_limiter.rs         │  │   │
  │   │  └─────────────────────┬────────────────────────────────┘  │   │
  │   │                        │ HTTPS (Prism Central 9440)         │   │
  │   │  ┌─────────────────────▼────────────────────────────────┐  │   │
  │   │  │  iSCSI Layer (iscsi.rs + disk_reader.rs)              │  │   │
  │   │  │  VG attach → O_DIRECT read → PHCBT01 stream          │  │   │
  │   │  └──────────────────────────────────────────────────────┘  │   │
  │   │                                                           │   │
  │   │  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

Os backups incrementais são transmitidos no formato PHCBT01 — o formato de stream de delta binário do PodHeitor compartilhado entre todos os plugins de estilo VM (Proxmox, VMware, Nutanix). O PHCBT01 codifica apenas as regiões ALTERADAS da resposta CBT, com um sidecar ZeroMap para tratamento eficiente de regiões esparsas. Esse formato é o que permite a reconstrução byte-a-byte da cadeia na restauração sem reler blocos inalterados do armazenamento.

3.5 Gerenciamento de estado

O estado de referência CBT é armazenado por disco em /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

O estado é gravado atomicamente (escrita-renomeação) de modo que uma falha entre o desarmamento do snapshot e a limpeza da referência anterior deixa no máximo um snapshot vazado, recuperável pelo operador via acli snapshot.list. Uma varredura de referências obsoletas é executada na inicialização do backend (job_cleanup_on_abort=yes) para recuperar sessões iSCSI e VGs órfãos de qualquer saída anormal anterior.

4. Análise detalhada dos modos de backup

4.1 Backup Full (F2)

Como funciona

Um backup Full cria um snapshot consistente com a aplicação (ou consistente com crash, conforme application_consistent=) do Nutanix v3/v4 da(s) VM(s) alvo, depois para cada disco virtual: cria um Volume Group (VG) no cluster, clona o disco do snapshot no VG, conecta o VG ao host FD via iSCSI, lê o dispositivo de bloco bruto usando O_DIRECT (chunks de 1 MiB, alinhados a 4 KiB), transmite ao Bacula como um arquivo virtual @nutanix/<vm>/disks/disk-<N>.raw e então limpa o VG e o snapshot em ordem reversa estrita via cadeias RAII Drop.

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

Concorrência

Múltiplas VMs e múltiplos discos por VM são processados concorrentemente. concurrent_vms=2 controla o número de VMs sendo pré-preparadas simultaneamente; concurrent_disks=4 controla leituras paralelas de disco por VM. O backend usa crossbeam-channel do Rust para filas produtor/consumidor limitadas entre o leitor iSCSI e o emissor PTCOMM.

Prós e contras

Aspecto Avaliação
Cobertura Excelente — imagem completa do disco da VM capturada
Consistência Excelente — snapshot Nutanix é consistente com crash ou com aplicação
Velocidade Boa — streaming de blocos via iSCSI; O_DIRECT ignora o cache de página
Simplicidade de restauração Excelente — stream único, sem dependências de cadeia
Largura de banda Alta — tamanho total do disco; combine com max_bandwidth_mbps se necessário
Dependência de cadeia Nenhuma — autocontido

4.2 Backup Incremental via CBT (F3)

Como funciona

Após um backup Full, os jobs subsequentes em Level=Incremental usam a API CRT (Changed Regions Tracking) do Nutanix para consultar apenas as regiões do disco que mudaram desde o snapshot de referência. O backend busca a lista de regiões alteradas, une runs ALTERADOS adjacentes, divide-os nos limites de chunk e emite um stream codificado em PHCBT01 contendo apenas os dados modificados. O snapshot de referência anterior é preservado até que o novo snapshot seja confirmado, depois atomicamente promovido como a nova referência.

  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

Internos do stream PHCBT01

  • Cabeçalho: 20 bytes — magic PHCBT01, tamanho do disco, contagem de regiões
  • Registros CHANGED: 12 bytes cada — offset, comprimento, seguido pelo payload da região
  • Sidecar ZeroMap: mapa esparso de regiões ZERO omitidas do stream (eficiente em espaço)
  • Pré-computação de tamanho: o codificador pré-soma o tamanho STAT declarado para que o catálogo do Bacula receba um tamanho de arquivo preciso antes que o streaming comece

Prós e contras

Aspecto Avaliação
Cobertura Excelente — captura todos os blocos alterados desde o snapshot de referência
Velocidade Excelente — tipicamente 5 a 10× menor que o Full para VMs ativas
Restauração Boa — requer reconstrução de cadeia (Full + N Incrementais)
Dependência de cadeia Obrigatória — o snapshot de referência não deve ser deletado externamente
Versão de API v3 (primária) + v4 (suporte completo a partir de F3.5 — CRT baseado em DRP)

4.3 Replicação de DR (F8)

Como funciona

A replicação de DR opera em duas fases: um push inicial de seed e ciclos recorrentes de delta por bitmap. O lado SOURCE executa mode=seed para enviar a imagem completa do disco ao receptor de DR via TCP autenticado por PSK na porta 9848 (configurável). Os ciclos subsequentes de mode=bitmap-push enviam apenas os blocos alterados identificados pelo CBT como um bitmap delta compacto. O receptor armazena seeds e bitmaps em seu próprio state_dir e pode reconstruir a imagem completa em qualquer limite 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)

Quatro modos de failover cobrem o ciclo de vida completo do DR:

  • failover-test — Inicializa um clone em uma VLAN isolada; estado do receptor inalterado. Use para testes de DR regulares sem afetar a produção.
  • failover-planned — Quiesce a VM de origem, promove o receptor, liga a cópia de DR. Use para failovers de manutenção planejada.
  • failover-unplanned — Promove o receptor sem quiesce da origem. Use quando o cluster de origem está inacessível.
  • failover-undo — Desfaz um clone de failover-test e libera espaço em disco do state-dir.
  • failover-perm — Cutover final; o receptor torna-se a nova fonte de verdade. Re-pareie para inverter a direção.

4.4 Restauração INBOUND entre fornecedores (F6)

O flag cross_restore=yes habilita a restauração de um backup Nutanix AHV para um hypervisor que não seja AHV. O backend converte a imagem de disco bruta para o formato de destino usando qemu-img convert e a envia ao serviço de imagem da plataforma de destino. Os destinos suportados incluem Proxmox VE (qcow2), VMware vSphere (vmdk) e Microsoft Hyper-V (vhd/vhdx). Isso é particularmente valioso para recuperação de desastres em um hypervisor diferente ou para testes de migração.

5. Matriz de funcionalidades

Funcionalidade Suporte Observações
Backup Full (F2) Sim Streaming de blocos via iSCSI + limpeza RAII
Backup Incremental via CBT (F3) Sim Stream delta PHCBT01; CRT v3 + v4
Concorrência multi-VM Sim concurrent_vms= (padrão 2)
Concorrência multi-disco por VM Sim concurrent_disks= (padrão 4)
Seleção de VM por glob/padrão Sim vm=prod-*, CSV, UUID
Padrões de exclusão de VM Sim exclude=temp-*
Snapshot consistente com aplicação Sim application_consistent=true|try|false
Restauração no mesmo cluster (F4) Sim Criação nativa de VM AHV
Restauração em cluster alternativo (F5) Sim Upload de imagem + materialização de VM no cluster de destino
Restauração INBOUND entre fornecedores (F6) Sim qemu-img para Proxmox/vSphere/Hyper-V
Substituição de vCPU/memória entre clusters Sim --vcpu / --memory-mib na restauração
Remapeamento de rede na restauração Sim network_map=src=dst,...
Restauração seletiva de disco Sim restore_disks_only=disk-0,disk-2
Ligar após restauração Sim power_on=yes
Seed de replicação de DR (F8.1) Sim Push de disco completo via PSK-TCP
Delta bitmap-push de DR (F8.2) Sim Push de delta derivado de CBT com reconexão
Limitação de largura de banda Sim Token-bucket em max_bandwidth_mbps=
Reconexão durante push Sim Retoma a partir do último limite de ciclo confirmado
Failover-test (drill) Sim Clone em VLAN isolada; estado inalterado
Failover-planned Sim Quiesce + promoção + ligar destino
Failover-unplanned Sim Promover sem quiesce da origem
Failover-undo Sim Desfazer clone de teste
Failover-perm (cutover) Sim Receptor torna-se nova fonte de verdade
Receptor de DR multi-instância Sim Template systemd; isolamento de estado por VM
API Prism v3 Sim Caminho primário
API Prism v4 Sim Detectada automaticamente; faz fallback para v3
Prism Central multi-cluster Sim Nome ou UUID do cluster em cluster=
Verificação TLS Sim Seguro por padrão; prism_insecure=yes apenas para laboratório
mTLS para canal de DR Sim dr_auth_cert / dr_auth_key / dr_ca_cert
Health-check standalone Sim Probes de RBAC + DSIP pré-voo
Estimativa de tamanho em modo dry-run Sim mode=estimate
Instant Recovery (F9) Roadmap Plugin Bacula-SD separado (restauração granular + IR)
Restauração granular em nível de arquivo (F10) Roadmap Plugin Bacula-SD separado
Suporte ARM64 Roadmap Apenas x86_64 na v2.0.0

6. Guia de instalação

6.1 Pré-requisitos

  • Bacula Community Edition File Daemon 15.0.3+ em execução no Oracle Linux 9 / RHEL 9 / Ubuntu 22.04 / Ubuntu 24.04 (x86_64)
  • qemu-img disponível no PATH (necessário para restauração entre clusters F5 / F6 entre fornecedores)
  • iscsiadm (open-iscsi) acessível quando data_path=iscsi é usado (padrão)
  • Conectividade de rede do host FD ao Prism Central HTTPS (porta padrão 9440) e ao IP dos Serviços de Dados do cluster (DSIP) pela porta iSCSI 3260
  • Uma conta de serviço Prism RBAC com funções de Backup Admin, VM Admin e Cluster Admin (somente leitura) no escopo do cluster

6.2 Instalação do pacote

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 (qualquer x86_64 com glibc 2.34+)

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

Os três caminhos de instalação colocam os seguintes arquivos no sistema:

Caminho Conteúdo
/opt/bacula/plugins/podheitor-nutanix-fd.so Plugin FD carregado pelo bacula-fd
/opt/bacula/bin/podheitor-nutanix-backend Binário de backend
/opt/bacula/etc/nutanix.conf.example Template de configuração anotado
/opt/bacula/working/nutanix-repl/ Diretório de estado (referências CBT, seeds, bitmaps)
/lib/systemd/system/podheitor-nutanix-receiver.service Unidade systemd do receptor de DR (instância única)
/lib/systemd/system/podheitor-nutanix-receiver@.service Template systemd do receptor de DR (por VM)
/etc/logrotate.d/podheitor-nutanix Configuração de rotação de logs

6.3 Configuração 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

Chaves mínimas obrigatórias em nutanix.conf:

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

Coloque a senha do Prism em /opt/bacula/etc/nutanix.secrets (modo 0600, proprietário root:bacula):

password = your-prism-service-account-password

6.4 Validação pré-voo

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

O probe de health-check valida na ordem: (1) acessibilidade TLS do Prism Central, (2) autenticação RBAC, (3) enumeração de clusters, (4) confirmação de função RBAC, (5) descoberta de DSIP e probe da porta iSCSI 3260. Código de saída 0 significa que o host FD está pronto para executar jobs de backup.

6.5 Configuração do receptor de DR (opcional)

Para DR de instância única (um receptor protegendo todas as 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 isolamento por VM (recomendado em produção):

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. Referência de configuração

7.1 Parâmetros de conexão

Chave Tipo Padrão Descrição
prism_central host[:porta] — Hostname ou IP do Prism Central, acessível pelo host FD
prism_port int 9440 Porta HTTPS do Prism Central
prism_api_version auto|v3|v4 auto auto testa v4 primeiro; faz fallback para v3
user string — Usuário RBAC do Prism (deve existir no IAM, não apenas em pass-through LDAP)
password string — Senha inline; prefira passfile por segurança
passfile caminho — Caminho para arquivo contendo password = …; modo 0600
prism_insecure bool no Ignora verificação do certificado TLS; apenas para laboratório. Emite um AVISO em cada job.
cluster string — Nome ou UUID do cluster quando o Prism Central gerencia múltiplos clusters

7.2 Parâmetros de seleção de backup

Chave Tipo Padrão Descrição
vm csv/glob * UUID da VM, nome exato ou padrão glob (prod-*). Múltiplos valores separados por vírgula.
exclude csv/glob — Padrões de exclusão aplicados após a correspondência de vm=
application_consistent true|try|false try try: tenta snapshot consistente com aplicação, faz fallback graciosamente; true: falha o job se consistência com aplicação não estiver disponível

7.3 Parâmetros de caminho de dados

Chave Tipo Padrão Descrição
data_path auto|iscsi|rest auto Seleção de transporte. iscsi é recomendado para taxa de transferência.
dsip IPv4 detectado Substituição explícita do IP de Serviços de Dados. Defina em produção para evitar falhas de probe.
iscsi_initiator string auto Substituição de IQN iSCSI. Detectado automaticamente em /etc/iscsi/initiatorname.iscsi.
concurrent_vms int 2 Número máximo de VMs sendo pré-preparadas (snapshot + anexação de VG) simultaneamente
concurrent_disks int 4 Máximo de leituras de disco paralelas por VM
chunk_size_mib int 1 Tamanho do chunk de leitura iSCSI em MiB. Valores maiores melhoram a taxa de transferência sequencial; deve ser alinhado a 4 KiB.
prism_rate_rpm int 30 Limitador de taxa da API Prism no cliente (requisições por minuto)

7.4 Parâmetros de restauração (F4 / F5 / F6)

Chave Tipo Padrão Descrição
mode enum backup Veja a seção 7.6 para a lista completa de valores de modo
where caminho — Prefixo de restauração do Bacula; normalmente definido automaticamente pelo Director
restore_vm_name string <orig>-restored Nome da VM restaurada no cluster de destino
target_cluster string origem Nome ou UUID do cluster alternativo para restauração entre clusters F5
target_container string origem Container de armazenamento AHV no cluster de destino
network_map csv — Remapeamento de sub-rede de origem para destino: src=dst,src2=dst2
power_on bool no Liga a VM restaurada após a criação ser concluída
restore_disks_only csv — Restaura apenas os discos listados: disk-0,disk-2
--vcpu int origem Substitui a contagem de vCPU na restauração entre clusters para redimensionamento
--memory-mib int origem Substitui a memória (MiB) na restauração entre clusters para redimensionamento
cross_restore bool yes Aceita streams de hypervisores externos para restauração F6

7.5 Parâmetros de replicação de DR (F8)

Chave Tipo Padrão Descrição
dr_host host — Hostname ou IP do receptor de DR (definido no lado SOURCE)
dr_port int 9848 Porta TCP do receptor de DR
dr_auth_token string — Chave pré-compartilhada para autenticação HMAC-SHA256. Gere com: openssl rand -hex 32
dr_auth_cert caminho — Caminho do certificado cliente mTLS (opcional, para TLS mútuo)
dr_auth_key caminho — Caminho da chave cliente mTLS
dr_ca_cert caminho — Certificado CA para verificação TLS do receptor
dr_restore_points int 7 Número de pontos de recuperação de DR retidos no receptor
max_bandwidth_mbps int 0 Limite de largura de banda do transporte de DR em Mbit/s. 0 = ilimitado. Algoritmo de token-bucket.
push_interval int 300 Segundos entre ciclos de delta bitmap-push
push_apply_remote bool yes Aplicar deltas recebidos em write-through no receptor (recomendado)

7.6 Parâmetros de log e scratch

Chave Tipo Padrão Descrição
verbose 0–3 1 Verbosidade do log: 0=apenas erros, 1=normal, 2=debug, 3=trace (muito detalhado)
debug_log caminho /opt/bacula/working/podheitor-nutanix-backend.log Caminho do arquivo de log do backend
working_dir caminho /opt/bacula/working Raiz de scratch para arquivos temporários
state_dir caminho /opt/bacula/working/nutanix-repl Diretório de estado persistente (referências CBT, seeds, bitmaps)
job_cleanup_on_abort bool yes Varredura RAII de recursos obsoletos na inicialização do backend (sessões iSCSI, VGs, snapshots órfãos)

7.7 Valores de modo

Valor Fase Uso
backup F2/F3 Padrão — Full ou Incremental conforme o Level do Job Bacula
restore F4 Restauração nativa no mesmo cluster
estimate F2 Estimativa de tamanho em dry-run sem streaming de dados
receiver F8 Escuta frames SEED + DELTA no receptor de DR
seed F8 Envia seed inicial de disco completo ao receptor
bitmap-push F8 Envia bitmap de delta CBT ao receptor
failover-test F8.4 Inicializa clone em VLAN isolada; estado do receptor inalterado
failover-planned F8.4 Quiesce da origem → promoção do receptor → ligar destino
failover-unplanned F8.4 Promove receptor sem quiesce da origem (origem inacessível)
failover-undo F8.4 Desfaz clone de failover-test e libera espaço do state-dir
failover-perm F8.4 Cutover final; receptor torna-se a nova fonte de verdade

8. Exemplos de FileSet

8.1 Backup Full + incremental básico de todas as 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 Somente VMs de produção, consistentes com aplicação, com concorrência

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 Restauração em cluster alternativo (DR entre clusters)

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 Agenda de seed + bitmap-push para replicação de DR

# FileSet para push de seed de DR (executar uma vez para estabelecer o 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 recorrente (agendado a 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 Restauração INBOUND entre fornecedores para 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 Definições de Job Bacula correspondentes

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. Dimensionamento e planejamento de capacidade

9.1 Requisitos do host FD

Recurso Mínimo Recomendado Observações
CPU 4 cores 8+ cores Cada leitor de disco concorrente usa ~1 core; codificação PHCBT01 é single-threaded por disco
RAM 4 GB 8 GB Buffer de chunk de 1 MiB por disco × concurrent_disks; pré-soma PHCBT01 atinge pico de ~1 GiB para incrementais muito grandes
IOPS do disco de scratch 1.000 IOPS 5.000+ IOPS Usado para staging de restauração F5/F6 e armazenamento de seed de DR
Capacidade do disco de scratch 200 GB 2× maior disco de VM Para staging de reconstrução F4/F5 e imagens de seed de DR
Rede para Prism Central 100 Mbit/s 1 Gbit/s Streaming de blocos iSCSI é o gargalo — 10 GbE ou bond recomendado para VMs grandes
Rede para receptor de DR 10 Mbit/s 100+ Mbit/s Bitmap-push de DR pode ser limitado com max_bandwidth_mbps=

9.2 Dimensionamento de armazenamento para volumes Bacula

O planejamento de capacidade depende muito dos tamanhos dos discos das VMs, das taxas de alteração e da política de retenção. Como orientação geral:

  • Tamanho do backup Full: aproximadamente igual à soma dos tamanhos de disco provisionados menos regiões esparsas/zero
  • Tamanho do backup Incremental: tipicamente 5 a 15% do tamanho Full para VMs ativas com taxas de escrita moderadas; VMs de banco de dados podem ser maiores
  • Fórmula de retenção: Total = Tamanho_Full + (Incrementais_por_ciclo × Tamanho_médio_Inc × Dias_de_retenção)
  • Compressão: LZ4 nas opções do FileSet Bacula tipicamente alcança redução de 20 a 40% em dados de disco de VM não comprimidos

9.3 Dimensionamento do receptor de DR

  • Armazenamento de seed: 1× capacidade total de disco por VM protegida
  • Armazenamento de bitmap: aproximadamente 1 MB por TB de disco por ciclo (muito pequeno)
  • IOPS do diretório de estado: intensivo em escrita durante seed; intensivo em leitura durante failover-test
  • Memória por instância de receptor: aproximadamente 256 MB em idle; 1 a 2 GB durante push de seed ativo

10. Relatório de desempenho

O Plugin de Backup Nutanix AHV PodHeitor foi validado por meio de um programa de testes em laboratório estruturado no Nutanix Community Edition 6.8.1 (nó único, aninhado no Proxmox VE 8) e por testes unitários e de integração no Oracle Linux 9 com Bacula Community Edition 15.0.3. Todos os gates de fase de F0 a F8.4 foram aprovados no nível source-complete, com verificação E2E ao vivo condicionada ao acesso do operador ao host Director.

Métrica Observado / Esperado Condições
Taxa de transferência de backup Full (iSCSI) 400–800 MB/s 10 GbE, O_DIRECT, chunks de 1 MiB, armazenamento SSD-tier AHV
Redução do tamanho do backup Incremental 85–95% vs Full VM de produção típica, taxa de alteração em 24h de ~5 a 15%
Limite de taxa da API Prism (lado cliente) 30 req/min (configurável) Token-bucket aplicado para evitar erro 429 do Prism Central
Taxa de transferência de seed de DR Até max_bandwidth_mbps Limitador token-bucket; 0 = velocidade de linha
Overhead de reconexão durante push <5 s típico Reconexão TCP + retomada do último limite de ciclo confirmado
Latência do health-check <10 s Sequência completa de probe RBAC + DSIP na LAN
Overhead de inicialização do backend <200 ms Varredura RAII de recursos obsoletos + autenticação Prism na LAN
Overhead de codificação PHCBT01 <1% de CPU Iteração de regiões + pré-soma não é o gargalo
Aceleração de concorrência multi-VM Quase linear até concurrent_vms Limitado pela taxa da API Prism e largura de banda iSCSI

Validado em laboratório, pronto para produção. Esses valores representam os melhores resultados observados em condições controladas; o desempenho real varia com a carga do cluster, topologia de rede e perfis de disco das VMs.

11. Matriz de compatibilidade

11.1 Componentes Bacula

Componente Versão Observações
Bacula Community Edition File Daemon 15.0.3+ Obrigatório — versões mais antigas não possuem semântica de OK-ack do metaplugin
Bacula Director 15.0.3+ Qualquer Director CE correspondente
Bacula Storage Daemon 15.0.3+ Qualquer Storage Daemon CE correspondente

11.2 Sistemas operacionais (host FD)

SO Status Pacote
Oracle Linux 9 Suportado (alvo de build primário) RPM
RHEL 9 / Rocky Linux 9 / AlmaLinux 9 Suportado RPM
Ubuntu 22.04 LTS Suportado DEB
Ubuntu 24.04 LTS Suportado DEB
Debian 12 Melhor esforço (mesma toolchain do Ubuntu 24.04) Tarball
Outro x86_64 com glibc 2.34+ Melhor esforço Tarball
RHEL 8 / OL 8 Não suportado glibc 2.28 muito antiga para a toolchain Rust distribuída
ARM64 (aarch64) Roadmap —

11.3 Plataforma Nutanix

Superfície Testado Observações
AOS 6.x (Prism Central + Element) Sim Baseline testado primário
AOS 7.x Sim Testado em ambiente de laboratório
Nutanix Community Edition 6.8.1 Sim Laboratório — aninhado no Proxmox VE 8
API Prism Central v3 Sim Caminho primário; sempre disponível
API Prism Central v4 Sim Detectada automaticamente; suporte completo a CRT baseado em DRP
PC de cluster único Sim Configuração padrão
PC multi-cluster Sim Use o parâmetro cluster=

11.4 Destinos de hypervisor para restauração

Hypervisor Backup (origem) Restauração INBOUND (F6) Observações
Nutanix AHV Sim Sim (F4 mesmo cluster, F5 cluster alternativo) Suporte nativo completo
Proxmox VE Use plugin irmão Sim (qemu-img → qcow2) Testado unitariamente; E2E pendente de acesso ao laboratório
VMware vSphere Use plugin irmão Sim (qemu-img → vmdk) Testado unitariamente; E2E pendente de acesso ao laboratório
Microsoft Hyper-V Use plugin irmão Sim (qemu-img → vhd/vhdx) Testado unitariamente; E2E pendente de acesso ao laboratório

12. Segurança

12.1 Tratamento de credenciais

O plugin implementa um modelo de credenciais com privilégio mínimo:

  • Credenciais Prism nunca são passadas inline em argumentos de linha de comando visíveis ao ps. O parâmetro passfile= aponta para um arquivo com modo 0600, proprietário root:bacula, legível apenas pelo processo FD.
  • O parâmetro inline password= é suportado por compatibilidade, mas emite um AVISO em cada job incentivando a migração para passfile.
  • Tokens PSK de DR (dr_auth_token) devem ser gerados com openssl rand -hex 32 (256 bits de entropia) e armazenados no arquivo de configuração com modo 0640. Eles nunca são escritos nos logs de job do Bacula.
  • Todos os parâmetros sensíveis são redigidos dos I-packets e linhas de log em verbose=1; apenas traces de debug intencionais em verbose=3 podem incluir valores parciais.

12.2 Postura RBAC do Prism

A conta de serviço usada para backups requer exatamente três funções no escopo do cluster:

  1. Backup Admin — criação/exclusão de snapshots e operações de Volume Group
  2. VM Admin — enumeração de VMs e criação de VM para restauração
  3. Cluster Admin (somente leitura) — descoberta de cluster e consulta de DSIP

O verbo health-check confirma que as três funções estão presentes antes que qualquer job seja executado. Uma conta sem alguma função falhará no health-check com código de saída 4 (etapa de verificação RBAC) com um erro descritivo nomeando a função ausente.

12.3 Segurança de transporte

  • Prism Central HTTPS: verificação TLS ativada por padrão. O flag prism_insecure=yes a desativa para laboratórios com certificados Prism autoassinados e emite um AVISO persistente.
  • Canal de replicação de DR: autenticado por PSK com HMAC-SHA256 por frame. Atualização mTLS opcional via dr_auth_cert / dr_auth_key / dr_ca_cert para ambientes que requerem autenticação por certificado mútuo.
  • Comunicações internas do Bacula: protegidas pela configuração TLS existente do Bacula (Director ↔ FD ↔ SD); o plugin não contorna nem enfraquece a segurança do próprio canal do Bacula.

12.4 Isolamento de processo

O backend é executado como subprocesso do bacula-fd com UID/GID herdados (bacula:bacula por padrão). Ele não adquire privilégios adicionais. O binário iscsiadm requer root ou um wrapper SUID em algumas distribuições — a documentação de instalação cobre isso explicitamente. O backend nunca escreve fora de working_dir e state_dir.

12.5 Relevância OWASP

Embora o plugin não seja uma aplicação web, vários princípios OWASP se aplicam ao seu design: dados sensíveis nunca são registrados na verbosidade padrão (mitigação de OWASP A02 Falhas Criptográficas); o cliente da API Prism aplica verificação de certificado TLS por padrão (A02); todas as entradas externas (parâmetros do plugin, valores do arquivo de configuração, respostas da API Prism) são validadas e limitadas antes do uso (mitigação de A03 Injeção); e o canal de DR autenticado por PSK impede a personificação não autorizada do receptor (mitigação de A07 Falhas de Autenticação).

13. Monitoramento

13.1 Fontes de log

Fonte Caminho / Comando Conteúdo
Log do backend /opt/bacula/working/podheitor-nutanix-backend.log Toda a atividade do backend — chamadas Prism, eventos iSCSI, estatísticas PHCBT01, erros
Log do FD /opt/bacula/working/&lt;fd-host&gt;-fd.log Carregamento do plugin, I-packets PTCOMM encaminhados ao Director
Log do receptor de DR (único) journalctl -u podheitor-nutanix-receiver Recebimento de seed, aplicação de bitmap-push, transições de estado de failover
Log do receptor de DR (por VM) journalctl -u podheitor-nutanix-receiver@vm-prod-01 Atividade do receptor por VM
Log de job Bacula Console Director Bacula / Bweb / Baculum I-packets encaminhados pela cdylib: versão do backend, fase, VMs selecionadas, contagem de discos, erros

13.2 Principais mensagens I-packet a monitorar

Os seguintes I-packets são emitidos em verbose=1 e aparecem no log de job do Bacula. Eles são a principal superfície de monitoramento operacional:

Mensagem I-packet Significado Ação se ausente
podheitor-nutanix backend up (v2.0.0) phase=F2 mode=Backup vm=… Backend iniciado com sucesso Verificar carregamento do plugin no log do FD
Prism discovery: PC=… cluster=… capability=v3|v4 Prism Central acessível e versão da API determinada Executar --standalone health-check
Selected N VM(s) for backup Glob de VM correspondeu a N máquinas virtuais Verificar padrão vm= e conectividade com Prism
Backup complete: VM=… disks=N bytes=B Todos os discos de uma VM transmitidos com sucesso Verificar log do backend se ausente
Applied PHCBT01 delta to disk-N (regions=R changed=B) Delta CBT incremental aplicado na restauração Garantir que o FileSet inclua v3
DR cycle complete: vm=… cycle=N bytes_pushed=B Ciclo de bitmap-push concluído Verificar log do receptor e caminho de rede

13.3 Integração com Prometheus / métricas

O backend não expõe um endpoint Prometheus nativo na v2.0.0. O padrão de monitoramento recomendado usa um exportador de scraping de logs (por exemplo, mtail ou grok_exporter) contra o log do backend. Métricas sugeridas para derivar:

Nome da métrica Derivado de Limiar de alerta
nutanix_backup_bytes_total{vm,type} Backup complete: bytes=B Zero bytes = backup vazio (aviso)
nutanix_backup_duration_seconds{vm} Timestamps de início/conclusão do backend > 4× média móvel (anomalia)
nutanix_dr_cycle_bytes_pushed{vm} DR cycle complete: bytes_pushed=B Zero sustentado = replicação parada
nutanix_dr_reconnect_total{vm} Linhas de log mid-push reconnect > 5/hora = caminho de rede instável
nutanix_prism_api_errors_total{endpoint} Linhas de log Prism API error Qualquer erro sustentado
nutanix_iscsi_attach_failures_total Linhas de log iSCSI attach failed Qualquer = investigar DSIP / initiator

14. Guia de solução de problemas

14.1 Onde procurar primeiro

# Log verbose do backend (mais detalhes)
tail -100 /opt/bacula/working/podheitor-nutanix-backend.log

# Aumentar verbosidade para debug ativo
# Em nutanix.conf: verbose = 2   (debug) or verbose = 3 (trace)

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

# Status do receptor de DR
journalctl -u podheitor-nutanix-receiver --since "1 hour ago"

14.2 Falhas comuns e correções

Sintoma Causa raiz Correção
401 Unauthorized na primeira requisição Prism Conta de serviço não encontrada no Prism IAM (pode existir apenas em pass-through LDAP); ou passfile não legível pelo processo FD Verificar se o usuário IAM existe no Prism. Checar chown root:bacula /opt/bacula/etc/nutanix.secrets &amp;&amp; chmod 0600 nutanix.secrets
403 Forbidden na criação de snapshot Conta de serviço sem a função Backup Admin no escopo do cluster Em Prism → IAM → Funções → Atribuições, adicionar Backup Admin para o escopo do cluster
Incremental continua executando como Full Linha Plugin= do FileSet sem chave v3, ou snapshot de referência deletado pela política de retenção do cluster Garantir que o FileSet use o padrão (sem chave version=) ou explicitamente v3. Verificar no log do backend por reference_snapshot not found.
Falha na conexão iSCSI: No portal available DSIP incorreto ou inacessível, ou IQN do host FD não autorizado na allowlist de VG do cluster Fixar DSIP: dsip=192.168.x.y. Adicionar IQN do FD à allowlist de volume-group do cluster via Prism ou CHAP.
qemu-img: command not found durante restauração F5/F6 qemu-img não instalado ou não no PATH para o usuário bacula dnf install qemu-img (RHEL) ou apt install qemu-utils (Ubuntu). Verificar com sudo -u bacula which qemu-img.
Receptor de DR em loop de reinicialização Incompatibilidade de dr_auth_token entre configs SOURCE e RECEIVER; state_dir sem permissão de escrita; colisão de porta Confirmar que os tokens são iguais. Verificar chmod 750 /opt/bacula/working/nutanix-repl/. Executar ss -tlnp | grep 9848 para detectar conflitos de porta.
Receptor multi-instância: estado cruzado entre VMs Duas instâncias de template compartilhando o mesmo state_dir Cada configuração por VM deve ter um state_dir distinto, por exemplo /opt/bacula/working/nutanix-repl/vm-prod-01/
Clone de failover-test não limpo failover-undo não executado após o teste de DR Executar job com mode=failover-undo para liberar o clone da VLAN isolada e o espaço em disco do state-dir
TLS handshake failed na conexão Prism Cluster Nutanix CE ou interno usando certificado autoassinado Apenas para laboratório/interno: adicionar prism_insecure=yes à configuração. Para produção: instalar um certificado válido no Prism Central.
Backend sai com código 2 na inicialização Verbo --standalone desconhecido ou parâmetros Plugin= malformados Verificar a sintaxe da linha Plugin= na seção 7. Executar com verbose=3 para ver o parse completo de parâmetros.

14.3 Referência de estado de failover

Modo VM na origem VM no receptor Estado do receptor
failover-test Intacta Inicializa em VLAN isolada Inalterado
failover-planned Quiesced + desligada Ligada Promovido; receptor torna-se fonte de verdade
failover-unplanned Inacessível Ligada Promovido; receptor torna-se fonte de verdade
failover-undo Intacta Clone de teste deletado Inalterado
failover-perm (limpeza manual necessária) Promovida Torna-se nova SOURCE — re-pareie para inverter

15. Casos de uso e cenários de implantação

15.1 Backup diário de VMs Nutanix de produção

Uma organização com 50 VMs de produção em um cluster Nutanix AHV quer backups Full diários nos fins de semana e Incrementais noturnos de segunda a sexta-feira, com retenção de 30 dias. O plugin PodHeitor é instalado em um host Bacula FD dedicado com conectividade 10 GbE ao DSIP do Prism. Um único FileSet com vm=prod-* e concurrent_vms=4 conduz todo o programa de backup. O Bacula Director executa Jobs em horários agendados; taxas de alteração incremental de 5 a 10% por dia significam que os backups Full de fim de semana são os únicos jobs com crescimento significativo de armazenamento. Os testes de restauração são realizados mensalmente usando um Job com mode=restore em um cluster de teste isolado.

15.2 Recuperação de desastres com replicação contínua

Uma empresa de serviços financeiros requer RPO inferior a 5 minutos para suas 10 VMs de banco de dados Tier-1. A pilha de replicação de DR é implantada com unidades de template systemd por VM em um host receptor no site de DR (300 km de distância, conectado via MPLS de 100 Mbit/s). Cada VM executa um receptor independente com seu próprio state_dir, dr_port e PSK. A configuração push_interval=300 aciona ciclos de bitmap-push a cada 5 minutos. Testes mensais de failover-test confirmam a capacidade de recuperação sem interromper a produção.

15.3 Migração do VMware vSphere para Nutanix AHV

Uma empresa migrando de um ambiente VMware vSphere para Nutanix AHV usa o plugin PodHeitor VMware irmão para fazer backup das VMs vSphere, depois usa o caminho cross_restore=yes (F6 INBOUND) do plugin Nutanix para restaurar imagens de disco convertidas no cluster AHV de destino. As substituições --vcpu e --memory-mib permitem redimensionar VMs durante a migração sem modificar a origem. Isso elimina a necessidade de uma ferramenta de migração dedicada e mantém todo o fluxo de trabalho dentro da infraestrutura Bacula existente.

15.4 Ambiente Nutanix multi-cluster

Um provedor de serviços gerenciados opera três clusters Nutanix sob um único Prism Central. Eles usam um único nutanix.conf com prism_central= apontando para o PC, e FileSets separados por cluster usando o parâmetro cluster= para escopo de cada job no cluster correto. Cenários de restauração entre clusters (restaurando uma VM do cluster A para o cluster B) usam target_cluster= no Job de restauração. O verbo health-check é executado via playbook Ansible como parte das verificações semanais de infraestrutura.

15.5 Ambiente air-gapped com armazenamento Bacula em fita

Uma agência governamental opera um ambiente Nutanix air-gapped. Todos os backups passam por uma infraestrutura Bacula com armazenamento em fita LTO. O plugin PodHeitor transmite dados de disco de VM pelo PTCOMM diretamente para o pool de fitas Bacula — sem staging intermediário em disco necessário. O parâmetro max_bandwidth_mbps= é usado para limitar o tráfego de backup para evitar saturar a rede interna durante o horário comercial. As restaurações requerem montagem manual de fita, que o operador inicia via bconsole restore; o plugin lida com a reconstrução completa no disco scratch do host FD antes de fazer upload para o AHV.

16. Comparação com outras abordagens

Capacidade Plugin PodHeitor Nutanix Bacula Enterprise (Nutanix) Veeam Data Platform Commvault Complete NetBackup
Motor de backup Bacula Community 15.0.3+ Bacula Enterprise 15.x Veeam B&R Commvault Veritas NetBackup
Incrementais baseados em CBT Sim Sim Sim Sim Sim
Streaming em nível de bloco via iSCSI Sim Sim Sim (HotAdd/NBD) Sim Sim
Integração nativa com API Prism Sim (v3 + v4) Sim Parcial Parcial Parcial
Restauração entre clusters Sim (F5) Sim Sim Sim Sim
Restauração entre fornecedores (qemu-img) Sim (F6 — Proxmox, vSphere, Hyper-V) Limitado Não Não Não
Replicação de DR embutida Sim (PSK-TCP, seed + delta + failover) Sim Sim (jobs de replicação) Sim Sim
Orquestração de failover Sim (4 modos) Sim Sim (SureBackup) Sim Limitado
Prism Central multi-cluster Sim Sim Sim Sim Sim
Instant Recovery (F9) Roadmap (plugin separado) Sim Sim Sim Sim
Restauração granular em nível de arquivo (F10) Roadmap (plugin separado) Sim Sim Sim Sim
Motor de backup open source Sim (Bacula Community) Não (proprietário) Não Não Não
Custo de licenciamento anual típico Fração das alternativas* ~US$ 10.000+/ano ~US$ 5.000+/ano ~US$ 10.000+/ano ~US$ 10.000+/ano
Modelo de licença do plugin Proprietário Proprietário Proprietário Proprietário Proprietário

* Entre em contato com PodHeitor International para preços atuais. A afirmação de 50% de economia é comparada com os preços de tabela publicados para conjuntos de funcionalidades equivalentes.

Nota sobre Bacula Enterprise: O Bacula Enterprise é uma alternativa válida e madura com um conjunto mais amplo de funcionalidades (incluindo Instant Recovery e restauração granular em um único produto). O plugin PodHeitor está posicionado como uma alternativa econômica para organizações que já investiram em infraestrutura Bacula Community e desejam uma integração Nutanix AHV de nível de produção sem o compromisso total de licenciamento do Bacula Enterprise. As duas soluções atendem perfis diferentes de orçamento e complexidade e não são competidores diretos.

17. Roadmap

17.1 v2.x — Estabilidade e ecossistema (H2 2026)

  • F7 — Cross-restore OUTBOUND: Habilitar que VMs Nutanix AHV sejam restauradas em outros hypervisores (Proxmox VE, VMware vSphere, Hyper-V) pelo caminho de exportação, complementando o caminho F6 INBOUND existente.
  • F3.5 / F3.6 — Estabilização do CRT v4: A captura DRP por disco está source-complete; validação E2E ao vivo em um cluster somente v4 para confirmar a cobertura do parser contra todos os formatos de resposta GA do AOS 7.x.
  • F4.5 — Upload no Image Service e criação de VM: Completar o caminho de restauração F4 conectando a reconstrução de disco ao upload no Prism Image Service e à materialização completa de VM a partir da imagem reconstruída.
  • Build ARM64: Target de compilação cruzada para aarch64 Linux para suportar organizações que executam Bacula FD em infraestrutura baseada em Arm.
  • Endpoint exportador Prometheus: Expor um endpoint HTTP /metrics em uma porta configurável para scraping nativo pelo Prometheus sem necessidade de parse de logs.

17.2 v3.x — Recuperação avançada (H1 2027)

  • F9 — Instant Recovery (boot via iSCSI-target): Esta funcionalidade é deliberadamente de propriedade do plugin paralelo PodHeitor Bacula-SD de restauração granular + IR, que serve todos os backends de estilo VM a partir de uma única implementação. O plugin Nutanix AHV se integrará a ele quando o plugin SD atingir GA.
  • F10 — Restauração granular em nível de arquivo: Mesmo escopo que F9 — fornecido pelo plugin Bacula-SD de restauração granular, que monta discos de VM reconstruídos e expõe arquivos individuais via navegador de restauração do Bacula.
  • Modo multi-tenant: Escopos RBAC dedicados por tenant dentro de um Prism Central compartilhado, habilitando implantações de provedores de serviços gerenciados com isolamento estrito de dados.
  • Suporte a destino cloud-native: Replicação de DR direta para armazenamento de objeto compatível com S3 como alternativa a um host receptor dedicado.

17.3 Contínuo

  • Acompanhamento de versões do Nutanix AOS e Prism Central API; atualizações de parser para quaisquer mudanças de schema de resposta em endpoints v4
  • Testes de regressão contínuos contra o ambiente de laboratório Nutanix Community Edition
  • Otimizações de desempenho para VMs muito grandes (> 4 TiB em um único disco) e VMs com muitos discos (> 16 discos)

18. Conclusão

O Plugin de Backup Nutanix AHV PodHeitor para Bacula representa um avanço significativo para o ecossistema de backup open source. Ele traz proteção Nutanix AHV de nível de produção — incluindo incrementais baseados em CBT, suporte multi-cluster, restauração entre fornecedores e uma pilha completa de replicação de DR e failover — ao alcance de qualquer organização que execute o Bacula Community Edition, sem exigir uma migração completa de plataforma de backup comercial ou licenciamento Bacula Enterprise.

A arquitetura do plugin — Rust puro em ambos os lados da fronteira do metaplugin, limpeza de recursos RAII-safe, isolamento de subprocesso PTCOMM e uma disciplina de engenharia em fases com mais de 50 testes automatizados — torna-o uma base confiável para fluxos de trabalho de backup de missão crítica. O verbo standalone health-check, os templates systemd de DR por VM e o registro estruturado de I-packets dão às equipes de operações a visibilidade e o controle necessários para manter uma postura de backup defensável.

Para organizações que enfrentam renovações de plataformas de backup comerciais — especialmente aquelas avaliando Veeam, Commvault ou NetBackup para Nutanix AHV — o plugin PodHeitor oferece uma alternativa comparativa com economia de 50% ou mais, com um conjunto de funcionalidades adaptado especificamente à plataforma Nutanix, em vez de sobreposto a uma camada de abstração de hypervisor genérica.

Convidamos você a avaliar o plugin em seu ambiente. Comece com o health-check standalone, execute um job de backup canário e compare a precisão da restauração e a simplicidade operacional com sua solução atual. Para um orçamento comercial por escrito, comparação de funcionalidades com seu ambiente específico ou contratação de serviços profissionais (instalação, configuração, go-live em produção), entre em contato diretamente com Heitor Faria pelos detalhes abaixo.

Oferta especial. Traga sua proposta de renovação de qualquer plataforma comercial de backup corporativo — Veeam, Commvault, NetBackup ou outras. Elaboraremos uma proposta comparativa com meta de pelo menos 50% de economia e funcionalidade superior específica para Nutanix AHV. Entre em contato pelo e-mail heitor@opentechs.lat para receber um orçamento por escrito.

19. Informações de contato

Canal Detalhes
Nome Heitor Faria — PodHeitor International
Website https://podheitor.com
E-mail heitor@opentechs.lat
Telefone / WhatsApp (Internacional) +1 786 726-1749
Telefone / WhatsApp (Brasil) +55 61 98268-4220
Documentação do plugin https://podheitor.com/plugins/nutanix-ahv
Suporte E-mail com assunto: PodHeitor Nutanix Plugin Support

Para contratos corporativos, Heitor Faria fornece serviços profissionais incluindo instalação, integração com Directors Bacula existentes, design de runbook de DR e suporte ao go-live em produção. Contratos de suporte por retainer e por incidente estão disponíveis.

20. Legal / direitos autorais

© 2026 Heitor Faria — PodHeitor International. Todos os Direitos Reservados.

O Plugin de Backup Nutanix AHV PodHeitor para Bacula é dual-licenciado sob LicenseRef-PodHeitor-Proprietary. A licença proprietária rege todos os usos comerciais e redistribuição. Entre em contato com heitor@opentechs.lat para termos de licenciamento comercial.

Marcas registradas: PodHeitor e o logotipo PodHeitor são marcas registradas de Heitor Faria / PodHeitor International. Nutanix, AHV, Prism, Prism Central, Prism Element, AOS e Nutanix Community Edition são marcas registradas ou marcas comerciais da Nutanix, Inc. Bacula e Bacula Enterprise são marcas registradas da Bacula Systems SA. Veeam é marca registrada da Veeam Software AG. Commvault é marca registrada da Commvault Systems, Inc. NetBackup e Veritas são marcas registradas da Veritas Technologies LLC. VMware e vSphere são marcas registradas da VMware, Inc. (uma empresa da Broadcom). Proxmox VE é marca registrada da Proxmox Server Solutions GmbH. Microsoft e Hyper-V são marcas registradas da Microsoft Corporation. Todas as demais marcas são propriedade de seus respectivos titulares.

Aviso legal: Este documento é fornecido para fins informativos. Os valores de desempenho e comparações de custos são baseados em testes em laboratório e preços de tabela publicamente disponíveis no momento da publicação e podem variar conforme o ambiente, configuração e mudanças de preços dos fornecedores. PodHeitor International não oferece garantia, expressa ou implícita, quanto à precisão das informações de produtos de terceiros contidas neste documento.

Disponível em: pt-brPortuguêsenEnglish (Inglês)esEspañol (Espanhol)

Deixe um comentário