Blog

Whitepaper técnico — PodHeitor vSphere para Bacula

Whitepaper técnico — PodHeitor vSphere para Bacula

Backup, Replicação e Conversão para VMware vSphere/ESXi no Bacula Community

Versão 1.4.1 — Abril de 2026 Autor: Heitor Faria Copyright © 2026 Heitor Faria — Todos os Direitos Reservados

💰 Oferta Especial

Traga sua cotação ou proposta de renovação do Bacula Enterprise, Veeam, Commvault ou Netbackup. Oferecemos pelo menos 50% de desconto, com muito mais recursos.

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

Sumário

  1. Sumário Executivo
  2. Definição do Problema e Contexto de Mercado
  3. Casos de Uso
  4. Arquitetura
  5. Recursos — Backup
  6. Recursos — Replicação e Recuperação de Desastres
  7. Recursos — Conversão entre Hipervisores
  8. Arquitetura de Segurança
  9. Guia de Instalação
  10. Referência de Configuração
  11. Exemplos de Configuração de Backup
  12. Exemplos de Configuração de Replicação
  13. Manual do Usuário e Operações do Dia a Dia
  14. Dimensionamento e Requisitos
  15. Matriz de Compatibilidade
  16. Resultados de Testes
  17. Comparativo com Soluções Corporativas
  18. Solução de Problemas
  19. Licenciamento e Contato

1. Sumário Executivo

PodHeitor vSphere BRC é um plugin production-ready para o Bacula Community Edition que oferece recursos enterprise-grade de backup, replicação e conversão entre hipervisores para VMware vSphere — a uma fração do custo das soluções comerciais.

Diferenciais

  • Três produtos em um: Backup + Replicação + Conversão em um único plugin
  • Nativo para Bacula Community: Não exige licença Enterprise
  • Replicação baseada em CBT: RPO quase em tempo real com consumo mínimo de banda
  • DR com 10 modos: Gerenciamento completo do ciclo de vida de failover
  • Restauração entre hipervisores: Conversão vSphere ↔ Hyper-V ↔ Proxmox/KVM
  • Protocolo DR com TLS: Segurança production-ready
  • Escrito em Rust: Segurança de memória, alto desempenho, FFI sem overhead com VDDK

Destaques da Versão 1.4.1

Correções completas de corretude na restauração — validadas contra ESXi 8.0.3 + Bacula 15.0.3 (job 6442 restaurou 2.147 GB / 4 arquivos em 6 s, 0 erros no FD; a VM Alpine 3.21 recriada inicializou corretamente):

Categoria Correção
🐛 Backup Caminhos de arquivo não são mais duplicados (@vsphere/@vsphere/disk-2000.vmdk → @vsphere/disk-2000.vmdk).
🐛 Restauração O prefixo Where= enviado pelo Bacula agora é capturado corretamente: um valor não vazio em Where direciona para restauração no sistema de arquivos; vazio// prossegue para restauração no hipervisor.
🐛 Restauração Entradas de diretório não encerram mais o loop de comandos PTCOMM externo com um EOD espúrio; diretórios usam um writer no-op.

Destaques da Versão 1.4.0

Categoria Recurso
⚖️ Licenciamento O plugin .so é agora uma cdylib pure-Rust — sem código-fonte AGPLv3 do Bacula vinculado. A ABI C é implementada por meio do crate bacula-fd-abi (reimplementado de forma independente a partir da especificação pública).
🛠 Build A compilação não exige mais a árvore de fontes do Bacula. cargo build --release -p plugin-vsphere a partir do workspace PodHeitor Rust cdylib gera o .so distribuído.
🧱 Arquitetura Barreira de licença preservada: cdylib em processo, backend Rust fora de processo via PTCOMM (isolamento de falhas + fronteira de licenciamento limpa).

Destaques da Versão 1.3.0

Categoria Recurso
🔐 Segurança Criptografia TLS para o protocolo DR (rustls)
🔐 Segurança Autenticação de token em tempo constante
🌐 Rede Mapeamento automático de rede no failover (ReconfigVM SOAP)
🌐 Rede Reconfiguração automática de IP no failover (CustomizeVM SOAP)
📸 Recuperação Pontos de restore baseados em snapshot na VM réplica
🔧 Operações Encerramento gracioso via SIGTERM no modo daemon

2. Definição do Problema e Contexto de Mercado

O Desafio

Organizações que utilizam VMware vSphere enfrentam desafios críticos de proteção de dados:

  1. Custo: O plugin vSphere do Bacula Enterprise custa $$$; Veeam, Commvault e Netbackup custam ainda mais
  2. Aprisionamento de Fornecedor: Soluções de backup corporativas prendem os clientes em renovações perpétuas caras
  3. Lacunas de Recursos: O Bacula Community não possui backup nativo para vSphere — apenas agentes em nível de sistema de arquivos
  4. Complexidade de DR: Configurar replicação e failover normalmente exige produtos separados
  5. Multi-Hipervisor: A migração entre vSphere, Hyper-V e KVM requer conversão manual

A Solução

O PodHeitor vSphere BRC elimina esses desafios ao oferecer:

  • Zero licenciamento Enterprise — funciona com o Bacula Community gratuito
  • Plugin tudo-em-um — backup, replicação e conversão unificados
  • Integração nativa com Bacula — usa configuração padrão de FileSet/Job/Schedule
  • DR automatizado — failover com um clique, com remapeamento de rede e reconfiguração de IP
  • Padrões abertos — conversão VMDK, VHDX e QCOW2 entre hipervisores

3. Casos de Uso

Caso de Uso 1: Backup de VM VMware

Cenário: A organização precisa de backup de VM em nível de imagem com CBT para incrementais eficientes.

Job: Full backup Sunday, Incremental daily
RPO: 24 hours (backup) / minutes (replication)
RTO: Minutes (instant restore) to hours (full restore)

Caso de Uso 2: Recuperação de Desastres

Cenário: Falha no site de produção — necessidade de inicializar VMs no site de DR imediatamente.

Normal operation: CBT push every 5 minutes
Planned failover: Sync → graceful shutdown → boot replica
Unplanned failover: Boot replica immediately from last sync point
Failback: Reverse-replicate once production is restored

Caso de Uso 3: Migração entre Hipervisores

Cenário: Migração do VMware para Proxmox/KVM devido a mudanças de licenciamento da Broadcom.

