Blog

Acesso direto a VHDX sem Export-VM, change tracking via RCT (Resilient Change Tracking), replicação RCT-Push near-CDP, conversão cross-hypervisor (vSphere/Proxmox → Hyper-V) e arquitetura multi-adapter.

Documento técnico complementar à página do plugin PodHeitor Hyper-V.

1. Problema: backup de Hyper-V sem plugin é caro ou frágil

VMs Hyper-V em produção apresentam três problemas fundamentais para Bacula stock:

• VHDX bloqueado enquanto a VM roda — leitura direta do arquivo é impossível sem produção checkpoint. Bacula stock não sabe disso.
• Export-VM duplica storage — exigir um Export-VM antes do backup duplica a frota em disco e não escala.
• Sem change tracking nativo no Bacula — todo “incremental” rebaixa para re-leitura do VHDX inteiro. 2 GB modificados em 100 GB de disco viram 100 GB transferidos.

O PodHeitor Hyper-V Plugin endereça os três problemas com leitura in-place do VHDX (zero staging adicional), RCT block-level via WMI, e replicação delta near-CDP para sites secundários.

2. Modelo arquitetural

O plugin usa o padrão PodHeitor de cdylib + backend standalone, com PTCOMM em stdin/stdout. No Windows o cdylib é uma DLL (podheitor-hyperv-fd.dll) carregada por bacula-fd, e o backend é podheitor-hyperv-backend.exe.

Bacula FD (Windows)
  └─ podheitor-hyperv-fd.dll  (metaplugin adapter)
       │  PTCOMM (stdin/stdout)
       ▼
     podheitor-hyperv-backend.exe (Rust)
       ├─ Get-VM / Checkpoint-VM (PowerShell + WMI)
       ├─ Msvm_VirtualSystemReferencePointService (RCT API)
       ├─ Direct VHDX reader (no Export-VM)
       ├─ CBT delta encoder (proprietary binary format)
       ├─ RCT-Push replication driver
       └─ Cross-hypervisor convert (qemu-img.exe wrapper)

2.1 Multi-adapter design

Um único backend engine atende múltiplas DLLs cdylib, cada uma com um namespace Bacula distinto:

Operacionalmente: um único host Bacula FD pode ser destino de migração de qualquer hipervisor — sem reprovisionamento, sem instalar três produtos diferentes.

3. Direct VHDX + RCT — por que importa

4. RCT — Resilient Change Tracking

RCT é a API nativa Microsoft (Windows Server 2016+) para change tracking de discos virtuais. O plugin a consome via WMI:

• Reference points são marcadores persistentes (sobrevivem reboot do host Hyper-V) registrados em Msvm_VirtualSystemReferencePointService.
• A cada incremental/diferencial, o plugin pede a Hyper-V o diff entre dois reference points e recebe a lista de extents {offset, length} que mudaram.
• O plugin lê apenas esses extents do VHDX e os encapsula no formato CBT delta proprietário (binary stream com header de offset).
• No restore, o cdylib aplica os deltas em ordem cronológica sobre a base full.

Quando RCT não está disponível (geração 1 legacy, host antigo), o plugin cai automaticamente para full streaming do VHDX em vez de falhar — comportamento documentado como Gen1 fallback.

5. Replicação RCT-Push (near-CDP)

Configurado com mode=rct-push, o plugin executa ciclos contínuos de replicação direta para um host Hyper-V secundário, sem passar por Bacula SD em cada ciclo.

Com push_apply_remote=yes, o canal vai direto do FD source para o DR, sem trip pelo Storage Daemon Bacula — útil quando o objetivo é puramente DR e não retenção centralizada. Com =no, deltas vão pelo SD (catalogados) e são reaplicados no DR no próximo ciclo.

6. Conversão cross-hypervisor (vSphere / Proxmox → Hyper-V)

Restore de VMs feito por outros plugins PodHeitor diretamente em Hyper-V — sem reconversão manual de disco.

Tradução de configuração da VM (network adapters, boot order, detecção Gen1/Gen2) é automática. Pré-requisito: qemu-img.exe em %BACULA_DIR%tools ou no %PATH%; espaço temporário ~1,5× o tamanho comprimido da VM.

7. Granular restore (file-level)

Compatível com PodHeitor Granular Restore:

1. Browse no catálogo Bacula (BVFS) para localizar arquivos VHDX da VM.
2. Restore apenas do VHDX base + CBT deltas relevantes para o Storage Daemon.
3. Reconstrução do estado completo do disco aplicando CBT deltas sobre o VHDX base.
4. Mount do filesystem guest (NTFS, ext4, XFS, etc.) via libguestfs ou qemu-nbd.
5. Browse e extração de arquivos individuais.

8. Plataformas validadas

9. Anti-patterns documentados

• Não desabilite quiesce em VMs com aplicação stateful. Sem VSS quiesce, snapshot é crash-consistent — restore pode bootear, mas DBs podem precisar recovery.
• Não rode dois plugins concorrentes contra a mesma VM. RCT reference points são por-VM globais; concorrência cria reference point churn.
• Não confie em RCT em VMs Gen1 ou hosts < Windows Server 2016. O plugin faz fallback transparente para full VHDX streaming, mas o operador deve saber para dimensionar bandwidth/storage.

10. License posture

Plugin sob LicenseRef-PodHeitor-Proprietary. Nenhum source AGPLv3 do Bacula é vinculado estaticamente à DLL cdylib. O binding é via crate bacula-fd-abi (puro PodHeitor) com declarações extern "C" independentes.

Pronto para avaliar?

Trial gratuito de 30 dias para frotas Hyper-V em produção. Garantimos no mínimo 50% de desconto vs Bacula Enterprise, Veeam ou Commvault, com mais funcionalidades inclusas.

Heitor Faria — Fundador, PodHeitor International
✉ [email protected]
☎ +1 (789) 726-1749 · +55 (61) 98268-4220 (WhatsApp)
🔗 Página do plugin PodHeitor Hyper-V

Disponível em: PortuguêsEnglish (Inglês)Español (Espanhol)