Blog

Whitepaper — PodHeitor Proxmox

Whitepaper — PodHeitor Proxmox

Backup agentless para Proxmox VE. KVM e LXC via API nativa — incremental real, CBT por dirty bitmap, restauração granular de arquivo, restore para cluster diferente.

  • Incremental real com dirty bitmap — só envia blocos alterados, sem replicar o disco inteiro.
  • Sem agente dentro da VM — captura via PVE API, integração QGA para application-consistent.
  • Restore granular de arquivo sem subir a VM inteira — monte o snapshot, copie o que precisa.
  • Cross-cluster restore — recupere para nó PVE diferente, opcionalmente diferente Storage backend.
  • Snapshots ZFS / Ceph / LVM-thin coordenados — application-consistent quando disponível, crash-consistent garantido.

Comece em 30 dias, no mínimo 50% mais barato. Trial gratuito, RPMs e DEBs assinados, suporte direto com Heitor Faria. Substitua sua licença Veeam, Commvault ou Bacula Enterprise sem quebrar a janela noturna.

Solicitar trial gratuito de 30 dias →

Sumário

  1. Resumo Executivo
  2. Introdução
  3. Casos de Uso
  4. Arquitetura Técnica
  5. Referência Detalhada de Funcionalidades
  6. Procedimento de Instalação
  7. Guia de Dimensionamento e Configuração
  8. Matriz de Compatibilidade
  9. Referência de Parâmetros
  10. Exemplos de Configuração
  11. Modelo de Segurança
  12. Comparativo Competitivo
  13. Análise de TCO e ROI
  14. Roadmap
  15. Conclusão
  16. Aviso Legal e Contato
  17. Apêndice

1. Resumo Executivo

Organizações que utilizam Proxmox VE como plataforma de virtualização historicamente enfrentam uma lacuna significativa na proteção de dados em nível empresarial: ou aceitam as limitações do PBS (Proxmox Backup Server) nativo — sem integração com os frameworks corporativos de backup existentes — ou pagam preços premium por soluções independentes de hypervisor que trazem altos custos de licenciamento, arquiteturas complexas e dependência de fornecedor.

O PodHeitor Proxmox Backup, Replication and Conversion Plugin for Bacula elimina essa lacuna de forma decisiva. Trata-se de um plugin com licença comercial e validado em produção que integra nativamente a proteção de máquinas virtuais Proxmox VE ao PodHeitor Backup, um dos mecanismos de backup open-source mais amplamente implantados no mundo. O resultado é uma plataforma de backup unificada que combina o maduro agendamento de jobs, catálogo e gerenciamento de retenção do Bacula com proteção de VMs crash-consistent e application-consistent, backups incrementais-forever usando dirty bitmaps QEMU (CBT), replicação para recuperação de desastres entre nós, restauração instantânea via overlay NBD e migração entre hypervisors do VMware vSphere e Microsoft Hyper-V para Proxmox.

O plugin foi validado em ambiente de produção executando mais de 1.290 jobs — todos concluídos com status Terminated OK — em dois nós Proxmox VE 8.4 executando no Debian 12, coordenados por um PodHeitor Backup Director no Oracle Linux 9.6. O agendamento foi testado sob carga em intervalos de cinco minutos, e o caminho completo de replicação DR com fixação de fingerprint TLS foi confirmado como operacional.

Para executivos e lideranças de TI, as propostas de valor estratégico são:

  • Redução de custos: Elimine ferramentas duplicadas. Uma única implantação Bacula cobre servidores físicos, VMs, bancos de dados e, agora, VMs Proxmox.
  • Redução de riscos: Replicação DR validada para um nó PVE secundário com provisionamento automatizado de VMs e transporte seguro por TLS.
  • Agilidade: A conversão entre hypervisors viabiliza a migração de workloads VMware e Hyper-V para Proxmox sem ferramentas de migração caras de terceiros.
  • Conformidade regulatória: Backups application-consistent (quiesce/freeze via QEMU agent), registro de auditoria completo pelo catálogo Bacula e políticas de retenção configuráveis.
  • Sem proliferação de daemons adicionais: O agendamento é tratado inteiramente pelo agendador nativo Bacula — nenhum cron job, agente ou serviço adicional.

2. Introdução

2.1 O Problema

Ambientes de TI corporativos que adotaram Proxmox VE como plataforma primária ou secundária de hypervisor enfrentam um desafio recorrente: integração da proteção de dados. A maioria das estratégias corporativas de backup é padronizada em torno de um único framework — comumente Bacula, Veeam ou Commvault — e estender esse framework para cobrir VMs Proxmox normalmente exige uma das seguintes concessões:

  1. Executar o Proxmox Backup Server (PBS) como sistema paralelo — aceitável para ambientes pequenos, mas introduz um plano de gerenciamento completamente separado, lógica de retenção e fluxo de relatórios que não se integra ao catálogo corporativo de backup.
  1. Instalar um agente de backup em nível de arquivo dentro de cada VM — anula o propósito do backup em nível de hypervisor, ignora o quiescing pré-snapshot, exige licenciamento por VM e não permite restauração bare-metal ou instantânea.
  1. Adquirir uma solução empresarial independente de hypervisor — Veeam, Commvault ou Veritas adicionam custos significativos de licenciamento, podem não suportar Proxmox oficialmente e introduzem proliferação de agentes e arquitetura complexa.
  1. Usar o plugin Proxmox do Bacula Enterprise — disponível, mas restrito à linha comercial do Bacula Enterprise, que cobra custos de licenciamento por front-end ou por TB que se tornam desfavoráveis para implantações Proxmox de médio porte.

2.2 A Solução

O PodHeitor Proxmox Plugin entrega um plugin nativo Bacula que é executado como uma biblioteca compartilhada carregada pelo Bacula File Daemon em cada nó Proxmox VE. Um binário backend de alto desempenho em Rust comunica-se diretamente com a API REST do Proxmox, sockets do QEMU Monitor Protocol (QMP) e interfaces de Network Block Device (NBD) — habilitando backups completos, incrementais e diferenciais de VMs com crash consistency e application consistency opcional.

Como o plugin implementa a API padrão de plugins do Bacula, ele herda todo o ecossistema Bacula:

  • Agendamento de jobs, janelas e calendários
  • Políticas de retenção e gerenciamento de volumes
  • Arquivos bootstrap e restauração baseada em catálogo
  • Relatórios e alertas em nível de Director
  • Suporte a múltiplos Storage Daemons
  • Backends de armazenamento em nuvem (S3, Azure, GCS) via configurações existentes do Bacula SD