Backup: VMware VM → Bacula storage
Restore: Bacula → Proxmox (automatic VMDK→QCOW2 conversion)

Caso de Uso 4: Clonagem de Ambiente de Teste/Dev

Cenário: Clonar VMs de produção para uma rede de testes isolada.

Mode: failover-test (non-destructive)
Network: Isolated test VLAN
Result: Production unaffected, test VM available

Caso de Uso 5: Conformidade e Backup Multi-Site

Cenário: Requisito regulatório para cópias de backup fora do site principal.

Primary: Local backup to disk/tape
Secondary: CBT replication to remote DR site
Tertiary: Cross-restore to different hypervisor at third site

4. Arquitetura

Visão Geral dos Componentes

┌─────────────────────────────────────────────────────────────┐
│                     Bacula Director                          │
│  (Job scheduling, catalog, policy management)               │
└─────────────────┬───────────────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────────────┐
│                   Bacula File Daemon (FD)                    │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  podheitor-vsphere-fd.so (Rust cdylib, v1.4.1+)      │   │
│  │  • Loaded by Bacula FD via dlopen                    │   │
│  │  • Implements Bacula FD plugin C ABI through         │   │
│  │    independently-reimplemented bacula-fd-abi crate   │   │
│  │  • No Bacula AGPLv3 source linked                    │   │
│  │  • Spawns Rust backend via PTCOMM pipe                │   │
│  └──────────────────┬───────────────────────────────────┘   │
│                     │ stdin/stdout pipe                      │
│  ┌──────────────────▼───────────────────────────────────┐   │
│  │  podheitor-vsphere-backend (Rust binary)              │   │
│  │                                                       │   │
│  │  ┌─────────────────────────────────────────────────┐  │   │
│  │  │  Backup Module        │  Restore Module         │  │   │
│  │  │  • VADP workflow      │  • Full VM restore      │  │   │
│  │  │  • CBT tracking       │  • Single disk restore  │  │   │
│  │  │  • Snapshot lifecycle  │  • Cross-restore (VHDX) │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  Replication Module (1500+ lines)               │  │   │
│  │  │  • CBT push (async replication)                 │  │   │
│  │  │  • Seed (initial full sync)                     │  │   │
│  │  │  • 10-mode failover lifecycle                   │  │   │
│  │  │  • TLS-encrypted DR protocol                    │  │   │
│  │  │  • DR receiver daemon                           │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  vSphere API Client                             │  │   │
│  │  │  • SOAP/XML over HTTPS                          │  │   │
│  │  │  • Property collector                           │  │   │
│  │  │  • Task manager                                 │  │   │
│  │  │  • ReconfigVM (net_map)                         │  │   │
│  │  │  • CustomizeVM (Re-IP)                          │  │   │
│  │  ├─────────────────────────────────────────────────┤  │   │
│  │  │  VDDK Integration (FFI)                         │  │   │
│  │  │  • VixDiskLib_Open/Read/Write                   │  │   │
│  │  │  • QueryAllocatedBlocks                         │  │   │
│  │  │  • Transport: NBD, NBDSSL, HotAdd, SAN          │  │   │
│  │  └─────────────────────────────────────────────────┘  │   │
│  └───────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                  │                            │
                  ▼                            ▼
┌─────────────────────────┐  ┌─────────────────────────────┐
│   VMware vSphere API     │  │  DR Receiver (remote host)  │
│   (SOAP over HTTPS)      │  │  TLS-encrypted TCP          │
│   ESXi / vCenter         │  │  PSK authentication         │
└─────────────────────────┘  │  Snapshot management         │
                              │  Delta application           │
                              └─────────────────────────────┘

Fluxo de Dados — Backup

1. Bacula FD invokes plugin
2. Plugin creates VM snapshot (quiesced)
3. VDDK opens VMDK via chosen transport
4. CBT provides changed block list (incremental)
5. Blocks streamed to Bacula SD via FD pipe
6. Snapshot deleted after backup
7. Job metadata stored in Bacula catalog

Fluxo de Dados — Replicação CBT

1. Plugin queries CBT delta since last sync
2. Changed blocks read via VDDK
3. Delta sent to DR receiver via TLS-encrypted TCP
4. Receiver creates restore point snapshot on replica
5. Receiver writes delta to replica VMDK via VDDK
6. Replication state persisted to /var/lib/podheitor/replication/

Fluxo de Dados — Failover

Planned Failover:
1. Final CBT sync (catch up)
2. Shutdown source VM
3. Apply net_map (ReconfigVM)
4. Apply Re-IP (CustomizeVM)
5. Power on replica
6. Update replication state

Unplanned Failover:
1. Apply net_map on replica
2. Apply Re-IP on replica
3. Power on replica immediately
4. (no final sync — uses last available restore point)

5. Recursos — Backup

Backup Full

  • Backup de VM em nível de imagem via VMware VADP API
  • Snapshots com quiesce para consistência de aplicação
  • Suporte a múltiplos discos (todos os discos virtuais capturados)
  • Preservação de metadados (configuração da VM, versão de hardware, sistema operacional convidado)

Backup Incremental

  • Changed Block Tracking (CBT) para backups incrementais eficientes
  • Somente os blocos modificados são transferidos — tipicamente 1 a 5% do disco total
  • Redução expressiva da janela de backup e do uso de armazenamento

Backup Diferencial

  • Captura todas as alterações desde o último backup Full
  • Útil em ambientes com alta taxa de modificação

Modos de Transporte

Modo Descrição Caso de Uso
NBD Network Block Device (sem criptografia) Ambientes de laboratório/teste
NBDSSL NBD com criptografia SSL Uso padrão em produção
HotAdd Anexa VMDK diretamente à VM do FD FD em execução como VM no mesmo ESXi
SAN Acesso direto via SAN ao LUN do VMDK Backup sem LAN, máximo desempenho

Suporte a Múltiplas VMs

  • Backup de múltiplas VMs com Jobs separados
  • Filtros de inclusão/exclusão por host para operações em massa
  • Inclusão/exclusão de disco para backup seletivo

6. Recursos — Replicação e Recuperação de Desastres

Replicação Baseada em CBT

  • Replicação assíncrona push usando VMware CBT
  • RPO medido em minutos (intervalo de push configurável)
  • Eficiente em banda — apenas blocos alterados transmitidos
  • Limitação de banda opcional (max_bandwidth_mbps)

