Blog

Whitepaper técnico — PodHeitor vSphere para Bacula

Backup image-level via VADP + CBT, replicação push CBT-based com 10 modos DR, restore cross-hypervisor (vSphere ↔ Hyper-V ↔ Proxmox), e o pacote VDDK runtime RPM com RPATH=$ORIGIN que evita poluir o ld.so do host.

Documento técnico complementar à página do plugin PodHeitor vSphere.

1. Problema: Bacula stock não fala VADP

Bacula Community por design não tem cliente VADP nem CBT. Backup de VMs ESXi via FD stock se reduz a:

  • Backup do datastore montado no host FD — captura VMDKs em estado inconsistente, sem snapshot, sem CBT.
  • Bacula Enterprise vSphere plugin — existe, mas a preço enterprise e sem replicação DR cross-site nem 10 modos de failover.
  • Veeam standalone — paralelo ao Bacula, com ferramentas, RPO, scripting e licenças separadas. Duplica TCO.

O PodHeitor vSphere BRC consolida backup, replicação e conversão cross-hypervisor em um único plugin Bacula, com integração VADP + VDDK 9.0 nativa.

2. Modelo arquitetural

Bacula FD → Rust cdylib plugin (.so) → Rust backend binary (PTCOMM pipe)
                                          ↕
                                     vSphere SOAP API (via reqwest)
                                          ↕
                                     VDDK 9.0 (FFI — read/write VMDK blocks)

O .so é uma cdylib Rust pura construída a partir do workspace PodHeitor Rust cdylib (crate plugin-vsphere). Implementa o ABI C do plugin Bacula FD via crate bacula-fd-abi reimplementado independentemente — nenhum source tree do Bacula é necessário para build, e nenhum objeto AGPLv3 do Bacula é vinculado ao binário. O .so spawna o backend Rust como subprocesso e usa PTCOMM (status_char + 6-digit length + newline + payload) sobre stdin/stdout.

3. Modos de transporte VADP

A leitura de VMDKs via VADP suporta quatro modos; o plugin os expõe via parâmetro transport:

Mode Quando usar Tradeoff
nbd Lab, sem TLS exigido Texto-claro; fácil debug
nbdssl (default) Produção, sem SAN compartilhada TLS sobre NBD; CPU overhead aceitável
hotadd FD rodando como VM no mesmo cluster ESXi Discos da VM-target hot-add no FD-VM; LAN-free
san FD com acesso direto ao SAN/iSCSI da VM LAN-free puro; máximo throughput

4. CBT — Changed Block Tracking

VADP CBT é a feature da VMware que permite a um cliente perguntar “que blocos mudaram desde o ChangeId X?”. O plugin a usa em todos os Incrementals/Diferenciais:

  1. Snapshot consistente da VM (com quiesce=true default — VMware Tools quiesce filesystem).
  2. Query CBT contra o snapshot anterior — retorna lista de extents {offset, length}.
  3. Lê via VDDK apenas esses extents.
  4. Stream-a para a PTCOMM com offsets preservados.
  5. Remove snapshot (com snapshot_delete_delay opcional para grandes commits).

Parâmetro keep_cbt=true evita reset do estado CBT após backup — útil quando múltiplos jobs Bacula consomem o mesmo CBT em paralelo.

5. Replicação CBT-Push e os 10 modos DR

O plugin implementa replicação push baseada em CBT com daemon receiver persistente do lado DR. O parâmetro mode= seleciona uma de dez operações:

Mode Função
replication-status Mostra status e last sync time
seed Replicação full inicial (seed da réplica)
cbt-push Push CBT deltas para a réplica remota
failover-test Boot da réplica em rede isolada (não-destrutivo)
failover-undo Desfaz test failover, power off da réplica
failover-planned Failover graceful: sync → shutdown source → boot replica
failover-unplanned Failover de emergência: boot da réplica imediatamente
failover-permanent Failover permanente: réplica vira produção
failback Replicação reversa do replica de volta ao source
reprotect Re-estabelece replicação após failback

Todo o workflow Veeam SRM-style (test → planned → reprotect) está disponível como modos do plugin, dirigíveis pelo Bacula Director sem produto extra.

5.1 Network mapping e Re-IP