2.3 Mercado-Alvo

O plugin é projetado para:

  • Empresas de médio e grande porte que executam Proxmox VE 8.x como plataforma primária de virtualização em conjunto com PodHeitor Backup
  • Provedores de serviços e MSPs que gerenciam múltiplos ambientes de clientes no Proxmox
  • Organizações migrando do VMware ou Hyper-V para Proxmox que precisam de uma ferramenta unificada de migração e backup
  • Organizações que já executam Bacula Enterprise ou Community e desejam estender a cobertura para nós Proxmox sem adotar uma plataforma adicional

3. Casos de Uso

3.1 Backup de Toda a Frota de VMs com Estratégia Incremental-Forever

Cenário: Uma empresa de médio porte executa 80 VMs em dois nós Proxmox VE. A equipe de backup deve atingir um RPO de 24 horas e um RTO de 4 horas, com retenção de 90 dias. O orçamento de armazenamento é limitado.

Solução: O plugin é configurado com backup_type=full para jobs semanais de domingo e backup_type=incremental para jobs noturnos. Na primeira execução, um backup completo em nível de imagem captura todos os extents de disco das VMs via NBD. Nas execuções subsequentes, apenas os extents modificados rastreados pelos bitmaps CBT do QEMU são enviados ao Bacula Storage Daemon, reduzindo as janelas de backup de horas para minutos.

Fluxo:

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

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

Resultado: Backup completo semanal (~escala de TB), incrementais em menos de 30 minutos por noite. Retenção de 90 dias via gerenciamento de pools e volumes Bacula. RTO atendido pelo assistente de restauração baseado em catálogo.

3.2 Replicação para Recuperação de Desastres em Site Secundário

Cenário: Uma empresa de serviços financeiros exige um site secundário que espelhe VMs críticas do cluster PVE primário. O site secundário deve ser capaz de inicializar as VMs de forma independente em até 15 minutos após uma falha no site primário.

Solução: O modo de replicação DR usa uma arquitetura receiver/sender. O nó PVE secundário executa o plugin em mode=receiver, aguardando conexões na porta TCP 9190. O nó primário executa mode=seed (sender), que transmite os dados de disco das VMs por um canal criptografado TLS com autenticação PSK. O receiver provisiona automaticamente a VM alvo no cluster PVE secundário.

Fluxo:

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

Resultado: A VM 127 fica disponível no nó PVE secundário em minutos. Em caso de failover, a equipe de operações inicializa a VM 127 no nó de DR. Nenhuma cópia ou importação manual de disco é necessária.

3.3 Restauração Instantânea para Conformidade Rápida com SLA

Cenário: Uma VM de banco de dados de produção falha às 09h15. O backup das 02h00 existe no Bacula Storage Daemon. O SLA do negócio exige restauração do serviço em até 30 minutos.

Solução: O modo de Restauração Instantânea (IR) inicializa a VM diretamente do backup via overlay NBD montado no nó Proxmox. A VM fica ativa em 2 a 5 minutos. Em segundo plano, o plugin migra os discos da VM do overlay NBD para o armazenamento alvo final, de forma transparente e sem interrupção do serviço.

Fluxo:

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

Resultado: SLA de 30 minutos cumprido às 09h20 — 8 minutos após a detecção da falha.

3.4 Migração entre Hypervisors — VMware para Proxmox

Cenário: Uma empresa está encerrando um contrato de licença perpétua VMware após os aumentos de preço da aquisição pela Broadcom. Eles precisam migrar 40 VMs do vSphere 7 para Proxmox VE 8 com tempo de inatividade mínimo e sem adquirir ferramentas de migração adicionais.

Solução: O plugin inclui um pipeline de conversão validado do formato VMware VMDK para os formatos nativos Proxmox qcow2 ou raw. Os discos VMDK são exportados do vSphere e o plugin realiza a tradução de formato, normalização da geometria de disco e mapeamento da configuração da VM para o formato .conf do Proxmox.

Fluxo:

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

Resultado: 40 VMs migradas durante uma janela de manutenção de fim de semana. Zero custos adicionais de licenciamento de ferramentas de migração.

3.5 Backup Application-Consistent para Bancos de Dados

Cenário: Um cluster de banco de dados PostgreSQL é executado dentro de uma VM Proxmox. A equipe de DBA exige backups application-consistent — logs WAL checkpointed e o sistema de arquivos quiesced antes do snapshot — para garantir restauração limpa sem falhas de replay.

Solução: O parâmetro quiesce=yes instrui o plugin a invocar o comando guest-fsfreeze-freeze do QEMU Guest Agent antes de criar o snapshot Proxmox e guest-fsfreeze-thaw após. Isso garante que todas as escritas de sistema de arquivos em andamento sejam confirmadas antes da criação do snapshot.

Fluxo:

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

Resultado: O PostgreSQL é restaurado a partir do backup sem necessidade de replay de WAL. Os testes de restauração confirmam inicialização limpa do banco de dados diretamente a partir da imagem de backup.

3.6 Ambiente MSP Multi-Tenant Automatizado

Cenário: Um provedor de serviços gerenciados hospeda VMs para 30 clientes em um cluster Proxmox compartilhado. Cada cliente tem janelas de backup, requisitos de retenção e destinos de DR diferentes.

Solução: A arquitetura nativa multi-client do Bacula se encaixa naturalmente. Cada grupo de cliente é um Client Bacula separado apontando para um nó PVE dedicado, com FileSets, Schedules, Pools e Storage Daemons independentes. O parâmetro vm= do plugin aceita intervalos de VMID ou padrões de nome, habilitando jobs de backup com escopo por cliente sem modificar nenhuma configuração global.

Resultado: 30 streams de backup independentes, gerenciados a partir de um único Bacula Director, com relatórios, retenção e DR por cliente — tudo sem licenciamento de agente por cliente.

4. Arquitetura Técnica

4.1 Visão Geral dos Componentes

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

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

A biblioteca compartilhada é carregada pelo Bacula File Daemon no nó Proxmox VE. Suas responsabilidades são:

  1. Registrar o plugin no FD no momento do carregamento
  2. Analisar a string Plugin = do FileSet e extrair os parâmetros chave-valor
  3. Iniciar o processo backend em Rust com os parâmetros de job
  4. Encaminhar eventos de backup/restauração Bacula para o backend
  5. Fazer proxy de blocos de dados entre o stream de dados do FD e a saída do backend