Ciclo de Vida DR com 10 Modos

# Modo Descrição Destrutivo Impacto na Origem
1 replication-status Consulta o estado de replicação e a última sincronização Não Nenhum
2 cbt-push Envia deltas CBT para a réplica Não Nenhum
3 seed Sincronização completa inicial do disco (cria réplica) Não Nenhum
4 failover-test Inicializa réplica em rede isolada Não Nenhum
5 failover-undo Desliga réplica de teste Não Nenhum
6 failover-planned Sincroniza → desliga origem → inicializa réplica Sim Desligamento
7 failover-unplanned Inicializa réplica imediatamente Não Nenhum
8 failover-permanent Converte réplica em produção Sim N/A
9 failback Replica em sentido inverso da réplica para a origem Sim Restaurado
10 reprotect Reestabelece replicação no sentido direto Não Nenhum

Mapeamento de Rede (net_map)

  • Reconfigura automaticamente as NICs da VM no failover
  • Mapeia redes de origem para redes de destino no site de DR
  • Utiliza a API SOAP ReconfigVM_Task do VMware
  • Aplicado em: failover planejado, não planejado e permanente

Reconfiguração de IP (Re-IP)

  • Define automaticamente endereço IP, máscara, gateway e DNS no failover
  • Utiliza a API SOAP CustomizeVM_Task do VMware (Customização do SO Convidado)
  • Formato: "nic_index:ip/prefix:gateway:dns1,dns2"
  • Requer VMware Tools no sistema operacional convidado

Pontos de Restore

  • Snapshot criado na réplica antes de cada aplicação de delta
  • Nomeado PodHeitor_RP_<timestamp>
  • Retenção configurável (dr_restore_points, padrão: 5)
  • Permite recuperação em momento específico a partir da réplica

Daemon Receptor de DR

  • Modo daemon persistente para recebimento de dados replicados
  • Escuta em porta TCP configurável (padrão: 9102)
  • Autenticação baseada em PSK com comparação em tempo constante
  • Handler de encerramento gracioso via SIGTERM
  • Criptografia TLS (opcional, recomendada para produção)

7. Recursos — Conversão entre Hipervisores

Conversões Suportadas

Origem Destino Conversão de Formato
VMware vSphere (VMDK) Hyper-V (VHDX) Automática
VMware vSphere (VMDK) Proxmox/KVM (QCOW2) Automática
Hyper-V (VHDX) VMware vSphere (VMDK) Automática
Hyper-V (VHDX) Proxmox/KVM (QCOW2) Automática
Proxmox/KVM (QCOW2) VMware vSphere (VMDK) Automática

Como Funciona

  1. O backup captura a VM em nível de imagem (formato nativo VMDK)
  2. O Bacula armazena os dados de backup em seu armazenamento padrão
  3. Na restauração, o plugin de destino detecta o hipervisor de origem
  4. Conversão automática de formato (VMDK ↔ VHDX ↔ QCOW2)
  5. Configuração da VM adaptada ao hipervisor de destino (hardware, drivers)

8. Arquitetura de Segurança

Segurança de Transporte

  • Backup: NBDSSL (criptografado com SSL) ou SAN (rede de armazenamento dedicada)
  • Protocolo DR: TLS 1.3 via rustls (quando certificado/chave configurados)
  • API vSphere: HTTPS com validação de certificado

Autenticação

  • vSphere: Usuário/senha via SOAP SessionManager
  • Protocolo DR: Chave pré-compartilhada (PSK) com comparação em tempo constante
  • Autenticação em tempo constante: Comparação baseada em XOR previne ataques de temporização

Proteção de Dados

  • Nenhum segredo armazenado no código — credenciais via configuração de FileSet do Bacula
  • Tokens de autenticação de DR rotativos sem reinicialização do serviço
  • Caminhos de certificado/chave TLS configuráveis via opções do plugin

Recursos de Conformidade

  • Log estruturado (nível + componente + mensagem)
  • Trilha de auditoria via catálogo do Bacula (histórico de jobs, metadados)
  • Persistência do estado de replicação para verificação de conformidade de DR

9. Guia de Instalação

9.1 Pré-requisitos

Requisito Detalhes
SO (host do File Daemon) Oracle Linux 9 / RHEL 9 / Rocky Linux 9 / AlmaLinux 9 — x86_64
Bacula Community 15.0.x instalado e em execução no mesmo host
VDDK Distribuído como RPM podheitor-vixdisklib-runtime — sem extração manual de tar
Rede TCP 443 para ESXi/vCenter; TCP 9102 (padrão) entre o FD primário e o receptor de DR
VMware Tools Instalado nas VMs convidadas (necessário para quiesce e Re-IP)
CBT Habilitado em cada VM a ser protegida (ver §9.5)
Espaço em disco ≥ 500 MB livres para o binário do backend + runtime do VDDK; ver §13 para armazenamento de backup

O host do File Daemon precisa de saída TCP 443 para a API ESXi/vCenter e, para replicação, saída TCP 9102 para o receptor de DR. Nenhuma porta de entrada é necessária no FD primário.

9.2 Artefatos da Versão

Tudo é distribuído como RPMs assinados dentro de releases/:

Arquivo Finalidade
podheitor-vsphere-1.4.1-1.el9.x86_64.rpm Plugin Rust cdylib (.so) + backend Rust + diretórios de estado CBT/replicação
podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm Bibliotecas de runtime VMware VDDK 9.0.1, autossuficientes via RPATH $ORIGIN

Sem extração de tar, sem edições manuais de ld.so.conf, sem exportações de LD_LIBRARY_PATH — tudo isso é tratado pelos scriptlets %post dos RPMs.

9.3 Instalação padrão (RPM)

A ordem não importa; qualquer RPM pode ser instalado primeiro.

# 1. Plugin RPM
sudo rpm -Uvh releases/podheitor-vsphere-1.4.1-1.el9.x86_64.rpm

# 2. VDDK runtime RPM
sudo rpm -Uvh releases/podheitor-vixdisklib-runtime-9.0.1-1.el9.x86_64.rpm

# 3. Restart Bacula FD
sudo systemctl restart bacula-fd

O RPM do plugin instala:

