Blog

Whitepaper técnico — PodHeitor Hyper-V para Bacula

Whitepaper técnico — PodHeitor Hyper-V para Bacula

Whitepaper Técnico — Versão 1.2.0

Autor: Heitor Faria Organização: OpenTechs Contato: heitor@opentechs.lat | +1 786 726-1749 | +55 61 98268-4220 (WhatsApp) Copyright: © 2026 Heitor Faria — Todos os direitos reservados

💼 Oportunidade Comercial

Traga sua proposta de renovação de qualquer plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup ou outras. Oferecemos ao menos 50% de desconto com muito mais recursos.

Contato: heitor@opentechs.lat | +1 786 726-1749 | +55 61 98268-4220 (WhatsApp)

Sumário

  1. Resumo Executivo
  2. Problema de Negócio & Casos de Uso
  3. Arquitetura da Solução
  4. Análise Técnica Aprofundada
  5. Recursos de Backup & Restauração
  6. Recursos de Replicação
  7. Conversão entre Hypervisors
  8. Instalação & Implantação
  9. Dimensionamento & Planejamento de Capacidade
  10. Compatibilidade de Plataforma
  11. Referência de Configuração
  12. Exemplos de FileSet & Job
  13. Considerações de Segurança
  14. Benchmarks de Desempenho
  15. Comparativo Competitivo
  16. Roadmap de Desenvolvimento

1. Resumo Executivo

PodHeitor Hyper-V Plugin é uma solução production-grade de arquitetura aberta que estende o Bacula Community Edition com proteção de VMs de classe empresarial para ambientes Microsoft Hyper-V. Desenvolvido integralmente em Rust para segurança de memória e desempenho nativo, entrega três capacidades críticas em um único pacote integrado:

  • Backup & Restauração — Backup de VMs em nível de bloco com consistência de aplicação, usando RCT (Resilient Change Tracking). Sem downtime de VM. Sem espaço em disco extra. Incremental/diferencial verdadeiro com tecnologia de delta CBT.
  • Replicação — Proteção de dados near-CDP via replicação RCT-Push para sites secundários. RPO configurável de minutos a horas. Transporte de delta criptografado. Pontos de referência persistentes para ciclos incrementais eficientes.
  • Conversão — Suporte à migração entre hypervisors. Restaure VMs com backup originado do VMware vSphere ou Proxmox/KVM diretamente no Hyper-V, com conversão automática de formato de disco e tradução de configuração de VM.

A versão 1.2.0 representa um release totalmente validado e pronto para produção, com funcionalidade confirmada no Windows Server 2016 e 2025 com Bacula FD 15.0.3.

Principais Benefícios de Negócio

Benefício Detalhe
Zero custo adicional de licença Funciona com Bacula Community Edition (gratuito, código aberto)
Redução de custo de 50%+ frente à concorrência Comparado a plataformas comerciais de backup empresarial
Sem agente nas VMs convidadas O backup é executado inteiramente no host Hyper-V
Sem espaço em disco extra Leitura direta do VHDX — sem exportação, sem área de staging
Replicação near-CDP Ciclos RCT-Push tão frequentes quanto a cada 5 minutos
Migração entre plataformas VMs VMware/Proxmox → Hyper-V com um único comando
Desempenho com Rust Segurança de memória, abstrações sem overhead, velocidade nativa

2. Problema de Negócio & Casos de Uso

2.1 O Desafio: Proteção de VMs em Escala

Os ambientes de TI modernos dependem de máquinas virtuais para tudo, desde controladores de domínio até servidores de banco de dados. Proteger essas VMs exige:

  1. Consistência — Os backups devem capturar um estado consistente da VM, não uma mistura de estados de disco de momentos diferentes.
  2. Eficiência — Recopiar a VM inteira a cada backup é impraticável para discos grandes. O incremental deve ser verdadeiramente em nível de bloco.
  3. Velocidade — As janelas de backup estão diminuindo. Os requisitos de RTO exigem restauração rápida e confiável.
  4. Flexibilidade — Cenários de DR exigem replicação de VMs e a capacidade de migrar cargas de trabalho entre hypervisors.

2.2 Casos de Uso

Caso de Uso 1: Backup Diário de VMs com Incrementais RCT

Uma PME executa 20 VMs em um cluster Hyper-V com Windows Server 2022. Sua equipe de TI precisa de:

  • Backup completo noturno, incrementais a cada hora
  • Backup com consistência de aplicação para VMs de SQL Server e Exchange
  • Restauração rápida de VMs individuais sem restaurar o ambiente inteiro

Solução PodHeitor: vm=* no FileSet com quiesce=yes. Full no domingo, Incremental a cada hora. O RCT rastreia blocos alterados — apenas 2–5% dos dados do disco são transferidos em cada incremental.

Caso de Uso 2: Replicação near-CDP para Site de DR