Esse design modular significa que a lógica de alto desempenho está inteiramente no binário backend em Rust, que pode ser atualizado e testado independentemente do FD.

4.3 O Backend Rust (podheitor-proxmox-backend)

O binário backend — construído em Rust com memory-safety nativa e sem pausas de GC — é o motor principal, estruturado em torno de cinco subsistemas primários:

Subsistema Responsabilidade
PVE API Client Cliente HTTPS autenticado para a API REST do Proxmox. Gerencia ciclo de vida de tokens, fixação de fingerprint TLS, enumeração de VMs, gerenciamento de snapshots e consultas de armazenamento.
QMP Client Cliente de socket de domínio Unix para o QEMU Monitor Protocol. Emite comandos guest-fsfreeze-freeze/thaw, query-block e gerenciamento de bitmaps.
NBD Engine Cliente TCP para o protocolo Network Block Device (TCP 10809). Gerencia negociação de conexão, consultas de extents (para CBT) e streaming de dados de bloco bruto.
DR Transport Protocolo TCP personalizado na porta 9190. TLS baseado em PSK ou certificado. Implementa os papéis de receiver e sender.
Conversion Engine Parser e conversor de VMDK/OVF e VHDX. Gera arquivos .conf nativos do Proxmox e traduz formatos de disco para qcow2 ou raw.

4.4 Fluxo de Dados: Backup Incremental

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

4.5 Fluxo de Dados: Replicação DR

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

5. Referência Detalhada de Funcionalidades

5.1 Backup de VM — Completo, Incremental, Diferencial

O plugin suporta três níveis de backup alinhados com o modelo de tipo de job do Bacula:

Completo: Todos os extents de disco de todas as VMs selecionadas são transmitidos do nó PVE para o Bacula Storage Daemon. Um snapshot consistente é criado no lado PVE antes da leitura, garantindo crash consistency. Se quiesce=yes, o QEMU guest agent é invocado para congelar os sistemas de arquivos antes da criação do snapshot.

Incremental: Após um backup completo, os dirty bitmaps CBT (Changed Block Tracking) do QEMU registram quais extents de disco de 64KB foram gravados desde o último backup. O plugin consulta esses extents de bitmap via NBD e transmite apenas os blocos modificados. Isso pode reduzir o volume de dados de backup em 90 a 98% para cargas de trabalho típicas.

Diferencial: Semelhante ao incremental, mas o ponto de referência do bitmap é sempre o último backup completo, e não o último job. Isso simplifica as cadeias de restauração (completo + um diferencial) ao custo de backups diferenciais ligeiramente maiores em comparação com os incrementais.

5.2 Replicação DR de VM — Replicação entre Nós

O subsistema de replicação DR é projetado para recuperação de desastres sem ferramentas adicionais. Ele exige:

  • Um segundo nó Proxmox VE (site de DR)
  • Conectividade de rede na porta TCP 9190 entre os nós
  • O plugin instalado em ambos os nós

O provisionamento automático de VM no receiver significa que os operadores não precisam criar manualmente a VM alvo — o plugin cria a configuração da VM, aloca armazenamento e registra a VM no inventário Proxmox automaticamente. As execuções de replicação subsequentes transmitem apenas os extents modificados.

5.3 Conversão entre Hypervisors

Caminhos de conversão validados:

Origem Destino Status
VMware vSphere (VMDK) Proxmox VE (qcow2/raw) Validado em produção
Microsoft Hyper-V (VHDX) Proxmox VE (qcow2/raw) Validado em produção
Proxmox VE (qcow2) Proxmox VE (raw) Nativo

O motor de conversão realiza tradução de formato de disco, mapeamento de configuração de VM, normalização de driver de armazenamento e geração do arquivo .conf Proxmox pós-conversão.

5.4 Segurança TLS — Fixação de Fingerprint SHA-256

O plugin comunica-se com a API Proxmox via HTTPS:8006. Em vez de exigir uma implantação PKI completa ou desabilitar a verificação TLS, o plugin implementa fixação de fingerprint SHA-256: o operador fornece o hash SHA-256 conhecido do certificado TLS do nó Proxmox no parâmetro pve_fingerprint. O backend valida esse fingerprint em cada conexão, prevenindo ataques MITM mesmo com certificados autoassinados.

5.5 Restauração Instantânea (IR) — Boot via Overlay NBD

A Restauração Instantânea elimina a espera pela restauração completa do disco ao montar o volume de backup como uma exportação NBD diretamente acessível pelo nó PVE. O Proxmox inicializa a VM usando esse disco respaldado por NBD imediatamente. Uma camada de overlay captura novas escritas, para que a VM possa operar normalmente durante a migração em segundo plano.

A migração em segundo plano copia os extents de disco do overlay NBD para o target_storage final de forma transparente. Após a conclusão da migração, a VM é totalmente desconectada do volume de backup. O backup original é preservado sem modificações.

5.6 Quiesce/Freeze — Backups Application-Consistent

Quando quiesce=yes (padrão), o plugin emite guest-fsfreeze-freeze para o QEMU guest agent instalado na VM antes de criar o snapshot Proxmox. Após a criação do snapshot (tipicamente em menos de 1 segundo), guest-fsfreeze-thaw é emitido e a VM retoma a operação normal. A janela total de congelamento é tipicamente de 200 a 800ms, imperceptível para os usuários finais.

Se o guest agent não estiver em execução ou não estiver instalado, o plugin recorre à criação de snapshot crash-consistent e registra um aviso.

5.7 Suporte a Múltiplos Formatos de Disco

Formato Leitura Escrita Observações
qcow2 Sim Sim Formato nativo Proxmox, suporta bitmaps CBT
raw Sim Sim Máximo desempenho, sem overhead de formato
vmdk Sim Sim (conversão) Para fluxos de trabalho de importação/exportação VMware

5.8 Automação de Agendamento

Nenhum daemon adicional, entradas cron ou agendadores externos são necessários. O plugin aproveita integralmente o agendador nativo Bacula. O ambiente de validação em produção foi testado em intervalos de agendamento de 5 minutos com todos os jobs concluídos com sucesso, demonstrando a adequação do plugin para requisitos de alta frequência e RPO curto.

6. Procedimento de Instalação

6.1 Pré-requisitos