Caminho Conteúdo
/opt/bacula/plugins/podheitor-vsphere-fd.so Plugin Rust cdylib carregado pelo Bacula FD
/opt/bacula/bin/podheitor-vsphere-backend Binário do backend Rust
/opt/bacula/working/podheitor/cbt/ Estado CBT (change-ids por VM)
/var/lib/podheitor/replication/ Estado de replicação + metadados de pontos de restore

O RPM do runtime VDDK instala:

Caminho Conteúdo
/usr/lib/vmware-vix-disklib/lib64/ libvixDiskLib.so* + OpenSSL/curl/z incluídos (todos corrigidos com RPATH=$ORIGIN)
/usr/lib/vmware-vix-disklib/bin64/ vixDiskCheck, vmware-vdiskmanager, vddkReporter
/usr/lib/vmware-vix-disklib/include/ Headers VDDK (somente para desenvolvimento)
/usr/lib/vmware-vix-disklib/doc/ Documentação HTML do VDDK

9.4 Conflito com OpenSSL 3.4.0 — prevenção e recuperação

Instaladores antigos criavam /etc/ld.so.conf.d/vmware-vddk.conf apontando para /usr/lib/vmware-vix-disklib/lib64. Em hosts EL9 cujo OpenSSL do sistema tenha sido atualizado além da versão 3.4.0, todo binário do sistema (rpm, dnf, flatpak, …) passava a carregar o libcrypto.so.3 (versão mais antiga) do VMware e falhava com:

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

O RPM atual do podheitor-vixdisklib-runtime previne isso ao corrigir cada objeto compartilhado com RPATH=$ORIGIN em tempo de compilação, de forma que o VDDK encontra seus irmãos sem nenhuma diretiva global no loader. O scriptlet %post também remove entradas obsoletas:

/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
/etc/ld.so.conf.d/flatpak-vddk*.conf

Para recuperar um host já quebrado (que nem consegue executar o dnf), execute — sem necessidade de conexão:

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
# Verify the system libcrypto is back in front:
ldconfig -p | grep 'libcrypto.so.3 .*=> /lib64'
# Then dnf/rpm/flatpak work again:
sudo dnf check-update

9.5 Habilitar Changed Block Tracking (CBT)

O CBT é obrigatório para incrementais eficientes e para replicação.

Via govc:

export GOVC_URL="https://root:<PASSWORD>@<ESXI_IP>/sdk"
export GOVC_INSECURE=true

govc vm.change -vm <VM_NAME> -e ctkEnabled=TRUE
govc vm.change -vm <VM_NAME> -e scsi0:0.ctkEnabled=TRUE
# Repeat for each virtual disk (scsi0:1, scsi0:2, …)

Via vSphere Client: VM → Editar Configurações → Opções da VM → Avançado → Parâmetros de Configuração → definir ctkEnabled=TRUE e scsi<N>:<M>.ctkEnabled=TRUE por disco, depois criar e excluir um snapshot para materializar o change log.

9.6 Configurar o Bacula

Adicione o diretório de plugins ao FD (normalmente já configurado):

# /opt/bacula/etc/bacula-fd.conf
FileDaemon {
  Name = vsphere-fd
  Plugin Directory = /opt/bacula/plugins
  Plugin Names = "podheitor-vsphere"
  ...
}

Em seguida, adicione FileSets / Jobs / Schedules no Director (ver §11 e §12). Reinicie ambos os daemons:

sudo systemctl restart bacula-fd
sudo systemctl restart bacula-dir

9.7 Teste de fumaça

# VDDK visible to the backend?
/opt/bacula/bin/podheitor-vsphere-backend --version
# Should print the build version and exit 0.

# Run a dry-run backup of a single VM:
echo "status" | bconsole
run job=Backup-<VM_NAME> yes
# watch progress:
status client=vsphere-fd

9.8 Opcional: compilar a partir do código-fonte

Para desenvolvedores / clones do repositório git:

sudo ./install.sh

O script install.sh irá: detectar e instalar o RPM do runtime VDDK a partir de releases/, remover entradas legadas de flatpack/vixlib/vmware-vddk em /etc/ld.so.conf.d/, compilar o backend Rust com cargo --release e instalar o binário resultante + .so em /opt/bacula/.

9.9 Desinstalar

sudo systemctl stop bacula-fd
sudo rpm -e podheitor-vsphere podheitor-vixdisklib-runtime
sudo systemctl start bacula-fd

Os diretórios de estado (/opt/bacula/working/podheitor/, /var/lib/podheitor/) são preservados entre upgrades e removidos somente na desinstalação completa com rpm -e.

10. Referência de Configuração

Formato da Plugin String

Plugin = "podheitor-vsphere: key1=value1 key2=value2 ..."

Todas as opções podem ser especificadas diretamente na diretiva Plugin do FileSet.

Tabela Completa de Opções — Backup

Opção Tipo Obrigatório Padrão Descrição
host string Sim — Nome de host / IP do ESXi ou vCenter
username string Sim — Nome de login no vSphere
password string Sim — Senha de login no vSphere
datacenter string Sim — Nome do objeto gerenciado do datacenter
vm string Sim — Nome da VM a proteger
transport string Não nbdssl nbd, nbdssl, hotadd, san
quiesce bool Não true Quiesce o sistema de arquivos do convidado
timeout int Não 3600 Timeout em segundos
include_disk multi Não todos Incluir discos específicos
exclude_disk multi Não nenhum Excluir discos específicos
keep_cbt bool Não false Manter CBT após o backup
abort_on_error bool Não false Abortar no primeiro erro
snapshot_delete_delay int Não 0 Segundos de espera antes de excluir o snapshot
force_san bool Não false Forçar transporte SAN
debug bool Não false Habilitar log de depuração
config_file string Não — Arquivo de configuração externo

Tabela Completa de Opções — Restauração

Opção Tipo Obrigatório Padrão Descrição
new_vm_name string Não original Nome da VM restaurada
power_on bool Não false Ligar após a restauração
datastore string Não original Nome do datastore de destino
overwrite bool Não false Sobrescrever VM existente
no_network bool Não false Desconectar NICs
thin_provisioned bool Não false Usar provisionamento thin de disco
resource_pool string Não padrão Pool de recursos de destino
network_name string Não original Rede de destino
guest_id_override string Não auto Substituir tipo de SO convidado
hw_version string Não auto Substituir versão de hardware
controller_type string Não auto auto, ide, scsi, nvme

Tabela Completa de Opções — Replicação