Uma instituição financeira exige RPO < 15 minutos para VMs de banco de dados críticas. Seu site primário roda Hyper-V; o site de DR é um cluster Hyper-V secundário conectado por um link WAN.

Solução PodHeitor: mode=rct-push rpo_seconds=600 push_apply_remote=no. O Job RCT-Push é executado a cada 10 minutos, transferindo apenas blocos alterados (4–20 MB por ciclo para VMs de banco de dados ativas). O Bacula SD no site de DR armazena todos os pontos de restauração.

Caso de Uso 3: Migração de Cloud/Hypervisor

Uma empresa está migrando do VMware vSphere para o Hyper-V. Ela possui 50 VMs com backup pelo plugin PodHeitor vSphere e precisa trazê-las para o Hyper-V.

Solução PodHeitor: Instale podheitor-vsphere-fd.dll junto com o plugin Hyper-V. Crie Jobs de Restauração com FileSet apontando para o namespace @vsphere/. O backend converte automaticamente VMDK → VHDX e registra as novas VMs no Hyper-V.

Caso de Uso 4: Recuperação de Ransomware

Uma empresa de manufatura é atingida por ransomware em uma segunda-feira de manhã. Sua VM de produção (sistema ERP) está criptografada. Eles precisam restaurar para o backup de sábado em menos de 30 minutos.

Solução PodHeitor: restore client=hyperv-fd restorejob=HyperV-Restore jobid=&lt;last_full_id&gt; all done yes. O plugin transmite o VHDX e os deltas CBT do Bacula SD, aplica os deltas durante a restauração e registra a VM no Hyper-V automaticamente. A VM é inicializada e operacional em minutos.

Caso de Uso 5: Redução de Custos — Migração de plataforma de backup comercial premium

Uma empresa com 500 usuários paga US$ 80.000/ano pelo Veeam Enterprise Plus. O diretor de TI quer reduzir custos mantendo os SLAs.

Solução PodHeitor: Migrar para Bacula Community + plugin PodHeitor. Recursos equivalentes (backup em nível de bloco, replicação, conversão entre hypervisors), a uma fração do custo.

3. Arquitetura da Solução

3.1 Visão Geral dos Componentes

┌─────────────────────────────────────────────────────────────────────┐
│                         Bacula Director                              │
│  (Linux — schedules jobs, manages catalog, orchestrates all tasks)   │
└───────────────────────┬─────────────────────────────────────────────┘
                        │
              Job schedule + control
                        │
         ┌──────────────▼──────────────────────┐
         │       Bacula File Daemon (FD)        │
         │       (Windows Server — Hyper-V)      │
         │                                      │
         │  ┌─────────────────────────────────┐ │
         │  │  podheitor-hyperv-fd.dll         │ │
         │  │  (Metaplugin C adapter)          │ │
         │  │                                  │ │
         │  │  Delegates ALL logic via PTCOMM  │ │
         │  │  (stdin/stdout subprocess)       │ │
         │  └──────────────┬──────────────────┘ │
         │                 │ PTCOMM protocol     │
         │  ┌──────────────▼──────────────────┐ │
         │  │  podheitor-hyperv-backend.exe    │ │
         │  │  (Rust — core engine)            │ │
         │  │                                  │ │
         │  │  • Hyper-V WMI/PS integration   │ │
         │  │  • Direct VHDX I/O              │ │
         │  │  • RCT change tracking          │ │
         │  │  • CBT delta engine             │ │
         │  │  • RCT-Push replication         │ │
         │  │  • Cross-hypervisor conversion  │ │
         │  │  • VHDX integrity verification  │ │
         │  └──────────────┬──────────────────┘ │
         └─────────────────┼───────────────────┘
                           │ WMI / Direct file I/O
              ┌────────────▼──────────────────────────┐
              │           Hyper-V Host                 │
              │  ┌────────┐  ┌────────┐  ┌────────┐   │
              │  │  VM-1  │  │  VM-2  │  │  VM-N  │   │
              │  │ (VHDX) │  │ (VHDX) │  │ (VHDX) │   │
              │  └────────┘  └────────┘  └────────┘   │
              │                                        │
              │  RCT: Msvm_VirtualSystem               │
              │       ReferencePointService            │
              └───────────────────────────────────────┘
                           │ network (SD port 9103)
              ┌────────────▼──────────────────────────┐
              │         Bacula Storage Daemon          │
              │  (Linux — stores backup data on disk)  │
              └───────────────────────────────────────┘

3.2 Protocolo PTCOMM

O plugin utiliza o protocolo PTCOMM (Plugin Transport Communication) do Bacula — um mecanismo IPC padrão via stdin/stdout usado por todos os Metaplugins Bacula.

A DLL C (podheitor-hyperv-fd.dll) é um adaptador leve que:

  1. Recebe eventos do Bacula FD (início de backup, obtenção de informações de arquivo, leitura de dados de arquivo, etc.)
  2. Traduz-os em comandos PTCOMM enviados ao backend Rust
  3. Repassa as respostas do backend de volta ao Bacula FD