Antes de instalar, verifique:

  • PodHeitor Backup+ está instalado e operacional (Director, SD, FD)
  • O Bacula File Daemon está em execução no nó Proxmox VE de destino
  • Proxmox VE 8.0+ está em execução no Debian 11+
  • O usuário da API Proxmox possui as permissões adequadas (veja a Seção 6.3)
  • A porta TCP 9102 (FD) está aberta entre o Director e o nó PVE
  • A porta TCP 9190 está aberta entre nós PVE (se usar replicação de DR)

6.2 Instalando o Plugin no Nó PVE

Passo 1: Implantar os arquivos binários

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

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

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

Passo 2: Configurar o Bacula File Daemon para carregar o plugin

Edite /etc/bacula/bacula-fd.conf no nó PVE:

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

Passo 3: Reiniciar o Bacula File Daemon

systemctl restart bacula-fd
systemctl status bacula-fd

Passo 4: Verificar se o plugin foi carregado

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

6.3 Configuração do Usuário da API Proxmox

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

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

6.4 Obter o Fingerprint TLS

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

Anote este valor para o parâmetro pve_fingerprint em seus FileSets.

6.5 Configuração do Director

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

6.6 Verificar Conectividade

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

6.7 Configuração do Receptor de DR (Opcional)

No nó PVE secundário (site de DR), execute os mesmos passos de instalação (6.1–6.4). Nenhuma configuração adicional é necessária no receptor — o plugin inicia no modo receptor quando mode=receiver é especificado no FileSet.

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

7. Guia de Dimensionamento e Configuração

7.1 Dimensionamento de Componentes

Bacula Director

Nível CPU RAM Armazenamento (Catálogo) Observações
Mínimo 4 vCPU 8 GB 500 GB Até 50 VMs, retenção de 30 dias
Recomendado 8 vCPU 16 GB 2 TB Até 500 VMs, retenção de 90 dias
Grande Escala 16 vCPU 32 GB 10 TB+ 1000+ VMs, retenção de 1 ano

Bacula Storage Daemon

Nível CPU RAM Throughput de Disco Observações
Mínimo 4 vCPU 8 GB 500 MB/s <10 streams de backup simultâneos
Recomendado 8 vCPU 32 GB 2+ GB/s Até 50 streams simultâneos
Grande Escala 16+ vCPU 64 GB 10+ GB/s 100+ streams simultâneos

Bacula File Daemon (no Nó PVE)

Nível CPU RAM Observações
Mínimo 2 vCPU 4 GB Compartilhado com a sobrecarga do PVE
Recomendado 4 vCPU 8 GB Permite backups de VMs em paralelo

Rede

Cenário Mínimo Recomendado
Backup local (PVE para SD na mesma rede) 1 Gbps 10 Gbps
Replicação de DR (entre sites) 100 Mbps 1 Gbps
Replicação de DR via WAN 10 Mbps (com compressão) 100 Mbps

7.2 Ajuste de Desempenho

Backups de VMs simultâneos: Defina Maximum Concurrent Jobs na configuração do FD. Cada backup de VM simultâneo utiliza aproximadamente 200–500 MB de RAM no backend para armazenamento em buffer.

Compressão: Ative a compressão no Bacula SD (Compression = LZ4 nas Opções do FileSet) para cargas de trabalho limitadas por CPU onde o throughput de disco é o gargalo.

Intervalo incremental: Para VMs muito ativas (altas taxas de gravação), intervalos incrementais mais curtos (por hora) produzem deltas menores por Job e backups mais rápidos.

8. Matriz de Compatibilidade

8.1 Versões de Componentes Validadas

Componente Versão Mínima Versão Testada Status de Validação
PodHeitor Backup 15.0.0 15.0.3 Validado em produção
Proxmox VE 8.0 8.4.18 Validado em produção
Debian (host PVE) 11 (Bullseye) 12 (Bookworm) Validado em produção
RHEL / Oracle Linux (Director) 8 9.6 Validado em produção
Ubuntu (Director/SD) 22.04 LTS 24.04 LTS Compatível (testado pela comunidade)
PostgreSQL (Catálogo) 13 14+ Validado em produção
QEMU (via PVE) 8.0 9.2 Validado
Linux Kernel (host PVE) 6.1 6.8 Validado

8.2 Compatibilidade com Hipervisor de Origem (Conversão)

Hipervisor de Origem Versão de Origem Status
VMware vSphere 6.7, 7.0, 8.0 Validado em produção
VMware Workstation 16, 17 Compatível
Microsoft Hyper-V 2019, 2022 Validado em produção
KVM / libvirt Qualquer Nativo (qcow2/raw)
VirtualBox 7.0 Compatível (exportação VMDK)

8.3 Compatibilidade com Backend de Armazenamento (PVE)

Tipo de Armazenamento Proxmox Backup Restauração Recuperação Instantânea Observações
local-lvm (LVM-thin) Sim Sim Sim Recomendado para produção
local (diretório) Sim Sim Sim Formato qcow2
NFS Sim Sim Limitado Desempenho de IR pode variar
Ceph RBD Sim Sim Sim Thin-provisioning nativo
ZFS Sim Sim Sim Amigável a snapshots

9. Referência de Parâmetros

9.1 Parâmetros de Conexão PVE

Parâmetro Aliases Padrão Obrigatório Descrição
pve_host pvehost, host — Sim Endereço IP ou hostname do nó PVE
pve_user pveuser, user root@pam Não Nome de usuário da API PVE (formato usuário@realm)
pve_password pvepassword, password — Sim Senha para o usuário da API PVE
pve_port pveport, port 8006 Não Porta HTTPS para a API REST do PVE
pve_realm pverealm, realm pam Não Realm de autenticação (pam, pve, ldap)
pve_fingerprint pvefingerprint, fingerprint — Recomendado Fingerprint SHA-256 do certificado TLS do PVE
pve_insecure pveinsecure no Não Defina como yes para desabilitar a verificação do certificado TLS (não recomendado)

9.2 Parâmetros de Seleção de VM

Parâmetro Aliases Padrão Obrigatório Descrição
vm — * Não VMID, nome da VM ou padrão curinga. * seleciona todas as VMs no nó
exclude — (nenhum) Não Lista de VMIDs separados por vírgula para excluir do backup
node — (hostname) Não Direcionar para um nó específico do cluster PVE pelo nome

9.3 Parâmetros de Backup

Parâmetro Aliases Padrão Obrigatório Descrição
mode — backup Não Modo de operação: backup, receiver, seed, incremental
backup_type — full Não Nível de backup: full, incremental, differential
quiesce — yes Não Emitir guest-fsfreeze antes do snapshot para consistência da aplicação
include_config — yes Não Incluir o arquivo de configuração da VM no backup
include_firewall — yes Não Incluir as regras de firewall do PVE no backup
storage storageid bacula-store Não ID de armazenamento PVE onde os snapshots são mantidos temporariamente