Opção Tipo Obrigatório Padrão Descrição
mode string Sim — Modo de replicação (ver tabela de modos)
dr_host string Sim* — Nome de host / IP do receptor de DR
dr_port int Não 9102 Porta TCP do receptor de DR
dr_auth_token string Sim* — Token de autenticação pré-compartilhado
dr_restore_points int Não 5 Máximo de snapshots na réplica
dr_replica_datastore string Não auto Datastore para a réplica
push_interval int Não 300 Intervalo de push (segundos)
push_apply_remote bool Não true Aplicar deltas remotamente
max_retries int Não 3 Máximo de tentativas em caso de falha
retry_delay_sec int Não 30 Intervalo entre tentativas
alert_after_failures int Não 3 Limite para alerta
net_map multi Não — Regras de mapeamento de rede
reip multi Não — Regras de reconfiguração de IP
storage_map multi Não — Regras de mapeamento de datastore
max_bandwidth_mbps int Não 0 Limite de banda (0=ilimitado)
test_failover_network string Não — Rede de teste isolada
failover_vm string Não auto VM de destino no failover
dr_tls_cert string Não — Caminho do certificado TLS
dr_tls_key string Não — Caminho da chave privada TLS
dr_tls_insecure bool Não false Aceitar certificados autoassinados

Obrigatório para modos que se comunicam com o receptor de DR (cbt-push, seed, failover-*, failback, reprotect).

11. Exemplos de Configuração de Backup

Exemplo 1: Backup Full + Incremental Básico

# FileSet
FileSet {
  Name = "vSphere-Backup-VM1"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=production-web
              transport=nbdssl"
  }
}

# Full backup weekly, Incremental daily
Schedule {
  Name = "vSphere-Schedule"
  Run = Full sun at 02:00
  Run = Incremental mon-sat at 22:00
}

# Backup Job
Job {
  Name = "Backup-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Backup-VM1"
  Storage = File1
  Pool = File
  Schedule = "vSphere-Schedule"
  Messages = Standard
}

Exemplo 2: Múltiplas VMs

FileSet {
  Name = "vSphere-Backup-All"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=web-server
              transport=nbdssl"
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=db-server
              transport=nbdssl quiesce=true"
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root
              password=MyP@ss datacenter=ha-datacenter vm=app-server
              transport=nbdssl"
  }
}

Exemplo 3: Backup via SAN (sem LAN)

FileSet {
  Name = "vSphere-SAN-Backup"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=vcenter.prod.local username=admin@vsphere.local
              password=VcP@ss datacenter=Production vm=critical-db
              transport=san force_san=true"
  }
}

Exemplo 4: Backup Seletivo de Disco

FileSet {
  Name = "vSphere-Selective"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=multi-disk-vm transport=nbdssl
              exclude_disk=Hard disk 3"
  }
}

Exemplo 5: Restauração em Nova VM

# bconsole commands
restore jobid=<BACKUP_JOBID> where=/
  # Then add these override options at the restore prompt:
  # podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
  #   datacenter=ha-datacenter new_vm_name=restored-vm power_on=yes
  #   datastore=datastore2 thin_provisioned=yes

12. Exemplos de Configuração de Replicação

Exemplo 1: Replicação CBT Push (Incremental)

# FileSet for CBT push
FileSet {
  Name = "vSphere-Repl-Push"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=cbt-push dr_host=192.168.2.50 dr_port=9102
              dr_auth_token=MySecureToken2026 dr_tls_insecure=yes"
  }
}

# Schedule: push every 15 minutes
Schedule {
  Name = "Repl-Push-15min"
  Run = Incremental hourly at 0:00
  Run = Incremental hourly at 0:15
  Run = Incremental hourly at 0:30
  Run = Incremental hourly at 0:45
}

# Job
Job {
  Name = "Replicate-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Repl-Push"
  Storage = File1
  Pool = File
  Schedule = "Repl-Push-15min"
}

Exemplo 2: Seed Inicial

FileSet {
  Name = "vSphere-Seed"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=seed dr_host=192.168.2.50 dr_port=9102
              dr_auth_token=MySecureToken2026"
  }
}

Job {
  Name = "Seed-Production-Web"
  Type = Backup
  Client = vsphere-fd
  FileSet = "vSphere-Seed"
  Storage = File1
  Pool = File
}

Exemplo 3: Failover Planejado com Mapeamento de Rede

FileSet {
  Name = "vSphere-Failover-Planned"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss
              datacenter=ha-datacenter vm=production-web transport=nbdssl
              mode=failover-planned
              dr_host=192.168.2.50 dr_port=9102 dr_auth_token=MySecureToken2026
              net_map=Production_Network=DR_Network
              reip=0:192.168.2.10/24:192.168.2.1:8.8.8.8,8.8.4.4"
  }
}

Exemplo 4: Receptor de DR

FileSet {
  Name = "vSphere-DR-Receiver"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-vsphere: host=192.168.2.50 username=root password=DrP@ss
              datacenter=ha-datacenter vm=production-web-replica transport=nbdssl
              mode=dr-receiver dr_port=9102 dr_auth_token=MySecureToken2026
              dr_tls_cert=/etc/podheitor/tls/server.crt
              dr_tls_key=/etc/podheitor/tls/server.key"
  }
}

Exemplo 5: Configuração Completa de DR

# === PRIMARY SITE (Production) ===

# 1. Initial seed
Job { Name = "Seed-WebVM"  ... FileSet = "vSphere-Seed" }

# 2. Continuous replication (every 5 min)
Job { Name = "Repl-WebVM"  ... FileSet = "vSphere-Repl-Push" Schedule = "Every5Min" }

# 3. Status check (hourly)
Job { Name = "Status-WebVM" ... FileSet = "vSphere-Status" Schedule = "Hourly" }

# === DR SITE (Standby) ===

# 4. DR Receiver (long-running)
Job { Name = "DR-Receiver"  ... FileSet = "vSphere-DR-Receiver" }

# === FAILOVER JOBS (manual trigger) ===

# 5. Test failover
Job { Name = "Test-Failover-WebVM" ... mode=failover-test }

# 6. Undo test
Job { Name = "Undo-Failover-WebVM" ... mode=failover-undo }

# 7. Planned failover (during maintenance window)
Job { Name = "Planned-Failover-WebVM" ... mode=failover-planned
      net_map=... reip=... }