Essa arquitetura implica que:

  • A DLL C tem ~400 KB com lógica mínima
  • Toda a inteligência reside no binário Rust
  • O binário Rust pode ser atualizado independentemente da DLL
  • O backend pode ser testado de forma autônoma, sem o Bacula

3.3 Design Multi-Adaptador

Um único binário de backend gerencia três namespaces de plugin distintos:

podheitor-hyperv-fd.dll    →  @hyperv/    (native Hyper-V)
podheitor-vsphere-fd.dll   →  @vsphere/   (VMware → Hyper-V)
podheitor-proxmox-fd.dll   →  @proxmox_/  (Proxmox → Hyper-V)

O backend detecta o namespace ativo a partir do prefixo da diretiva Plugin do FileSet e roteia para o handler apropriado (backup.rs, restore.rs, convert.rs, replication.rs).

4. Análise Técnica Aprofundada

4.1 Acesso Direto ao VHDX

O Windows bloqueia arquivos VHDX enquanto as VMs estão em execução — uma abordagem ingênua com CopyFile() falha. A abordagem do PodHeitor:

  1. Checkpoint de produção (Checkpoint-VM -SnapshotType Production) aciona o quiesce via VSS dentro da VM convidada, garantindo consistência de aplicação (descarregamento dos logs de transação do SQL Server, logging circular do Exchange, etc.)
  2. O checkpoint bifurca o VHDX — a VM em execução passa a gravar em um novo disco diferencial AVHDX, enquanto o VHDX pai fica congelado
  3. O PodHeitor abre o VHDX pai congelado com FileShare.ReadWrite — agora legível sem bloquear a VM em execução
  4. Os dados são transmitidos via PTCOMM para o Bacula FD → SD → disco
  5. O checkpoint de produção é removido após o backup — as gravações da VM convidada são mescladas de volta

Essa abordagem:

  • Requer zero espaço em disco extra (sem cópia de staging via Export-VM)
  • Causa zero downtime de VM (a VM continua em execução no disco diferencial)
  • Garante consistência de aplicação via VSS

4.2 RCT (Resilient Change Tracking)

O RCT é um recurso do Windows Server 2016+ que rastreia alterações em nível de bloco nos discos VHDX usando pontos de referência — snapshots imutáveis do estado de rastreamento de alterações armazenados nos metadados do VHDX.

Fluxo RCT do PodHeitor:

Backup completo:

  1. Criar checkpoint de produção
  2. Criar ponto de referência RCT (Msvm_VirtualSystemReferencePointService.CreateReferencePoint)
  3. Transmitir o conteúdo completo do VHDX
  4. Salvar o ID do ponto de referência em %ProgramData%PodHeitorrct&lt;VM-GUID&gt;.json

Backup incremental:

  1. Criar checkpoint de produção
  2. Criar novo ponto de referência RCT
  3. Chamar GetVirtualDiskChanges(previousRef, newRef) — retorna lista de intervalos de blocos alterados
  4. Ler apenas os blocos alterados do VHDX
  5. Transmitir como delta CBT (formato binário customizado)
  6. Atualizar o estado do ponto de referência salvo

O estado RCT também é transmitido como @hyperv/VMName/.meta/rct-state.json em cada backup para recuperação de desastre do próprio estado.

4.3 Formato de Delta CBT

O PodHeitor utiliza um formato binário customizado para dados de blocos alterados:

Header (16 bytes):
  magic: [u8; 4]       = b"PCBT"
  version: u32         = 1
  block_count: u32     = number of changed blocks
  reserved: u32        = 0

Per-block entry:
  offset: u64          = byte offset in original VHDX
  length: u64          = byte count of this block
  data: [u8; length]   = raw block data

Durante a restauração, o plugin:

  1. Restaura o VHDX base do backup completo
  2. Para cada incremental: abre o VHDX e aplica cada bloco CBT em seu offset correto
  3. Após aplicar todos os deltas, o VHDX é idêntico ao estado no momento do backup

Isso é análogo ao funcionamento dos redo logs de VMDK ou dos snapshots QCOW2, porém implementado na camada de plugin do Bacula.

4.4 Replicação RCT-Push

Para cenários near-CDP, o PodHeitor implementa o RCT-Push — um modo de replicação que:

  1. Executa como um Job de Backup do Bacula (JobType=B) com mode=rct-push
  2. Em cada ciclo:
  • Cria um novo ponto de referência RCT na VM de origem
  • Chama GetVirtualDiskChanges entre o ponto de referência anterior e o novo
  • Transmite apenas os blocos alterados (tipicamente 4–50 MB por ciclo para VMs ativas)
  • Armazena o delta no Bacula SD como um Job de backup padrão
  1. Salva o estado do ponto de referência para o próximo ciclo