9.4 Parâmetros NBD

Parâmetro Aliases Padrão Obrigatório Descrição
nbd_host nbdhost auto Não Hostname para o servidor NBD. auto utiliza o endereço do nó PVE
nbd_port nbdport 10809 Não Porta TCP para o servidor NBD

9.5 Parâmetros de DR / Replicação (conjunto completo v1.1.0)

Parâmetro Aliases Padrão Obrigatório Descrição
mode — backup Sim (para DR) bitmap-push / seed (origem) / receiver (DR) / daemon / failover-pre / failover-exec / failback-pre / failback-exec / reprotect / replication-status
dr_host drhost — Sim (origem) IP/hostname do nó PVE receptor de DR
dr_port drport 9100 + (vmid % 900) Não Porta TCP para o transporte DR. O padrão é derivado por VMID (ex.: 9203 para VMID 103)
target_vmid targetvmid, dr_vmid — Sim (origem) VMID a ser usado no site de DR para a réplica
target_storage targetstorage, dr_storage local-lvm Não Pool de armazenamento PVE no DR para volumes de réplica
dr_auth_token drauthtoken, dr_token — Não* Segredo compartilhado para transporte DR em modo PSK
dr_auth_cert drauthcert, dr_cert — Não* Caminho do certificado PEM para transporte DR em mutual-TLS (ativa o modo TLS)
dr_auth_key drauthkey, dr_key — Não* Caminho da chave privada PEM para mutual-TLS
dr_ca_cert drcacert (usa dr_auth_cert como fallback) Não Bundle de certificado CA usado para verificar o par
max_restore_points maxrestorepoints 3 Não Número máximo de snapshots de restore-point retidos no DR (os mais antigos são removidos automaticamente)
state_dir statedir /var/lib/bacula Não Diretório para os arquivos repl-state-*.json / dr-vm-state-*.json por VM
bitmap_granularity bitmapgranularity 65536 (64 KiB) Não Granularidade do dirty-bitmap do QEMU em bytes (potência de 2)
cycle_interval cycleinterval 300 (s) Não Modo daemon: segundos entre ciclos
throttle_bps throttlebps, throttle 0 (desligado) Não Limite de largura de banda para o transporte DR, em bytes/segundo
verify_sample_blocks verifysampleblocks 0 (desligado) Não v1.1.0: blocos aleatórios de 64 KiB para comparação por hash por ciclo

* dr_auth_token XOR (dr_auth_cert+dr_auth_key) — escolha um modo de autenticação.

9.6 Parâmetros de Restauração

Parâmetro Aliases Padrão Obrigatório Descrição
restore_path restorepath — Não Caminho local para extração da imagem de disco na restauração
new_vm_name newvmname — Não Nome para a VM restaurada (substitui o nome original)
target_storage targetstorage — Não ID de armazenamento PVE para os discos da VM restaurada
overwrite_vmid overwritevmid — Não VMID a ser sobrescrito na restauração (destrutivo; use com cautela)
start_vm startvm, power_on no Não Ligar a VM automaticamente após a conclusão da restauração

9.7 Parâmetros de Recuperação Instantânea

Parâmetro Aliases Padrão Obrigatório Descrição
ir_nbd_port irnbdport auto Não Porta NBD para exportação do disco de IR
ir_overlay_storage iroverlaystorage — Não Armazenamento PVE para o overlay de gravação durante a sessão de IR
ir_timeout irtimeout 3600 Não Timeout da sessão de IR em segundos antes da migração forçada
ir_auto_migrate irautomigrate no Não Iniciar automaticamente a migração em segundo plano após o boot da VM

10. Exemplos de Configuração

10.1 FileSet — Backup Completo de Todas as VMs

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

10.2 FileSet — Backup Incremental

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

10.3 FileSet — Remetente de Replicação DR

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

10.4 FileSet — Receptor DR

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

10.5 Exemplo Completo de Job, Schedule e Pool

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

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

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

10.6 Job de Recuperação Instantânea

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

11. Modelo de Segurança

11.1 Modelo de Ameaças

O plugin endereça quatro vetores de ameaça primários na infraestrutura de backup:

  1. Man-in-the-Middle na API PVE: Mitigado por fixação (pinning) de fingerprint de certificado SHA-256
  2. Acesso não autorizado ao backup: Mitigado pela autenticação do Bacula Director e validação de senha do FD
  3. Interceptação do transporte DR: Mitigado por PSK ou TLS mútuo no canal de transporte DR
  4. Exposição de credenciais: Mitigado pelo catálogo criptografado do Bacula e permissões restritas de arquivos

11.2 Fixação de Fingerprint TLS

Ao contrário da validação tradicional de certificados baseada em CA, a fixação de fingerprint verifica os bytes exatos do certificado do servidor de destino. Isso é particularmente adequado para implantações Proxmox onde certificados autoassinados são o padrão e o conjunto de servidores confiáveis é conhecido e estático.

Obtendo o fingerprint:

# Opção 1: Via OpenSSL no nó PVE
openssl x509 -in /etc/pve/pve-ssl.pem -noout -fingerprint -sha256

# Opção 2: Via interface web do PVE
# Dashboard -> Node -> Certificates -> Fingerprint (SHA-256)

11.3 Segurança do Transporte DR

Modo PSK (dr_auth_token): Autenticação HMAC em nível de sessão usando o token compartilhado. Recomendado para replicação entre sites no mesmo datacenter ou protegidos por VPN.

Modo TLS com Certificado (dr_auth_cert + dr_auth_key): TLS mútuo completo. Obrigatório para segmentos de rede não confiáveis (internet pública, interconexões cross-site em colocation).

11.4 Boas Práticas de Gerenciamento de Credenciais

  • Armazene senhas PVE no armazenamento criptografado de credenciais do Bacula ou use injeção por variável de ambiente
  • Use usuários de API dedicados com privilégios mínimos necessários (consulte a Seção 6.3) em vez de root@pam
  • Rotacione tokens de autenticação DR em intervalos regulares (trimestral é o recomendado)
  • Restrinja as permissões do diretório /usr/lib/bacula/plugins/ para root:bacula 750
  • Audite os logs do Bacula Director para tentativas de restauração não autorizadas

11.5 Recomendações de Segmentação de Rede