# 8. Emergency failover
Job { Name = "Emergency-Failover-WebVM" ... mode=failover-unplanned
      net_map=... reip=... }

# 9. Permanent failover
Job { Name = "Permanent-Failover-WebVM" ... mode=failover-permanent
      net_map=... reip=... }

# 10. Failback (after production restored)
Job { Name = "Failback-WebVM" ... mode=failback }

# 11. Re-protect
Job { Name = "Reprotect-WebVM" ... mode=reprotect }

13. Manual do Usuário e Operações do Dia a Dia

Esta seção descreve as tarefas cotidianas executadas pelo operador após a instalação do plugin e adição dos FileSets das seções §11–§12 ao bacula-dir.conf.

13.1 Comandos comuns do bconsole

Tarefa Comando (no bconsole)
Listar jobs de backup configurados show jobs
Listar jobs de backup de um cliente list jobs client=vsphere-fd
Executar um job sob demanda run job=Backup-Production-Web yes
Executar com nível explícito run job=Backup-Production-Web level=Full yes
Ver jobs em execução status client=vsphere-fd
Acompanhar mensagens messages
Buscar arquivos no catálogo list files jobid=<JOBID>
Cancelar um job travado cancel jobid=<JOBID>
Purgar e excluir um backup delete jobid=<JOBID>

13.2 Executar um backup

echo "run job=Backup-Production-Web yes" | bconsole
# Then watch:
echo "status client=vsphere-fd" | bconsole
echo "messages" | bconsole

Para forçar um Full (ex.: após habilitar o CBT pela primeira vez):

run job=Backup-Production-Web level=Full yes

Após o primeiro Full, os Incrementais subsequentes carregarão apenas os blocos alterados reportados pelo CBT (tipicamente 1 a 5% do disco por dia).

13.3 Restaurar uma VM (interativo)

* restore
Select item:  5 (Select the most recent backup for a client)
Defined Clients:
  1: vsphere-fd
Select Client (File Daemon) resource:  1
The defined FileSet resources are:
  1: vSphere-Backup-VM1
Select FileSet:  1
... bconsole picks the latest Full + chain of Incrementals
... it then drops you into the file selection tree.
$ mark *
$ done
Run Restore job
   JobName:    RestoreFiles
   Bootstrap:  /opt/bacula/working/...
   Where:      /tmp/bacula-restores
   Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
   ...
   12: Plugin Options
Select parameter to modify (1-13): 12
Please enter a Plugin Options string: podheitor-vsphere: 
        host=192.168.1.100 username=root password=MyP@ss 
        datacenter=ha-datacenter new_vm_name=production-web-restored 
        datastore=datastore2 thin_provisioned=yes power_on=yes
OK to run? (yes/mod/no): yes

O plugin reutiliza a versão de hardware original da VM, o tipo de adaptador de rede e o SO convidado, a menos que você substitua via hw_version, network_name, guest_id_override ou controller_type.

13.4 Restauração de disco único

Use include_disk (ou exclude_disk) na Plugin string da restauração para restringir qual VMDK será restaurado:

podheitor-vsphere: host=192.168.1.100 username=root password=MyP@ss 
        datacenter=ha-datacenter new_vm_name=onlydata 
        include_disk="Hard disk 2" datastore=datastore2 power_on=no

13.5 Restauração entre hipervisores (vSphere → Proxmox / Hyper-V)

A restauração entre hipervisores é simplesmente uma restauração regular direcionada a um host não VMware. A conversão de formato (VMDK ↔ VHDX ↔ QCOW2) é automática — ver §7.

# Restore a VMware backup onto a Proxmox host (FD running on PVE node)
restore client=proxmox-fd jobid=<BACKUP_JOBID>
   Plugin Options: podheitor-proxmox: node=pve1 storage=local-lvm 
                   new_vm_name=migrated-web vmid=120 power_on=no

13.6 Fluxo de operações do dia a dia na replicação

Após a conclusão do seed (modo seed) e com um job recorrente em modo cbt-push, a replicação é totalmente automática. As operações do dia a dia são:

Operação Quando bconsole
Verificar status A qualquer momento run job=Status-WebVM yes
Testar failover (não destrutivo) Simulação de DR run job=Test-Failover-WebVM yes
Desfazer teste Após simulação run job=Undo-Failover-WebVM yes
Failover planejado Janela de manutenção run job=Planned-Failover-WebVM yes
Failover não planejado Interrupção run job=Emergency-Failover-WebVM yes
Failover permanente Migração definitiva run job=Permanent-Failover-WebVM yes
Failback para a origem Origem restaurada run job=Failback-WebVM yes
Reproteger (reiniciar replicação direta) Após failback run job=Reprotect-WebVM yes

13.7 Ciclo de vida do daemon receptor de DR

O receptor de DR executa como um job de longa duração (mode=dr-receiver) no Bacula FD do site de DR. Configuração recomendada:

Job {
  Name = "DR-Receiver-Always-On"
  Type = Backup
  Client = vsphere-dr-fd
  FileSet = "vSphere-DR-Receiver"
  Schedule = "Boot"          # starts on FD boot
  Max Run Sched Time = 0     # never time out
  Allow Duplicate Jobs = no
  Reschedule On Error = yes
  Reschedule Interval = 60
  Reschedule Times = 0       # forever
}

SIGTERM (ex.: bconsole: cancel jobid=<n>) aciona um encerramento gracioso — os deltas em andamento são descarregados e o bloqueio de snapshot na réplica é liberado antes da saída.

13.8 Certificados TLS para o protocolo DR

Para produção, gere um certificado de servidor para o host do receptor de DR:

openssl req -x509 -newkey rsa:4096 -nodes -days 3650 
    -keyout /etc/podheitor/tls/server.key 
    -out    /etc/podheitor/tls/server.crt 
    -subj   "/CN=vsphere-dr-fd.dr.local"
chmod 600 /etc/podheitor/tls/server.key

Referencie ambos os arquivos via dr_tls_cert= e dr_tls_key= no FileSet com mode=dr-receiver, e remova dr_tls_insecure=yes no lado remetente assim que o certificado for confiável.

13.9 Rotação de token

Os tokens são lidos da Plugin string no início do job, portanto a rotação é:

  1. Gere um novo token (openssl rand -hex 32).
  2. Atualize ambas as strings dr_auth_token= (FileSets do remetente e do receptor).
  3. bconsole: reload.
  4. Cancele o job do receptor de DR em execução — o Bacula o reagendará