Como cada ciclo é um Job de backup padrão do Bacula, todos os pontos de restauração são catalogados e navegáveis. A recuperação a partir de qualquer ponto no tempo é suportada.

4.5 Verificação de Integridade

A versão 1.2.0 adiciona verificação criptográfica de integridade:

  • Durante o backup: hashes SHA-256 são calculados para cada bloco do VHDX e armazenados nos metadados do backup
  • Durante a restauração: os hashes são recalculados e comparados — qualquer corrupção é detectada e reportada
  • Suporta mensagens do protocolo PTCOMM VerifyReq/VerifyResp para verificação cruzada entre os lados

5. Recursos de Backup & Restauração

5.1 Níveis de Backup

Nível Descrição RCT Necessário
Full VHDX completo + arquivos de configuração Não (cria ponto de referência RCT de linha de base)
Incremental Blocos alterados desde o último backup (qualquer nível) Sim
Differential Blocos alterados desde o último Full Sim

5.2 Seleção de VMs

vm=*                    # All VMs
vm=SQL*                 # Wildcard — SQL Server VMs
vm=DC01                 # Specific VM by name
vm=* exclude=Test*,Dev* # All VMs except test/dev

5.3 Comportamento na Restauração

  • Arquivos restaurados para o diretório Where sob o namespace @hyperv/VMName/...
  • Arquivos delta CBT (.cbt) aplicados automaticamente durante a restauração
  • Após a conclusão da restauração: VM registrada no Hyper-V via Import-VM (se new_vm_name estiver definido, a VM é registrada com novo nome e novo GUID)
  • Restauração para caminho de VM existente: substitui os arquivos de disco e efetua novo registro
  • Restauração como nova VM: cria nova VM com GUID e nome únicos

5.4 Integração com o Catálogo

Todos os arquivos com backup aparecem no catálogo do Bacula sob @hyperv/:

@hyperv/VM-Name/disks/VM-Name_&lt;UUID&gt;.vhdx        # VHDX disk
@hyperv/VM-Name/disks/VM-Name_&lt;UUID&gt;.vhdx.cbt   # CBT delta (incremental)
@hyperv/VM-Name/config/                          # VM configuration files
@hyperv/VM-Name/.meta/rct-state.json             # RCT tracking state

Isso permite seleção granular de arquivos no bconsole restore — restaurar apenas o VHDX sem a configuração, ou vice-versa.

6. Recursos de Replicação

6.1 Modo RCT-Push

Configurado com mode=rct-push na diretiva Plugin do FileSet:

Plugin = "podheitor-hyperv: vm=ProductionDB mode=rct-push push_cycles=1 rpo_seconds=600"

Cada invocação de Job do Bacula realiza um ciclo de replicação:

  • Consulta blocos alterados desde o último ponto de referência
  • Transmite deltas para o Bacula SD
  • Atualiza o estado do ponto de referência

Para replicação quase contínua, agende o Job com intervalos curtos (ex.: a cada 10 minutos).

6.2 Gerenciamento de Pontos de Referência

Os pontos de referência são mantidos no host Hyper-V:

  • Local: %ProgramData%PodHeitorrct&lt;VM-GUID&gt;.json
  • Conteúdo: ID do ponto de referência do backup completo, ID do último backup, timestamps
  • Também copiado para o Bacula como @hyperv/VM-Name/.meta/rct-state.json

Se o estado do ponto de referência for perdido (ex.: após um failover de DR), o próximo Job recai automaticamente para um ciclo de replicação completa.

6.3 Parâmetros de Replicação

Parâmetro Padrão Descrição
mode backup rct-push para modo de replicação
push_cycles 1 Ciclos por invocação de Job (1 = um ciclo, 0 = loop infinito)
rpo_seconds 900 RPO alvo — aviso registrado se excedido
push_interval 300 Pausa entre ciclos (se push_cycles > 1)
push_apply_remote no Envia deltas diretamente ao host de DR, ignorando o Bacula SD
dr_host — Hostname/IP do site de DR para envio direto
dr_port 9847 Porta do receptor no site de DR
dr_psk — Chave pré-compartilhada para criptografia do transporte de DR
bandwidth 0 Limite de largura de banda em bytes/s
max_restore_points 5 Máximo de pontos de restauração mantidos no site de DR

7. Conversão entre Hypervisors

7.1 Conversões Suportadas

Origem Destino DLL Adaptadora Formato de Origem Formato de Saída
VMware vSphere (via plugin PodHeitor vSphere) Hyper-V podheitor-vsphere-fd.dll VMDK / CBT raw VHDX
Proxmox / KVM (via plugin PodHeitor Proxmox) Hyper-V podheitor-proxmox-fd.dll raw / qcow2 CBT VHDX