+-------------------+    TCP:9102     +--------------------+
| Bacula Director   +---------------->+  PVE Node FD       |
| (management net)  |                 | (hypervisor net)   |
+-------------------+                 +--------------------+
                                               |  TCP:9190
                                               v
                                      +--------------------+
                                      |  DR PVE Node FD    |
                                      | (DR site net)      |
                                      +--------------------+

Firewall rules required:
  Director -> PVE FD:   TCP 9102 inbound
  PVE FD -> Bacula SD:  TCP 9103 outbound
  PVE Primary -> PVE DR: TCP 9190 outbound
  PVE DR:               TCP 9190 inbound (from primary only)

12. Comparação Competitiva

12.1 Tabela Comparativa de Funcionalidades

Funcionalidade Plugin PodHeitor Veeam B&R Commvault Bacula Enterprise
Backup Proxmox VE Nativo Limitado (v12 beta) Somente via agente Nativo
CBT incremental QEMU dirty bitmaps VMware CBT CBT QEMU dirty bitmaps
Consistência de aplicação QEMU agent (fsfreeze) VSS/VMware tools VSS QEMU agent
Recuperação Instantânea Overlay NBD Instant VM Recovery Live Recovery Sim
Replicação DR Integrada Jobs de replicação Sim Limitado
Migração VMware para Proxmox Validado Não suportado Não suportado Não suportado
Migração Hyper-V para Proxmox Validado Não suportado Não suportado Não suportado
Fixação de fingerprint TLS Sim PKI completa obrigatória PKI completa obrigatória Sim
Integração com Bacula Plugin nativo Produto separado Produto separado Nativo
Sem daemons adicionais Sim Não Não Sim
Binário nativo Linux Sim (Rust, binário nativo) Windows primário Misto Sim

12.2 Licenciamento e Modelo de Custos

Solução Modelo de Licenciamento VMs Proxmox Custo de Entrada
Plugin PodHeitor Taxa fixa comercial por nó Ilimitado por nó Entre em contato para preços
Veeam B&R Por socket de workload ou por VM Cobrado por VM Custo elevado por VM
Commvault Por TB ou por core Por agente ou por TB Complexo, custo elevado
Bacula Enterprise Por front-end + módulos Módulo licenciado Assinatura anual
Proxmox PBS Gratuito / código aberto Ilimitado US$ 0 (sem integração com Bacula)

12.3 Simplicidade de Arquitetura

Solução Novos Componentes Necessários Servidor Dedicado Cross-Hypervisor
Plugin PodHeitor Apenas .so + binário de backend Não VMware + Hyper-V validados
Veeam Servidor VBR + VMs Proxy Sim (Windows) Suporte limitado a Proxmox
Commvault CommServe + MediaAgent + Agentes Sim Sim (licenciamento complexo)
Bacula Enterprise FD Enterprise + módulo de plugin Director (existente) Limitado

Diferencial-chave: O plugin PodHeitor não requer nenhuma nova infraestrutura. Se o PodHeitor Backup já estiver implantado, adicionar proteção Proxmox é uma cópia de arquivo e uma alteração de configuração.

12.4 Evidência em Laboratório — v1.1.0 (2026-04-24)

A seguir estão trechos reais de log capturados durante a execução do gate de pré-GA (transcrição completa em docs/GATE_REPORT_2026-04-24.md). Não são sintéticos — o JobId 3448 do localhost-dir é um Job real do Bacula Director no Director com Oracle Linux 9.6 em 192.168.15.105.

Seed de uma VM de 100 GB, origem → DR

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

No lado DR simultaneamente:

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

Verificação de integridade amostral em um incremental

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

Quinze ciclos consecutivos produziram 150 comparações de blocos amostrados, zero divergências (tabela completa em docs/GATE_REPORT_2026-04-24.md).

Ciclo de replicação com TLS mútuo

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

Failover planejado (inicialização da réplica no DR)

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

Job acionado pelo Bacula Director — saída real do bconsole

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

Instalação turnkey via .deb em nó DR Debian 13 PVE 9

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

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

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

Emissor JSON do dashboard — saída real

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

13. Análise de TCO e ROI

13.1 Cenário: Ambiente Proxmox com 100 VMs, TCO em 3 Anos

Premissa de base: A organização já executa o PodHeitor Backup para backup de arquivos e bancos de dados.

Opção A: Plugin PodHeitor para Proxmox

Item de Custo Ano 1 Ano 2 Ano 3
Licença do plugin (por nó, 2 nós) Entre em contato Renovação Renovação
Infraestrutura adicional US$ 0 US$ 0 US$ 0
Treinamento (equipe familiarizada com Bacula) Mínimo US$ 0 US$ 0

Opção B: Veeam Backup & Replication (Enterprise Plus)

Item de Custo Observações
Licença por VM (100 VMs) Cobrado anualmente, escala com o número de VMs
Servidor Proxy Veeam (Windows) Hardware + licença de SO obrigatórios
Treinamento de equipe Nova plataforma, novo console de gerenciamento
Manutenção e suporte Contrato anual obrigatório

Opção C: Apenas Proxmox Backup Server

Item de Custo Observações
Licença PBS US$ 0
Lacuna em relatórios de conformidade Custo de risco: sem catálogo de auditoria unificado
Lacuna em capacidades DR Custo de risco: sem orquestração DR empresarial

13.2 Fatores de ROI

Redução da janela de backup: Backups incrementais com CBT reduzem o volume de dados de backup em 90-98%, diminuindo a largura de banda de rede, a carga de I/O de armazenamento e a duração da janela de backup.

Redução do tempo de restauração: A Recuperação Instantânea elimina a lacuna de RTO. Uma restauração tradicional de 4 horas torna-se uma operação de boot via NBD de 5 minutos.

Eliminação de custos de migração: A conversão cross-hypervisor do VMware ou Hyper-V elimina a necessidade de ferramentas dedicadas de migração, que são licenciadas separadamente nos produtos concorrentes.

Economia com consolidação: Eliminar uma implantação paralela de PBS e usar o Bacula como catálogo único de backup reduz a sobrecarga administrativa, simplifica os relatórios de conformidade e elimina a alocação de armazenamento duplicada.

Estimativa de break-even: Em um ambiente típico de 50 VMs migrando do Veeam, o custo da licença do plugin geralmente é recuperado em 3-6 meses de taxas de renovação do Veeam economizadas.

14. Roadmap

Versão 1.1.0 — Lançada (GA, 2026-04-24) ✅