automaticamente (conforme §13.7) e o novo token entrará em vigor.

13.10 Localização dos logs

Arquivo Conteúdo
/opt/bacula/working/bacula-fd.log Log do Bacula FD (saída do plugin multiplexada)
/opt/bacula/working/podheitor/cbt/<vm>.json Change-IDs CBT por VM
/var/lib/podheitor/replication/<vm>.json Estado de replicação, hora da última sincronização, pontos de restore
journalctl -u bacula-fd -e stderr capturado pelo systemd

Adicione debug=true à Plugin string para rastreamento detalhado do backend (encaminhado ao log do Bacula FD via PTCOMM).

14. Dimensionamento e Requisitos

Requisitos de Hardware

Componente Mínimo Recomendado Alto Desempenho
CPU 2 núcleos 4 núcleos 8+ núcleos
RAM 4 GB 8 GB 16+ GB
Disco (FD) 20 GB 50 GB 100+ GB
Rede 1 Gbps 10 Gbps 25 Gbps

Dimensionamento de Armazenamento

Cenário Estimativa
Backup Full ~1:1 com dados usados (compressão pelo Bacula SD)
Incremental 1 a 5% do disco total por dia (típico)
Réplica Igual ao tamanho do disco da VM de origem
Pontos de restore ~1 a 5% por snapshot (depende da taxa de alteração)

Largura de Banda de Rede

Cenário Largura de Banda Necessária
Backup diário (VM de 100 GB) ~5 GB incremental → ~11 Mbps sustentado
Replicação (VM de 100 GB, RPO de 5 min) ~100 MB/intervalo → ~3 Mbps sustentado
Seed completo (VM de 100 GB) 100 GB → ~2,2 horas a 100 Mbps

Limites de VMs Simultâneas

Configuração Máximo Recomendado
2 CPU / 4 GB RAM 2 a 3 VMs simultâneas
4 CPU / 8 GB RAM 5 a 10 VMs simultâneas
8 CPU / 16 GB RAM 15 a 20 VMs simultâneas

15. Matriz de Compatibilidade

Compatibilidade VMware

Componente Versão Testado Observações
ESXi 7.0 ✅ Todos os níveis de atualização
ESXi 8.0 ✅ Todos os níveis de atualização
ESXi 8.0U3e ✅ Plataforma de teste principal
vCenter 7.0 ✅ Opcional — ESXi standalone suportado
vCenter 8.0 ✅ Opcional
VDDK 8.0.x ✅ Mínimo recomendado
VDDK 9.0.1 ✅ Plataforma de teste principal

Compatibilidade de Sistema Operacional (Servidor FD)

SO Versão Testado Observações
Oracle Linux 9.x ✅ Plataforma de teste principal (9.5)
RHEL 9.x ✅ Mesmo binário que OL9
Rocky Linux 9.x ✅ Mesmo binário que OL9
AlmaLinux 9.x ✅ Mesmo binário que OL9

Compatibilidade com Bacula

Componente Versão Testado
Bacula Community 15.0.3 ✅
Bacula Community 15.0.x Compatível esperado

Suporte a SO Convidado

SO Convidado Backup Restauração Quiesce CBT Re-IP
Linux (qualquer) ✅ ✅ ✅* ✅ ✅*
Windows Server ✅ ✅ ✅* ✅ ✅*
Windows 10/11 ✅ ✅ ✅* ✅ ✅*
FreeBSD ✅ ✅ ⚠️ ✅ ❌
Outros ✅ ✅ ⚠️ ✅ ❌

*Requer VMware Tools instalado no convidado.

16. Resultados de Testes

Ambiente de Teste

Componente Detalhes
ESXi 8.0U3e, standalone, IP 192.168.15.91
Servidor FD Oracle Linux 9.5, Bacula 15.0.3
VDDK 9.0.1
VMs de Teste Alpine (381 MB), TinyCore, CirrOS, Multi-Disk

Testes de Backup e Restauração

# Teste Resultado Detalhes
1 Backup Full (NBDSSL) ✅ APROVADO Todas as 4 VMs
2 Backup Incremental (CBT) ✅ APROVADO Apenas blocos alterados
3 Restauração completa da VM ✅ APROVADO Nome original + novo nome
4 Restauração para datastore diferente ✅ APROVADO Thin provisioned
5 Restauração entre hipervisores (vSphere → Hyper-V) ✅ APROVADO VMDK → VHDX
6 Restauração entre hipervisores (Hyper-V → vSphere) ✅ APROVADO VHDX → VMDK

Testes de Replicação (20 de abril de 2026)

# Teste JobId Status Dados
1 Status de Replicação 881 ✅ T 870 B
2 CBT Push (Incremental) 882 ✅ T 377 MB
3 Teste de Failover 883 ✅ T 137 B
4 Desfazer Failover 884 ✅ T 137 B
5 Failover Planejado 885 ✅ T 140 B
6 Desfazer Failover (2) 887 ✅ T 137 B
7 Failover Não Planejado 889 ✅ T 142 B
8 Failover Permanente 892 ✅ T 142 B
9 Seed (Sincronização Completa) 893 ✅ T 377 MB
10 Failback 894 ✅ T 2,1 GB
11 Reprotect 895 ✅ T 1.795 B
12 Status Final 897 ✅ T 870 B

Resultado: 12/12 testes APROVADOS — 100% de taxa de sucesso

Matriz de Validação de Restauração (v1.4.1, 29 de abril de 2026)

Laboratório de caminho de restauração de ponta a ponta em ESXi 8.0.3 (192.168.15.91, sem vCenter) + Bacula 15.0.3 FD/SD/Director (192.168.15.105). VM de origem vm-alpine1 (Alpine 3.21, ext4 com SYSLINUX VBR; snapshot ao vivo).