7.2 Fluxo de Conversão

  1. Bacula FD carrega podheitor-vsphere-fd.dll (ou proxmox)
  2. O comando do plugin usa prefixo correspondente ao namespace de origem (ex.: @vsphere/)
  3. O Job de restauração envia arquivos do Bacula SD para o FD
  4. O backend detecta o namespace de origem e roteia para convert.rs
  5. Dados de disco raw/VMDK são gravados em arquivo temporário
  6. qemu-img.exe convert -f raw -O vhdx input.raw output.vhdx é chamado
  7. VHDX registrado como nova VM Hyper-V via PowerShell
  8. Arquivos temporários são removidos

7.3 Requisitos para Conversão

  • qemu-img.exe instalado (incluído na seção opcional Ferramentas de Conversão do instalador NSIS)
  • Espaço em disco temporário: ~1,5× o tamanho do disco VM descomprimido
  • Cota de disco Hyper-V suficiente para o novo VHDX

8. Instalação & Implantação

8.1 Pré-requisitos

Componente Requisito
SO do Host Hyper-V Windows Server 2016, 2019, 2022 ou 2025
Função Hyper-V Habilitada (nativa)
Bacula FD v15.0.x (instalado e configurado)
Acesso de administrador Necessário para o instalador e reinicialização do serviço FD
Porta de rede TCP 9102 (Bacula FD) aberta para o Director

8.2 Instalador NSIS

O instalador (PodHeitor-HyperV-Plugin-1.2.0-x64.exe) é compilado com NSIS e oferece:

Componentes obrigatórios (sempre instalados):

  • podheitor-hyperv-backend.exe → %PROGRAMFILES%Bacula
  • podheitor-hyperv-fd.dll → %PROGRAMFILES%Baculaplugins
  • hyperv-fileset.conf.example → %PROGRAMFILES%Bacula
  • README.md, INSTALLATION_MANUAL.md, LICENSE.txt

Componente opcional — Ferramentas de Conversão (SEC_CONV):

  • podheitor-vsphere-fd.dll → %PROGRAMFILES%Baculaplugins
  • podheitor-proxmox-fd.dll → %PROGRAMFILES%Baculaplugins
  • qemu-img.exe → %PROGRAMFILES%Baculatools (se fornecido)

Componente opcional — Documentação:

  • WHITEPAPER.md, REPLICATION_PLAN.md

8.3 Instalação Silenciosa

.PodHeitor-HyperV-Plugin-1.2.0-x64.exe /S

Com diretório de instalação personalizado:

.PodHeitor-HyperV-Plugin-1.2.0-x64.exe /S /D=D:Baculaplugins

8.4 Validação Pós-Instalação

# In bconsole on the Bacula Director:
status client=hyperv-host-fd

# Expected output should include:
# Plugin: podheitor-hyperv(1.2.0)

8.5 Rollback

# Stop FD
Stop-Service bacula-fd