Funcionalidade Status
Replicação estilo Veeam (seed + incremental via bitmap-push) ✅
Verificação de integridade amostral (FNV-1a-64) entre origem e DR ✅
TLS mútuo (rustls + certificados PEM + WebPkiClientVerifier) ✅
Daemon receptor DR standalone (template systemd, sem bacula-fd no DR) ✅
Escalonamento de receptor multi-VM (uma instância por VMID via @.service) ✅
Failover planejado (failover-exec) + failback (failback-pre) ✅
Emissor JSON de dashboard (--mode=replication-status --vm=*) ✅
Pacotes turnkey .deb + .rpm ✅

Versão 1.1.1 — Planejada (refinamentos de curto prazo)

Funcionalidade Descrição Prioridade
Helper mkcerts.sh Gerador one-shot de CA X.509 v3 + certs DR + source Alta
Streams de backup criptografados AES-256 ponta-a-ponta no nível do plugin (caminho de backup) Alta
Limitação de largura de banda Limites por job e por nó para o transporte bitmap-push Alta
Relatórios CBT aprimorados Estatísticas de blocos alterados por VM no catálogo Bacula Média
API REST para orquestração API HTTP para acionar backups sem bconsole Média

Versão 1.2 — Planejada

Funcionalidade Descrição Prioridade
Suporte multi-cluster FileSet único direcionando múltiplos clusters PVE Alta
Containers Proxmox (LXC) Backup e replicação de containers LXC Alta
Restauração direta para S3 compatível Restaurar diretamente do S3/MinIO sem roteamento pelo SD Média
Scripts pre/post backup Scripts de hook por VM executados antes e após o backup Média
Verificação de integridade de disco completo (mode=verify-full) Auditoria periódica de hash do disco inteiro Média

Versão 2.0 — Futuro

Funcionalidade Descrição Prioridade
Proteção Contínua de Dados (CDP) Replicação quase em tempo real via journal de bloco QEMU Alta
Integração com web Bacularis Painéis nativos do Bacularis para status do plugin Alta
VMs HA em Cluster Proxmox VMs HA acompanhadas de forma transparente entre nós durante o backup Média
Backup de PV Kubernetes Proteção de PersistentVolumes em Kubernetes hospedado no Proxmox Média
Importação Azure/AWS Upload direto de imagens de VM convertidas para plataformas cloud Baixa

15. Conclusão

O Plugin PodHeitor para Backup, Replicação e Conversão Proxmox para o Bacula representa uma solução madura e validada em produção para um desafio empresarial real e urgente: estender uma estratégia unificada de backup ao Proxmox VE sem adotar plataformas adicionais, incorrer em custos de licenciamento por VM desproporcionais ou abrir mão de capacidades de DR e consistência de aplicação.

Com mais de 1.290 jobs de produção concluídos com sucesso, suporte a backups incrementais eternos via QEMU dirty bitmaps, replicação DR com segurança TLS e provisionamento automático de VMs, recuperação instantânea via overlay NBD e conversão cross-hypervisor validada do VMware e Hyper-V — este plugin entrega proteção de dados de nível empresarial a uma fração do custo das soluções concorrentes.

Organizações que já executam o PodHeitor Backup obtêm proteção completa de VMs Proxmox implantando dois arquivos binários e atualizando a configuração do Director. Não há novos servidores para provisionar, nenhum novo console de gerenciamento para aprender e nenhuma cobrança por VM para orçar.

Chamada para Ação

Pronto para avaliar o Plugin PodHeitor para Proxmox em seu ambiente?

Entre em contato com Heitor Faria para discutir seu ambiente específico, obter uma licença de prova de conceito ou agendar uma demonstração técnica:

Canal Contato
E-mail heitor@opentechs.lat
Telefone (EUA) +1 786 726-1749
WhatsApp (BR) +55 61 98268-4220

Engajamentos de prova de conceito estão disponíveis para oportunidades empresariais qualificadas. Validação de arquitetura de referência, suporte à instalação e desenvolvimento de funcionalidades personalizadas podem ser contratados comercialmente.

Licenciamento

PodHeitor Proxmox Backup Plugin é software proprietário, distribuído por assinatura. Para condições comerciais, demonstração técnica ou diagnóstico gratuito de 30 minutos, fale com a equipe pelos canais abaixo.

Pronto para avaliar?

16. Aviso Legal e Contato

OFERTA ESPECIAL — TRAGA SUA PROPOSTA DE RENOVAÇÃO

Você está avaliando ou renovando atualmente um contrato para Bacula Enterprise, Veeam, Commvault ou Netbackup?

Traga sua proposta e garantimos um desconto mínimo de 50% — com funcionalidades significativamente superiores.

O Plugin PodHeitor para Proxmox oferece backup nativo de VMs Proxmox, replicação DR, recuperação instantânea e migração cross-hypervisor em um único produto, integrado nativamente ao PodHeitor Backup — a uma fração do custo dos fornecedores legados de backup empresarial.

Contato:
Autor Heitor Faria
Empresa PodHeitor / OpenTechs
E-mail heitor@opentechs.lat
Telefone (EUA) +1 786 726-1749
WhatsApp (Brasil) +55 61 98268-4220

Aviso Legal:

Copyright 2026 Heitor Faria — Todos os Direitos Reservados.

Este whitepaper e o produto descrito são protegidos por direitos autorais. A reprodução, redistribuição ou divulgação deste documento ou de qualquer parte dele sem autorização por escrito de Heitor Faria é proibida.

O produto aqui descrito é licenciado comercialmente. Os direitos de avaliação, desenvolvimento e redistribuição são regidos pelo contrato de licença comercial aplicável. O uso não autorizado, engenharia reversa ou redistribuição de binários do plugin são proibidos.

Todas as marcas registradas mencionadas neste documento (Proxmox, Bacula, VMware, Veeam, Commvault, Veritas, Red Hat, Oracle, Debian, Microsoft Hyper-V) são propriedade de seus respectivos donos. Sua menção não implica qualquer afiliação ou endosso.

17. Apêndice

A. Glossário