# Caminho JobId Resultado Observações
1 Backup Full (NBDSSL + habilitação CBT) 6425 ✅ T changeId persistido: …/85
2 Full → restauração no sistema de arquivos (Where=/tmp/restore) 6427 ✅ T 4 arquivos / 2,147 GB / 6 s, 0 erros no FD
3 Corretude de bytes do VMDK restaurado — ✅ mount -o ro,loop,noload; /etc/alpine-release = 3.21.0
4 Backup Incremental (CBT) 6429 ✅ T changeId persistido: …/86
5 Incremental → restauração no sistema de arquivos 6431 ✅ T correspondência byte a byte com a restauração Full
6 Segurança da restauração no hipervisor (VM de origem existe) 6434/6435 ✅ recusado “VM already exists; use overwrite=yes or different where name”
7 Backup com new_vm_name=vm-alpine1-restored embutido 6440 ✅ T Plugin string congelada no catálogo
8 Restauração no hipervisor (recriação no ESXi via NBD/SSL) 6442 ✅ T moref=71 criado, VMDK enviado
9 Inicialização da VM recriada / boot — ✅ bootTime definido, uptimeSeconds=118, CPU 29 MHz, mem 220 MB

Resultado: 9/9 caminhos APROVADOS. As três correções da v1.4.1 (duplicação de caminho, captura de Where=, EOD do writer de diretório) confirmadas contra carga de trabalho real.

17. Comparativo com Soluções Corporativas

Comparativo de Recursos

Recurso PodHeitor BRC Bacula Enterprise Veeam B&R Commvault
Backup em Nível de Imagem ✅ ✅ ✅ ✅
Suporte a CBT ✅ ✅ ✅ ✅
Incremental ✅ ✅ ✅ ✅
Transporte SAN ✅ ✅ ✅ ✅
Restauração Completa de VM ✅ ✅ ✅ ✅
Restauração de Disco Único ✅ ✅ ✅ ✅
Entre Hipervisores ✅ ❌ ⚠️ ⚠️
Replicação de VM ✅ ❌ ✅ ✅
Failover de DR ✅ (10 modos) ❌ ✅ ✅
Mapeamento de Rede ✅ ❌ ✅ ✅
Re-IP no Failover ✅ ❌ ✅ ✅
Protocolo DR com TLS ✅ N/A ✅ ✅
Bacula Community ✅ ❌ N/A N/A
Custo $$ $$$$ $$$$$ $$$$$

Vantagem de Custo

Traga sua cotação ou proposta de renovação do Bacula Enterprise, Veeam, Commvault ou Netbackup. Garantimos pelo menos 50% de desconto, com muito mais recursos.

18. Solução de Problemas

18.1 OPENSSL_3.4.0 not found do rpm / dnf / flatpak

Causa: uma entrada legada em /etc/ld.so.conf.d/ está forçando todo processo a carregar o libcrypto.so.3 antigo do VMware. Consulte §9.4 para a recuperação em um único comando.

18.2 libvixDiskLib.so not found in standard paths

O backend busca em:

  1. /usr/lib/vmware-vix-disklib/lib64
  2. /usr/lib64/vmware-vix-disklib
  3. /opt/bacula/lib/vix

Se o RPM do runtime VDDK estiver instalado, o caminho #1 conterá libvixDiskLib.so. Se você instalou o VDDK manualmente em um local incomum, defina a variável de ambiente VDDK_LIB_PATH=/caminho/completo/libvixDiskLib.so na unidade de serviço do FD:

sudo systemctl edit bacula-fd
# add:
# [Service]
# Environment=VDDK_LIB_PATH=/opt/vddk/lib64/libvixDiskLib.so
sudo systemctl daemon-reload && sudo systemctl restart bacula-fd

18.3 Backup executado, mas produz 0 bytes no Incremental

O CBT não está habilitado ou foi redefinido. Verifique:

govc vm.info -vm.ipath /ha-datacenter/vm/<VM_NAME> | grep -i ctk
# Must show ctkEnabled = true

Em seguida, crie e exclua um snapshot para materializar o change log e execute um Full novamente.

18.4 dlopen(libvixDiskLib.so): symbol lookup error

O .so do VDDK não encontrou um de seus irmãos (libcrypto.so.3, libssl.so.3, libcurl.so.4, …). Confirme se o RPATH foi aplicado:

readelf -d /usr/lib/vmware-vix-disklib/lib64/libvixDiskLib.so.9 | grep PATH
# Expected:
#   0x0000000000000001 (RUNPATH)            Library runpath: [$ORIGIN]

Se ausente, reinstale o podheitor-vixdisklib-runtime — o %install do RPM aplica patchelf --set-rpath '$ORIGIN' a cada .so em lib64/.

18.5 O delta de replicação é aplicado, mas a VM não inicializa após o failover

Verifique se net_map= / reip= no FileSet de failover apontam para redes e IPs que existem de fato no site de DR. Um port group não mapeado faz o VMware desconectar silenciosamente a NIC na inicialização.

18.6 “Authentication failed” no receptor de DR

dr_auth_token= deve ser idêntico byte a byte no remetente e no receptor. A comparação é feita em tempo constante (baseada em XOR) para prevenir ataques de temporização, portanto a única forma de falhar é uma discrepância real. Se você rotacionou o token recentemente, consulte §13.9.

18.7 Backups lentos ou presos em connecting

Verifique o transporte:

  • nbdssl via WAN com alta latência — mude para san se possível,

ou hotadd se o FD for uma VM no mesmo cluster ESXi.

  • Firewall entre FD e ESXi — a porta NBD (902) deve estar aberta

além da 443 ao usar nbd / nbdssl.

19. Licenciamento e Contato

Licença

Copyright © 2026 Heitor Faria — Todos os Direitos Reservados

Este software é proprietário. Todo o código-fonte, binários e documentação são propriedade exclusiva de Heitor Faria. Cópia, distribuição, modificação ou engenharia reversa não autorizadas são estritamente proibidas.

Contato

Heitor Faria

  • 📧 Email: heitor@opentechs.lat
  • 📱 Telefone: +1 786 726-1749
  • 📱 WhatsApp: +55 61 98268-4220

Consultas Comerciais

Para preços, licenciamento, prova de conceito e demonstrações técnicas, entre em contato diretamente. Descontos por volume e contratos plurianuais disponíveis.

Oferta Especial: Traga sua cotação ou proposta de renovação existente do Bacula Enterprise, Veeam, Commvault ou Netbackup. Garantimos pelo menos 50% de desconto, com muito mais recursos.

PodHeitor vSphere BRC Plugin — Whitepaper v1.4.1 — Abril de 2026 VMware, vSphere, ESXi, VADP, VDDK são marcas registradas da Broadcom/VMware. Bacula é marca registrada de Kern Sibbald. Todas as demais marcas são propriedade de seus respectivos donos.

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

Deixe um comentário