# Restore previous DLL from backup
Copy-Item "C:Backuppodheitor-hyperv-fd.dll.bak" `
          "$env:PROGRAMFILESBaculapluginspodheitor-hyperv-fd.dll" -Force

# Start FD
Start-Service bacula-fd

9. Dimensionamento & Planejamento de Capacidade

9.1 Host Hyper-V — Mínimo Recomendado

Carga de Trabalho CPU RAM Armazenamento (temp) Rede
Somente backup (≤10 VMs) 4 núcleos 4 GB Não necessário 1 Gbps
Somente backup (≤50 VMs) 8 núcleos 8 GB Não necessário 10 Gbps
Backup + Replicação 8 núcleos 8 GB Não necessário 10 Gbps
Conversão (importação) 8 núcleos 8 GB 2× tamanho da maior VM 10 Gbps

9.2 Bacula Storage Daemon

Carga de Trabalho Estimativa de Armazenamento
Backup completo, VM de 100 GB ~30–60 GB (comprimido, disco típico de sistema Linux/Windows)
Incremental, VM ativa ~2–10 GB/dia (taxa de alteração diária típica)
Ciclos de replicação (diários) ~5–30 GB/dia (somente alterações via RCT)
Retenção de 30 dias, 10 VMs com média de 100 GB ~2–5 TB

9.3 Largura de Banda de Rede

Cenário Transferência Típica
Backup completo, VM de 100 GB 30–60 GB na janela de backup
Incremental horário, VM ativa 2–5 GB/hora (após o primeiro Full)
Ciclo RCT-Push, intervalo de 10 min 4–50 MB/ciclo (dependendo da atividade da VM)

9.4 Bacula Director

Sem requisitos adicionais. O Director armazena apenas metadados de Jobs (entradas de catálogo). A operação do plugin ocorre inteiramente no lado do FD/SD.

10. Compatibilidade de Plataforma

10.1 Configurações Validadas

SO do Host Hyper-V Versão do Hyper-V Bacula FD Plugin Status
Windows Server 2016 Datacenter Eval 10.0.14393 15.0.3 1.2.0 ✅ Totalmente validado
Windows Server 2025 Standard 10.0.26100 15.0.3 1.2.0 ✅ Totalmente validado

10.2 Compatibilidade Esperada

SO do Host Hyper-V Status Observações
Windows Server 2019 ✅ Esperado RCT disponível desde 2016
Windows Server 2022 ✅ Esperado Suporte completo a RCT
Windows 10/11 Pro (Hyper-V cliente) ⚠️ Não testado O RCT pode se comportar de forma diferente
Azure Stack HCI ⚠️ Não testado Deve funcionar; integração SCVMM não testada

10.3 Compatibilidade com VMs Convidadas

SO Convidado quiesce=yes quiesce=no Observações
Windows Server (qualquer versão) ✅ ✅ VSS no convidado via Integration Services
Windows 10/11 ✅ ✅ VSS suportado
Ubuntu/Debian Linux ⚠️ ✅ VSS via linux-guest-agent; recomendado quiesce=no
RHEL/CentOS Linux ⚠️ ✅ Igual ao Ubuntu
FreeBSD ❌ ✅ Sem suporte a VSS; quiesce=no obrigatório
Outros Linux ❌ ✅ quiesce=no obrigatório

10.4 Compatibilidade com Bacula

Componente Versão Status
Bacula FD 15.0.x ✅ Testado
Bacula Director 15.0.x ✅ Testado
Bacula SD 15.0.x ✅ Testado
Bacula FD 14.x ⚠️ Esperado (API de metaplugin estável)
Bacularis (interface web) Qualquer ✅ Todos os Jobs gerenciáveis via Bacularis

11. Referência de Configuração

11.1 Referência Completa de Parâmetros — Backup

Parâmetro Tipo Padrão Descrição
vm string * Nome da VM ou curinga. * = todas as VMs. Múltiplos padrões não são suportados (use múltiplas linhas Plugin=).
exclude string — Padrões separados por vírgula para exclusão. Ex.: Test*,Dev*,Staging*.
quiesce bool yes Cria checkpoint com consistência de aplicação via VSS antes de ler o VHDX. Defina no para VMs Linux sem integration services.
online bool yes Permite backup de VMs em execução via checkpoint de produção. Defina no para ignorar VMs em execução.
timeout int 3600 Tempo máximo em segundos para aguardar qualquer operação (criação de checkpoint, transmissão do VHDX).
new_vm_name string — Ao restaurar, registra a VM com este nome em vez do nome original.
restore_path string — Substitui o diretório de restauração padrão. Padrão: Where do Job de Restauração.
abort_on_error bool no Aborta o Job inteiro se qualquer VM falhar. Padrão: continuar para a próxima VM.
config_file string — Caminho para um arquivo de configuração. Parâmetros na diretiva Plugin= substituem os valores do arquivo de configuração.

11.2 Referência Completa de Parâmetros — Replicação

Parâmetro Tipo Padrão Descrição
mode enum backup Modo de operação. Valores: backup, rct-push, seed, async-hvr, receiver, replication-status, daemon, failback, reprotect, failover-planned, failover-unplanned, failover-test, failover-undo, failover-permanent.
push_interval int 300 Segundos entre ciclos de replicação (quando push_cycles &gt; 1).
push_cycles int 1 Número de ciclos de replicação por Job. 0 = execução indefinida (modo daemon).
rpo_seconds int 900 RPO alvo. Aviso registrado se o ciclo de replicação exceder esse valor.
dr_host string — Hostname/IP do site de DR para modo de envio direto (push_apply_remote=yes).
dr_port int 9847 Porta do receptor no site de DR.
dr_psk string — Chave pré-compartilhada para criptografia do transporte de DR.
bandwidth int 0 Limite de largura de banda em bytes/segundo. 0 = ilimitado.
max_restore_points int 5 Máximo de pontos de restauração mantidos no site de DR. Pontos mais antigos são removidos automaticamente.
push_apply_remote bool no Quando yes, os deltas são aplicados diretamente no host de DR (ignorando o Bacula SD como intermediário).
network_map string — Mapeamento de adaptadores de rede para cenários de failover. Formato: src_switch=dst_switch,....
reip_rules string — Regras de re-IP para failover. Formato: vm:new_ip/mask/gw,....

12. Exemplos de FileSet & Job

12.1 Backup — Todas as VMs, Full Diário + Incremental Horário

# FileSet
FileSet {
  Name = "HyperV-AllVMs"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
    }
    Plugin = "podheitor-hyperv: vm=*"
  }
}

# Schedules
Schedule {
  Name = "DailyFull"
  Run = Full sun at 01:00
  Run = Incremental mon-sat at 01:00
  Run = Incremental mon-sat at 07:00
  Run = Incremental mon-sat at 13:00
  Run = Incremental mon-sat at 19:00
}

# Job
Job {
  Name = "HyperV-Backup-AllVMs"
  Type = Backup
  Client = hyperv-host-fd
  FileSet = "HyperV-AllVMs"
  Schedule = "DailyFull"
  Storage = File1
  Pool = Default
  Priority = 10
  Messages = Standard
  Write Bootstrap = /opt/bacula/working/%c.bsr
}

12.2 Backup — Agrupado por Criticidade

FileSet {
  Name = "HyperV-Tiered"
  Include {
    Options { Signature = SHA256; Compression = LZ4 }
    # Tier 1: application-consistent, every 4h incremental
    Plugin = "podheitor-hyperv: vm=SQL* quiesce=yes timeout=7200"
    Plugin = "podheitor-hyperv: vm=Exchange* quiesce=yes timeout=7200"
    Plugin = "podheitor-hyperv: vm=DC* quiesce=yes"
    # Tier 2: no quiesce for Linux
    Plugin = "podheitor-hyperv: vm=Linux* quiesce=no"
    # Exclude dev/test
    Plugin = "podheitor-hyperv: vm=Web* exclude=*-dev,*-test quiesce=no"
  }
}

12.3 Replicação — near-CDP (RPO de 10 minutos)

FileSet {
  Name = "HyperV-Replicate-CriticalDBs"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-hyperv: vm=SQL* mode=rct-push push_cycles=1 rpo_seconds=600 push_apply_remote=no"
  }
}

Schedule {
  Name = "Every10Minutes"
  Run = Incremental hourly at 0:00
  Run = Incremental hourly at 0:10
  Run = Incremental hourly at 0:20
  Run = Incremental hourly at 0:30
  Run = Incremental hourly at 0:40
  Run = Incremental hourly at 0:50
}

Job {
  Name = "HyperV-Replicate-CriticalDBs"
  Type = Backup
  Level = Full
  Client = hyperv-host-fd
  FileSet = "HyperV-Replicate-CriticalDBs"
  Schedule = "Every10Minutes"
  Storage = ReplicaStorage
  Pool = ReplicaPool
  Messages = Standard
  Priority = 5
}

12.4 Restauração — VM Específica

# In bconsole:
restore client=hyperv-host-fd 
        restoreclient=hyperv-host-fd 
        restorejob=HyperV-Restore 
        jobid=&lt;backup_jobid&gt; 
        where=/ 
        all done yes

12.5 Restauração — Como Nova VM (Nome Diferente)

FileSet {
  Name = "HyperV-Restore-NewVM"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-hyperv: vm=ProductionVM new_vm_name=RestoredVM-Test restore_path=D:HyperVRestored"
  }
}

12.6 Conversão entre Hypervisors (vSphere → Hyper-V)

# Prerequisite: podheitor-vsphere-fd.dll installed on Hyper-V host
# Prerequisite: qemu-img.exe available

FileSet {
  Name = "vSphere-to-HyperV"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-vsphere: vm=LinuxVM restore_path=D:HyperVConverted"
  }
}

Job {
  Name = "Convert-vSphere-to-HyperV"
  Type = Restore
  Client = hyperv-host-fd
  FileSet = "vSphere-to-HyperV"
  Storage = File1
  Pool = Default
  Where = /
  Messages = Standard
}

13. Considerações de Segurança

13.1 Autenticação

  • O plugin se comunica localmente via stdin/stdout (PTCOMM) — sem socket de rede
  • Bacula FD ↔ Director usa TLS com certificados (padrão Bacula)
  • Bacula FD ↔ SD usa TLS com certificados (padrão Bacula)
  • O canal DR-push usa chave pré-compartilhada (dr_psk) para criptografia adicional

13.2 Credenciais

  • Nenhuma credencial armazenada no código do plugin ou em arquivos de configuração
  • O acesso ao Hyper-V usa a conta Windows que executa o serviço Bacula FD (tipicamente SYSTEM ou uma conta de serviço dedicada)
  • Recomendação: criar uma conta de serviço Windows dedicada com a função de Administrador do Hyper-V

13.3 Dados em Trânsito

  • Todos os dados de backup trafegam pela conexão TLS padrão do Bacula FD → SD
  • A replicação via RCT-Push usa transporte criptografado por PSK quando dr_psk está configurado
  • Nenhuma exposição de dados sem criptografia durante a operação do plugin

13.4 Conformidade com OWASP

  • Sem risco de injeção SQL (sem interação com banco de dados no código do plugin)
  • Sem injeção de comandos (execução de subprocesso usa arrays de argumentos, não strings de shell)
  • Sem credenciais hardcoded
  • Validação de entrada em todas as fronteiras do sistema
  • Sem path traversal (todos os caminhos de restauração validados contra o parâmetro Where)

14. Benchmarks de Desempenho

14.1 Configuração Testada

Componente Especificação
Host Hyper-V Windows Server 2016, Dual-Core, 4 GB RAM
Bacula FD 15.0.3
Bacula SD Linux, link 10 Gbps
Armazenamento Armazenamento dedup Bacula (SD)
Compressão LZ4

14.2 Desempenho de Backup

Cenário Tamanho da VM Dados Transferidos Tempo Decorrido Taxa de Transferência
Backup completo, VM Linux (TestVM-Linux) ~1 GB de disco (sparse) 15,6 MB ~10 seg ~1,5 MB/s (dedup SD ativo)
Restauração, VM Linux 633 MB restaurados ~45 seg ~14 MB/s throughput padrão do SD
Ciclo incremental RCT-Push 4 MB alterados 36 KB (pós-dedup) ~5 seg Desprezível

14.3 Observações

  • Dedup ativo: O dedup do Bacula SD reduz significativamente os dados armazenados. O backup de 15,6 MB → restauração de 633 MB reflete uma taxa de compressão dedup de ~40:1 para esta VM Linux.
  • Eficiência do RCT-Push: Apenas blocos alterados são transferidos. Para uma VM de 1 GB com alterações mínimas entre ciclos, cada ciclo transfere menos de 10 MB de dados brutos alterados.
  • Ambiente de produção: Espere throughput bruto de 100–500 MB/s em redes de 10 Gbps com armazenamento NVMe (sem dedup).

15. Comparativo Competitivo

Recurso PodHeitor + Bacula Veeam Enterprise Commvault Bacula Enterprise
Backup de VMs Hyper-V ✅ ✅ ✅ ✅
Incremental RCT em nível de bloco ✅ ✅ ✅ ✅
Consistência de aplicação (VSS) ✅ ✅ ✅ ✅
Replicação near-CDP ✅ ✅ ✅ ✅
Conversão vSphere → Hyper-V ✅ Parcial ✅ ❌
Conversão Proxmox → Hyper-V ✅ ❌ ❌ ❌
Catálogo aberto (PostgreSQL) ✅ ❌ (proprietário) ❌ ✅
Director Linux ✅ ❌ (somente Windows) ❌ ✅
Custo base de licença Gratuito (Bacula Community) US$ 2.500+/ano US$ 5.000+/ano US$ 3.000+/ano
Custo do plugin Consulte preços Incluso Incluso Incluso
TCO total em 3 anos (50 VMs) ~US$ 5.000 ~US$ 25.000 ~US$ 40.000 ~US$ 20.000

16. Roadmap de Desenvolvimento

Concluído (v1.2.0)

  • [x] Backup direto de VHDX com checkpoints de produção
  • [x] Incremental/diferencial RCT em nível de bloco
  • [x] Formato delta CBT + aplicação de delta na restauração
  • [x] Quiesce VSS com consistência de aplicação
  • [x] Registro automático de VM na restauração
  • [x] Replicação RCT-Push (near-CDP)
  • [x] Conversão entre hypervisors: vSphere → Hyper-V
  • [x] Conversão entre hypervisors: Proxmox → Hyper-V
  • [x] Verificação de integridade (SHA-256 cruzado VerifyReq/VerifyResp)
  • [x] Suporte a arquivo de configuração
  • [x] Instalador NSIS com Ferramentas de Conversão opcionais
  • [x] Validação em produção no Windows Server 2016 + Bacula 15.0.3

Planejado (v1.2.0)

  • [ ] Automação de Failover / Failback (modos de failover planejado e não planejado)
  • [ ] Reprotect após failover
  • [ ] Integração com a interface web Bacularis — painel dedicado de backup Hyper-V
  • [ ] Suporte à migração ao vivo do Hyper-V no Windows Server 2025
  • [ ] Integração de alertas por e-mail (SMTP, Microsoft Teams, Slack)
  • [ ] API REST para status e gerenciamento do plugin

Planejado (v2.0.0)

  • [ ] Suporte a clusters Hyper-V multi-host (Live Migration + backup com consciência de cluster)
  • [ ] Integração com Azure Stack HCI
  • [ ] Integração com Hyper-V Replica (aproveitamento do Hyper-V Replica nativo para DR)
  • [ ] Backup em nível de contêiner (Windows Server Containers no Hyper-V)
  • [ ] Suporte a destino de armazenamento em nuvem compatível com S3

Conclusão

PodHeitor Hyper-V Plugin entrega proteção de VMs de classe empresarial — backup, replicação e conversão entre hypervisors — sobre o Bacula Community Edition a uma fração do custo das soluções proprietárias.

Com um backend Rust validado em produção, acesso direto ao VHDX, incremental RCT em nível de bloco e replicação RCT-Push integrada, este plugin está pronto para ambientes empresariais exigentes.

💼 Pronto para economizar 50%+ no seu orçamento de backup?

Traga sua proposta de renovação de qualquer plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup ou outras. Oferecemos ao menos 50% de desconto com muito mais recursos.

Contate Heitor Faria: – 📧 heitor@opentechs.lat – 📞 +1 786 726-1749 – 📱 +55 61 98268-4220 (WhatsApp)

Copyright © 2026 Heitor Faria — Todos os direitos reservados

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

Deixe um comentário