Parâmetro Formato Função
net_map "source_net=target_net" Reconfigura NICs da réplica no failover
reip "nic:ip/prefix:gw:dns1,dns2" Reconfigura IP guest da réplica no failover
storage_map "source_ds=target_ds" Mapeamento de datastore
test_failover_network nome de rede Rede isolada para test failover (não polui produção)

5.2 TLS para canal DR

Suporta dr_tls_cert + dr_tls_key (PEM) com rustls; dr_tls_insecure=true aceita self-signed (apenas para lab). PSK token via dr_auth_token obrigatório em todos os modos.

6. VDDK runtime RPM — por que é importante

VDDK é distribuído pela VMware como tarball com libcrypto.so.3/libssl.so.3/libcurl.so.4 bundled. Instalações antigas escreviam /etc/ld.so.conf.d/vmware-vddk.conf apontando para esses libs — fazendo todo processo no host (incluindo rpm, dnf, flatpak) carregar o libcrypto da VMware em vez do system OpenSSL. Sintoma típico:

flatpak: /usr/lib/vmware-vix-disklib/lib64/libcrypto.so.3: 
    version `OPENSSL_3.4.0' not found (required by /lib64/librpmio.so.9)

O podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm resolve isso em build time: cada .so em /usr/lib/vmware-vix-disklib/lib64 é patcheado com RPATH=$ORIGIN, então VDDK resolve seus siblings do próprio diretório sem poluir o ld.so do host. O scriptlet %post remove qualquer /etc/ld.so.conf.d/vmware-vddk*.conf, vixlib*.conf ou flatpack*.conf stale e re-executa ldconfig.

Recovery sem internet (host já quebrado por instalação legacy):

sudo rm -f /etc/ld.so.conf.d/vmware-vddk.conf 
           /etc/ld.so.conf.d/vmware-vix-disklib.conf 
           /etc/ld.so.conf.d/*vixlib*.conf 
           /etc/ld.so.conf.d/*flatpack*.conf
sudo ldconfig
sudo rpm -Uvh releases/podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm

7. Cross-restore (vSphere ↔ Hyper-V ↔ Proxmox)

O plugin participa de duas pernas do triângulo cross-hypervisor:

  • Como source: backups VMware podem ser restaurados em Hyper-V ou Proxmox via os plugins-irmãos PodHeitor Hyper-V / PodHeitor Proxmox.
  • Como target: backups Hyper-V/Proxmox podem ser restaurados em vSphere via este plugin (com conversão VHDX → VMDK e qcow2 → VMDK).

8. Compatibilidade

Componente Versões suportadas
VMware ESXi 7.0, 8.0, 8.0U3
VMware vCenter 7.0, 8.0
VDDK 8.0.x, 9.0.x
Bacula Community 15.0.x
OS (FD server) Oracle Linux 9, RHEL 9, Rocky 9, AlmaLinux 9
Arquitetura x86_64

9. Validação em laboratório

  • ESXi 8.0U3e standalone host, VDDK 9.0.1 em Oracle Linux 9.5, Bacula Community 15.0.3.
  • 4 VMs com CBT habilitado (Alpine, TinyCore, CirrOS, multi-disk).
  • 12/12 testes de replicação PASSED (abril 2026).
  • v1.4.1: lab job 6442 restaurou 2,147 GB / 4 arquivos em 6s, 0 erros FD; VM Alpine 3.21 restaurada bootou clean.

10. Anti-patterns documentados

  • Não deixe dr_tls_insecure=true em produção. Aceita self-signed certs do canal DR — útil em lab; risco de MITM em prod.
  • Não use force_san=true sem zoneamento SAN correto. O FD precisa enxergar os LUNs da VM target diretamente; misconfiguration causa I/O errors confusos.
  • Não rode quiesce=false em VMs com DBs. Snapshot crash-consistent → DBs precisam recovery no boot da réplica/restore.

11. License posture

Plugin sob LicenseRef-PodHeitor-Proprietary. Desde v1.4.0, o .so é cdylib Rust pura — nenhum source AGPLv3 do Bacula é vinculado estaticamente. Releases anteriores linkavam objetos pluginlib/metaplugin C++ do Bacula tree — não mais o caso. Bindings via crate clean-room bacula-fd-abi.

Pronto para avaliar?

Trial gratuito de 30 dias para frotas vSphere em produção. Garantimos no mínimo 50% de desconto vs Bacula Enterprise, Veeam ou Commvault, com 10 modos DR e restore cross-hypervisor inclusos.

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

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

Deixe um comentário