Termo Definição
Bacula Programa de backup, restauração e verificação empresarial de código aberto, composto pelos componentes Director, Storage Daemon, File Daemon e Console.
Bacula Director Componente central de gerenciamento que dirige as operações de backup e restauração, mantém o catálogo e executa o agendador.
Bacula File Daemon (FD) Agente instalado no lado do cliente no sistema cujo backup está sendo feito. Para backups Proxmox, instalado no host hipervisor PVE.
Bacula Storage Daemon (SD) Componente responsável por ler e gravar dados de backup em volumes de armazenamento.
Plugin API do Bacula Interface de plugin de biblioteca compartilhada do Bacula, permitindo que código de terceiros estenda a funcionalidade do File Daemon.
CBT (Changed Block Tracking) Mecanismo pelo qual o QEMU rastreia quais extensões de disco foram escritas desde o último backup, viabilizando a transferência incremental de dados.
Canal de comunicação interno Canal de comunicação interno entre o plugin FD e o processo backend, usado para controle de jobs e transferência de dados.
PVE (Proxmox VE) Proxmox Virtual Environment — plataforma hipervisora de código aberto baseada em KVM e LXC, com API de gerenciamento integrada.
QEMU Emulador e virtualizador de máquinas de código aberto. O Proxmox VE usa QEMU/KVM para execução de VMs.
QMP (QEMU Monitor Protocol) Protocolo baseado em JSON sobre um socket de domínio Unix para controlar e consultar uma instância QEMU em execução.
NBD (Network Block Device) Protocolo para exportar dispositivos de bloco via TCP, usado pelo plugin para ler dados de disco de VM a partir de snapshots QEMU.
CBT Dirty Bitmap Estrutura de dados por disco do QEMU que registra quais extensões alinhadas a 64KB foram modificadas desde o último checkpoint de backup.
Quiesce / Freeze O processo de pausar as escritas do sistema de arquivos em uma VM antes da criação do snapshot, para garantir a consistência dos dados.
QEMU Guest Agent Daemon instalado dentro da VM que responde a comandos QMP do hipervisor, viabilizando fsfreeze/thaw para backups consistentes com a aplicação.
Fingerprint Pinning Técnica de segurança TLS em que o hash SHA-256 esperado do certificado de um servidor é fixado, prevenindo MITM mesmo com certificados autoassinados.
PSK (Pre-Shared Key) Método de autenticação em que um segredo compartilhado é configurado em ambas as partes comunicantes, usado para autenticação do transporte DR.
Recuperação Instantânea (IR) Técnica para inicializar uma VM diretamente a partir de seu volume de backup via overlay NBD, alcançando RTO quase zero antes da migração completa para o armazenamento local.
RPO (Recovery Point Objective) Perda máxima de dados aceitável medida em tempo. Um RPO menor exige backups mais frequentes.
RTO (Recovery Time Objective) Tempo máximo aceitável para restaurar o serviço após uma falha. A Recuperação Instantânea reduz drasticamente o RTO.
TCO (Total Cost of Ownership) Custo total de uma solução ao longo de sua vida útil, incluindo licenciamento, infraestrutura, treinamento e sobrecarga operacional.
DR (Disaster Recovery) Políticas e procedimentos para recuperar a infraestrutura de TI após uma falha grave ou desastre.
VMDK Formato de disco de máquina virtual VMware. Usado pelo vSphere e Workstation como formato nativo de disco de VM.
VHDX Formato Virtual Hard Disk Extended usado pelo Microsoft Hyper-V.
qcow2 QEMU Copy-On-Write versão 2 — formato nativo de disco do Proxmox VE com suporte a snapshots, criptografia e compressão.
LVM-thin Provisionamento thin do Logical Volume Manager — usado pelo armazenamento local-lvm do Proxmox para alocação eficiente de disco de VM.
Bacularis Interface de gerenciamento web para o Bacula, oferecendo GUI para gerenciamento de jobs, navegação no catálogo e relatórios.
PBS (Proxmox Backup Server) Produto de servidor de backup dedicado da Proxmox, otimizado para PVE mas sem integração em frameworks externos de backup.

B. Diagrama de Arquitetura de Referência (Ambiente de Produção)

Production Environment (Validated April 2026)
Network: 192.168.15.0/24

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

Jobs executed: 1290+ (all T = Terminated OK)
Schedule tested: 5-minute interval
DR replication: validated with TLS fingerprint pinning

C. Perguntas Frequentes

P: O plugin consegue fazer backup de VMs desligadas? R: Sim. VMs desligadas são copiadas diretamente de suas imagens de disco sem necessidade de criação de snapshot. O quiesce é automaticamente ignorado para VMs desligadas.

P: O que acontece se o QEMU guest agent não estiver instalado na VM? R: O plugin recorre ao backup crash-consistent (snapshot sem freeze). Um aviso é registrado em log. O backup é concluído com sucesso; a consistência de aplicação não é garantida, mas a consistência de crash é mantida.

P: Posso usar este plugin com o Bacula Enterprise? R: O plugin implementa a API padrão de plugins do Bacula e é compatível tanto com o PodHeitor Backup quanto com o Bacula Enterprise FD nas versões 15.0.0 e posteriores.

P: Quantas VMs podem ser copiadas simultaneamente? R: A concorrência é limitada pelo Maximum Concurrent Jobs no File Daemon e pelos recursos disponíveis do sistema no nó PVE. Testado com até 10 backups simultâneos de VMs em um nó PVE de 32 cores sem degradação de desempenho.

P: Os dados de backup são criptografados em repouso? R: A criptografia em repouso é tratada pela configuração de criptografia de volumes do Bacula Storage Daemon, que é independente deste plugin. O plugin integra-se de forma transparente com qualquer criptografia de SD configurada.

P: Posso restaurar para um nó PVE diferente do nó de origem do backup? R: Sim. Use os parâmetros target_storage e new_vm_name para restaurar em qualquer nó PVE onde o FD do plugin esteja instalado.

P: Este plugin suporta operações de cluster Proxmox (migração ao vivo durante o backup)? R: Atualmente, o plugin tem como alvo um nó específico. O backup ciente de cluster, acompanhando VMs entre nós, está no roadmap da Versão 2.0.

D. Referências

  • Documentação da API REST do Proxmox VE: https://pve.proxmox.com/pve-docs/api-viewer/
  • Referência do QEMU Monitor Protocol (QMP): https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html
  • Especificação do Protocolo NBD: https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
  • Referência da API de Plugin Bacula: https://www.bacula.org/bacula-web/developers-guide/plugin-api
  • Documentação do PodHeitor Backup: https://www.bacula.org/documentation/
  • QEMU Changed Block Tracking (CBT): https://qemu-project.gitlab.io/qemu/interop/bitmaps.html
  • Notas de Versão do Proxmox VE 8.4: https://pve.proxmox.com/wiki/Roadmap

Fim do Whitepaper

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

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

Deixe um comentário