Blog

Whitepaper técnico — PodHeitor Granular Restore para Bacula

Whitepaper técnico — PodHeitor Granular Restore para Bacula

Whitepaper Técnico — Versão 0.1.0 — Maio de 2026

Autor: Heitor Faria · Website: https://podheitor.com · E-mail: heitor@opentechs.lat · Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Oferta especial. Traga sua proposta de renovação de qualquer plataforma comercial de backup — Veeam, Commvault, NetBackup ou outras. Elaboraremos uma proposta técnica comparativa com meta de pelo menos 50% de economia e funcionalidades superiores específicas para PHGR. Contato: heitor@opentechs.lat.

Sumário

  1. Sumário executivo
  2. Introdução e contexto de mercado
  3. Visão arquitetônica
  4. Modos de restore em detalhe
  5. Matriz de funcionalidades
  6. Guia de instalação
  7. Referência de configuração
  8. Exemplos de FileSet
  9. Dimensionamento e planejamento de capacidade
  10. Relatório de desempenho
  11. Matriz de compatibilidade
  12. Segurança
  13. Monitoramento
  14. Guia de troubleshooting
  15. Casos de uso e cenários de implantação
  16. Comparação com outras abordagens
  17. Roadmap
  18. Conclusão
  19. Informações de contato
  20. Aviso legal / direitos autorais

1. Sumário executivo

Backups de máquinas virtuais protegem imagens de disco completas — VMDK para vSphere, VHDX para Hyper-V, qcow2 para Proxmox e KVM. Essas imagens são extremamente eficientes em espaço e consistentes com o hipervisor, mas criam uma lacuna operacional dolorosa: quando um administrador precisa recuperar um único arquivo deletado, uma configuração específica ou um diretório individual de dentro de uma VM backupeada, a resposta tradicional é restaurar a imagem de disco inteira — um processo medido em gigabytes de transferência de rede, dezenas de minutos de inatividade e enorme movimentação de armazenamento — apenas para recuperar um arquivo que pode ter poucos kilobytes.

O PodHeitor Granular Restore for Bacula (PHGR) fecha essa lacuna. Trata-se de uma suíte que roda no lado do Storage Daemon, escrita em Rust, que monta imagens de disco virtual (VHDX, VMDK, qcow2, VHD, raw, VDI) diretamente dos volumes Bacula — sem precisar fazer staging da imagem completa em disco — e expõe o sistema de arquivos do guest (NTFS, ext4, xfs, btrfs, ReFS, FAT32, exFAT) para navegação interativa ou extração programática. Administradores podem navegar pela árvore de diretórios de qualquer VM backupeada, selecionar arquivos ou pastas individuais e extraí-los em segundos.

Além do restore em nível de arquivo, o PHGR entrega duas capacidades adicionais que compartilham o mesmo núcleo Rust: Instant Recovery (IR), que inicializa uma VM diretamente de um volume Bacula via NBD ou iSCSI em menos de 60 segundos enquanto a migração de armazenamento ocorre em segundo plano; e V2V Cross-Hypervisor, que converte o formato de disco e gera a configuração nativa do hipervisor de destino para restaurar uma VM em um hipervisor diferente do original. As três capacidades são entregues em uma única suíte modular voltada para o Bacula Community 15.0.3.

Do ponto de vista competitivo, Granular Restore é uma funcionalidade premium na Veeam Data Platform e na Commvault — precificada como tal e indisponível em infraestrutura de backup open-source até agora. O PHGR entrega funcionalidade equivalente e, em vários aspectos, superior (cobertura Proxmox/CloudStack/Nutanix, Instant Recovery para Hyper-V, V2V cross-hypervisor, arquitetura zero-staging) sobre o Bacula Community a uma fração do custo das plataformas enterprise.

2. Introdução e contexto de mercado

2.1 O paradoxo do backup de máquinas virtuais

O backup de VM em nível de imagem tornou-se o padrão de fato para proteger infraestrutura virtualizada. A abordagem captura o estado completo do disco — incluindo o sistema operacional, software instalado e dados — em um snapshot consistente que pode ser restaurado para uma nova VM de forma previsível e repetível. Mecanismos nativos de hipervisor (Hyper-V RCT, VMware CBT, dirty bitmaps do Proxmox) permitem capturas incrementais eficientes com impacto mínimo de desempenho.

O paradoxo operacional surge no momento em que é preciso recuperar um arquivo específico. Considere estes cenários reais:

  • Um desenvolvedor em uma VM Windows Server apaga acidentalmente um arquivo de configuração. A VM está em produção e não pode ser parada. O arquivo está em C:AppConfig no backup Hyper-V mais recente.
  • Um auditor de conformidade solicita um arquivo de log específico de uma imagem de VM tirada há três meses. Restaurar o VHDX inteiro (200 GB) para recuperar um arquivo de 40 KB é operacionalmente absurdo.
  • Uma VM de servidor de banco de dados falha. É necessário Instant Recovery — inicializar a partir do backup imediatamente enquanto a equipe de storage provisiona novo hardware — mas a plataforma de backup suporta apenas restores completos.

Esses cenários exigem acesso granular ao conteúdo das imagens de disco virtual. Sem ferramentas específicas, os administradores enfrentam uma escolha difícil: aceitar o overhead do restore completo, manter um backup em nível de arquivo em paralelo (dobrando custos de armazenamento e janelas de backup) ou recorrer a procedimentos manuais ad hoc.

2.2 Por que as abordagens existentes são insuficientes

Ferramenta Granular Restore a partir de imagem de VM Veredicto
Bacula Community (nativo, sem plugin) Restore completo da imagem necessário antes do acesso ao arquivo Impraticável para recuperação de arquivo único
Veeam Data Platform Instant File Recovery — funcionalidade premium, preço premium Indisponível em infraestrutura open-source
Commvault Granular Recovery Technology — proprietário, caro Exige pilha completa de licenças Commvault
NetBackup Instant Access — disponível apenas em tiers enterprise Alto custo de licenciamento, implantação complexa
Bareos / Amanda Sem Granular Restore nativo de VM Apenas restore completo da imagem
Scripts manuais (libguestfs/7z) Possível, mas propenso a erros, sem integração com catálogo Não é produção-grade, sem trilha de auditoria

A lacuna é clara: até o PHGR, nenhuma plataforma de backup open-source oferecia Granular Restore de produção a partir de backups de imagem de VM. O PHGR preenche essa lacuna.

2.3 A abordagem PodHeitor

O PHGR segue a mesma filosofia de design da família de plugins PodHeitor: implementação nativa em Rust, desenvolvimento por fases com testes de regressão automatizados, operação no lado do Storage Daemon que elimina todo o overhead de staging de dados, e um gateway gRPC + REST que torna a suíte consumível pelo Bacularis, PHWEB ou qualquer integração scriptada. As três capacidades — Granular Restore, Instant Recovery e conversão V2V — compartilham um único crate phgr-core, maximizando o reuso de código e minimizando a superfície de ataque.

3. Visão arquitetônica

3.1 Design da suíte: um projeto, três binários

O PHGR é estruturado como um Cargo workspace com um crate de biblioteca compartilhada e quatro binários implantáveis:

Componente Binário / arquivo Função
Biblioteca central phgr-core (crate) Catálogo/BVFS, leitor de volumes, montador de FS, exportador de blocos, motor V2V, gerenciador de sessões, auditoria
Daemon de Granular Restore /opt/phgr/bin/phgrd Daemon de longa duração que gerencia sessões GR (export FUSE / SMB / NFS)
Daemon de Instant Recovery /opt/phgr/bin/phird Daemon de longa duração que gerencia sessões IR (export NBD / iSCSI / NFS-Datastore) e migração de armazenamento em segundo plano
CLI /opt/phgr/bin/phgr-cli Assistente interativo e CLI scriptada para operações mount, ir, v2v, diff, verify
Gateway de API /opt/phgr/bin/phgr-api Servidor gRPC + REST com spec OpenAPI 3.1; consumido pelo Bacularis e PHWEB

Essa separação oferece três vantagens principais:

  1. Isolamento. Cada daemon roda como um serviço systemd separado. Uma falha no daemon de IR não afeta sessões de GR ativas.
  2. Implantação independente. Sites que precisam apenas de Granular Restore instalam somente phgrd e phgr-cli. Instant Recovery e V2V são componentes opcionais.
  3. Testabilidade. O phgr-core é uma biblioteca pura testável independentemente de qualquer infraestrutura Bacula ou de hipervisor.

3.2 Operação no lado do Storage Daemon

O PHGR roda no host do Bacula Storage Daemon (SD), não no host do cliente (FD). Esta é uma decisão arquitetônica intencional com consequências importantes:

  • Zero staging de imagem completa. O PHGR lê dados de imagem de disco virtual diretamente dos volumes Bacula no filesystem do SD via leituras lazy por streaming. Nunca extrai o VHDX ou VMDK completo para um diretório de trabalho antes de montar. Para um VHDX de 200 GB, o footprint do diretório de trabalho é de no máximo 2 GB (cache LRU + overlay COW).
  • Disponibilidade de ferramentas. O host SD é Linux. libguestfs, qemu-nbd, qemu-img, Samba, NFS e iSCSI Target (LIO) estão disponíveis nativamente no Linux e são trivialmente instaláveis.
  • Desempenho. Leituras dos volumes Bacula são I/O local no filesystem do host SD. Latência de rede não está no caminho crítico das sessões de GR.

3.3 Diagrama de arquitetura

┌────────────────────────────────────────────────────────────────────────┐
│                     Suíte PHGR (host do SD)                             │
│                                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │  phgr-cli    │  │  phgrd       │  │  phird       │  │  phgr-api    │ │
│  │ (interativo  │  │ (daemon GR:  │  │ (daemon IR:  │  │ (gRPC+REST   │ │
│  │  + scriptado)│  │  FUSE/SMB/   │  │  NBD/iSCSI/  │  │  OpenAPI)    │ │
│  │              │  │  NFS export) │  │  NFS-DS)     │  │              │ │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│         └─────────────────┴──────────────────┴─────────────────┘         │
│                                    │                                      │
│                                    ▼                                      │
│               ┌──────────────────────────────────────────┐                │
│               │          phgr-core  (crate Rust)         │                │
│               │                                          │                │
│               │  Catálogo/BVFS ── Leitor de Volumes      │                │
│               │  Montador de Delta/CBT ── Adaptador Disco │                │
│               │  Montador FS ── Exportador de Blocos      │                │
│               │  Motor V2V ── Gerenc. Sessões ── Auditoria│                │
│               └───────────────────────┬──────────────────┘                │
│                                       │                                   │
│                         lê volumes Bacula diretamente                     │
│                                       │                                   │
└───────────────────────────────────────┼───────────────────────────────────┘
                                        │
        ┌───────────────────────────────┴──────────────────────────────┐
        │  Bacula 15.0.3 (Director / SD / catálogo PG / volumes)        │
        │  Hipervisores (Hyper-V, vSphere, Proxmox, KVM, CloudStack)    │
        │  libguestfs / qemu-img / qemu-nbd / Samba / NFS / iSCSI LIO  │
        └──────────────────────────────────────────────────────────────┘

3.4 Gerenciamento de sessões

Cada sessão de GR ou IR é rastreada em um diretório de trabalho dedicado:

/opt/bacula/working/phgr/{session_uuid}/
  ├── session.db          # estado da sessão SQLite e manifesto de arquivos
  ├── manifest.yaml       # heartbeat, modo, IDs de Job, pontos de montagem
  ├── cow/                # overlay qcow2 COW (modo IR)
  └── mnt/                # ponto de montagem FUSE (modo GR)

O daemon grava um heartbeat no manifest.yaml a cada 30 segundos. Um sweeper em segundo plano coleta sessões órfãs (heartbeat com mais de 10 minutos), desmonta filesystems FUSE, coloca targets NBD/iSCSI offline e remove o diretório de trabalho. Hooks ExecStop do systemd garantem a limpeza no reinício do daemon.

4. Modos de restore em detalhe

4.1 Granular Restore (GR) — acesso em nível de arquivo a partir de imagens de disco de VM

Como funciona

O modo Granular Restore lê dados de imagem de disco virtual de forma lazy a partir dos volumes Bacula, monta a cadeia CBT/incremental em memória, passa a imagem reconstruída para o adaptador de disco (libguestfs + qemu-nbd na v1.x, parsers nativos em Rust na v2.x) e monta o sistema de arquivos do guest via FUSE ou exporta via SMB ou NFS. O operador pode então navegar pela árvore de diretórios interativamente e extrair arquivos ou diretórios individuais.

  Volumes Bacula (filesystem do SD)
    ──► phgr-core::volume_reader (streaming lazy)
    ──► phgr-core::delta (montagem da cadeia CBT)
    ──► phgr-core::disk_adapter (libguestfs / qemu-nbd)
    ──► phgr-core::fs_mounter (FUSE / SMB / NFS)
    ──► operador navega pelo filesystem guest, extrai arquivos

Modos de operação

Modo Descrição Melhor para Footprint do diretório de trabalho
browse Montagem FUSE read-only do FS guest, acesso local apenas Inspeção rápida pelo operador < 100 MB
extract Extração direta de caminhos específicos para destino, sem montagem Restore scriptado / ETL Streaming (sem staging)
share-smb Browse + compartilhamento Samba automático Acesso drag-and-drop por cliente Windows < 100 MB
share-nfs Browse + export NFS Cliente Linux ou datastore ESXi < 100 MB

Quando usar

  • Recuperar um arquivo deletado de dentro de um backup de VM sem restaurar a imagem completa
  • Solicitação de auditor ou conformidade por um arquivo específico de um backup histórico
  • Recuperar arquivos de configuração, logs ou certificados sem reinicializar a VM em produção
  • Comparar o estado do filesystem entre dois jobs de backup (modo diff)

Formatos de imagem de disco suportados

Formato Hipervisor de origem Suporte GR
VHDX / VHD Hyper-V (Microsoft) Suportado
VMDK vSphere / VMware Suportado
qcow2 Proxmox / KVM / CloudStack / Nutanix AHV Suportado
raw KVM / genérico Suportado
VDI VirtualBox Suportado

Sistemas de arquivos guest suportados

Sistema de arquivos SO Leitura Preservação de ACL
NTFS Windows (todas as versões) Suportado Parcial (aproximação POSIX)
ext4 Linux Suportado Sim
ext3 / ext2 Linux Suportado Sim
xfs Linux / RHEL Suportado Sim
btrfs Linux / openSUSE Suportado Sim
ReFS Windows Server 2016+ Suportado Parcial
FAT32 / exFAT UEFI ESP / removível Suportado N/A

4.2 Instant Recovery (IR) — inicializar VM diretamente do backup Bacula

Como funciona

O modo Instant Recovery expõe a imagem de disco reconstruída como um target de dispositivo de bloco via NBD (Proxmox/KVM/ESXi 7+), iSCSI (Hyper-V) ou NFS Datastore (vSphere clássico). O hipervisor inicializa a VM usando esse endpoint de bloco. Todas as leituras são servidas pelo phird fazendo streaming dos dados sob demanda a partir dos volumes Bacula. Um overlay Copy-on-Write absorve as escritas durante o período de recuperação. Uma thread de migração de armazenamento em segundo plano copia os blocos para o armazenamento de destino sem interromper a VM em execução.

  Volumes Bacula ──► phird streaming lazy ──► overlay qcow2 COW
                                                    │
                          ┌─────────────────────────┼─────────────────────────┐
                          │                         │                         │
                     export NBD              export iSCSI (LIO)     export NFS-Datastore
                          │                         │                         │
                   Proxmox/KVM               Hyper-V                    vSphere
                   VM boot ≤ 60s           VM boot ≤ 90s              VM boot ≤ 60s
                          │
              segundo plano: migra blocos para local-lvm → sessão COMPLETA

Modos de IR por hipervisor

Hipervisor Protocolo de export Tempo de boot (p95) Status
Proxmox / KVM NBD (qemu-nbd) ≤ 60 s Fase 5
vSphere / ESXi NFS Datastore (NFSv3) ≤ 60 s Fase 5
Hyper-V iSCSI Target (Linux LIO) ≤ 90 s Fase 5
Nutanix AHV NBD / Prism API ≤ 90 s Fase 7
CloudStack / KVM NBD ≤ 60 s Fase 7

4.3 V2V Cross-Hypervisor — restaurar em um hipervisor diferente

Como funciona

O modo V2V converte o formato de disco (via qemu-img) e traduz o descritor de configuração da VM para o formato exigido pelo hipervisor de destino. Um backup VHDX de Hyper-V pode ser restaurado como uma VM qcow2 no Proxmox com vCPU, RAM e configuração de rede corretas. O pipeline completo — extração do disco do Bacula, conversão de formato, geração de config, registro da VM — é orquestrado por um único comando phgr-cli.

  phgr-cli v2v --from @hyperv/MinhaVM --to proxmox/pve --jobid 1234 --target-storage local-lvm
      │
      ├─ 1. Extrai VHDX do volume Bacula (leitura lazy + montagem CBT)
      ├─ 2. Converte VHDX → qcow2 via qemu-img
      ├─ 3. Parseia config VMCX → descritor unificado de VM → config qm do Proxmox
      ├─ 4. Registra VM no Proxmox (qm create + import disk)
      └─ 5. Inicia VM (opcional) — boot validado

5. Matriz de funcionalidades

Funcionalidade Granular Restore Instant Recovery V2V
Suporte VHDX (Hyper-V) Sim Sim Sim
Suporte VMDK (vSphere) Sim Sim Sim
Suporte qcow2 (Proxmox/KVM) Sim Sim Sim
Sistema de arquivos guest NTFS Sim Sim Sim
Sistema de arquivos guest ext4 Sim Sim Sim
Sistema de arquivos guest xfs Sim Sim Sim
Sistema de arquivos guest btrfs Sim Sim Sim
Sistema de arquivos guest ReFS Sim Sim Sim
FAT32 / exFAT Sim Sim Sim
Montagem de cadeia CBT incremental Sim Sim Sim
Zero staging de imagem completa Sim Sim Não
Montagem FUSE local Sim Não Não
Export via SMB Sim Não Não
Export NFS Sim Sim (datastore) Não
Export de bloco NBD Não Sim Não
Export iSCSI (IR Hyper-V) Não Sim Não
Overlay COW (escritas durante IR) Não Sim Não
Migração de armazenamento em segundo plano Não Sim Não
Conversão cross-hypervisor Não Parcial (on-the-fly) Sim
Diff entre dois jobs de backup Sim Não Não
Verificação de boot em sandbox Sim Não Não
Varredura de malware (ClamAV/YARA) Sim (opcional) Não Não
Log de auditoria HMAC Sim Sim Sim
Métricas Prometheus Sim Sim Sim
API gRPC + REST Sim Sim Sim
Integração Bacularis Sim Sim Sim
Pacote RPM Sim Sim Sim
Pacote DEB Sim Sim Sim
Sessões concorrentes Sim (≥ 8) Sim (≥ 2) Sim
Limpeza de sessões órfãs Sim Sim Sim

6. Guia de instalação

6.1 Pré-requisitos

  • Bacula Community 15.0.3 ou posterior instalado; Storage Daemon rodando em um host Linux
  • SO: RHEL/OL/Rocky 9+ ou Ubuntu 22.04+/Debian 12+
  • glibc 2.34+
  • Pacotes de sistema necessários (instalados automaticamente pelas pré-dependências do RPM/DEB):
# EL9 / OL9
dnf install libguestfs guestfs-tools qemu-img qemu-nbd kpartx fuse3 
            samba samba-common nfs-utils iscsi-initiator-utils targetcli ntfs-3g

# Ubuntu 22.04 / Debian 12
apt install libguestfs-tools qemu-utils fuse3 samba nfs-kernel-server 
            open-iscsi targetcli-fb ntfs-3g
  • Usuário bacula existe e tem acesso de leitura aos diretórios de volumes do SD Bacula
  • bconsole está disponível e consegue conectar ao Bacula Director (necessário para consultas de catálogo BVFS)

6.2 Instalação via RPM (EL9 / OL9 / RHEL9 / Rocky 9)

# 1. Instalar pacote base (instala phgr-core + phgr-cli)
dnf install podheitor-phgr-0.1.0-1.el9.x86_64.rpm

# 2. Instalar daemon de GR (opcional — necessário para sessões GR persistentes + API)
dnf install podheitor-phgr-gr-0.1.0-1.el9.x86_64.rpm

# 3. Instalar daemon de IR (opcional — necessário para Instant Recovery)
dnf install podheitor-phgr-ir-0.1.0-1.el9.x86_64.rpm

# 4. Habilitar e iniciar os daemons
systemctl enable --now phgrd phird

# 5. Verificar instalação
/opt/phgr/bin/phgr-cli --version
/opt/phgr/bin/phgr-cli health

6.3 Instalação via DEB (Ubuntu 22.04 / Debian 12)

# 1. Instalar pacote base
apt install ./podheitor-phgr-core_0.1.0-1_amd64.deb

# 2. Instalar daemon de GR
apt install ./podheitor-phgr-gr_0.1.0-1_amd64.deb

# 3. Instalar daemon de IR
apt install ./podheitor-phgr-ir_0.1.0-1_amd64.deb

# 4. Habilitar e iniciar os daemons
systemctl enable --now phgrd phird

# 5. Verificar instalação
/opt/phgr/bin/phgr-cli --version
/opt/phgr/bin/phgr-cli health

6.4 Configuração do sudoers

Os daemons rodam como bacula:bacula e precisam de um conjunto pequeno de operações privilegiadas. O RPM/DEB instala automaticamente uma allowlist mínima de sudoers:

# /etc/sudoers.d/phgr (instalado automaticamente)
bacula ALL=(ALL) NOPASSWD: /usr/bin/smbcontrol reload-config
bacula ALL=(ALL) NOPASSWD: /usr/sbin/exportfs -ra
bacula ALL=(ALL) NOPASSWD: /usr/bin/targetcli *
bacula ALL=(ALL) NOPASSWD: /usr/bin/fusermount -z *

6.5 Teste de smoke rápido

# Listar VMs com backup nos últimos 7 dias
phgr-cli catalog list-vms --days 7

# Montar um backup específico para navegação de arquivos
phgr-cli mount --client meuservidor --jobid 4200 --vm "MinhaVM" --mode browse

# Navegar pelo filesystem montado
ls /opt/bacula/working/phgr/&lt;session-uuid&gt;/mnt/

# Extrair um arquivo específico
phgr-cli extract --session &lt;uuid&gt; --path /etc/nginx/nginx.conf --dest /tmp/recovered/

7. Referência de configuração

7.1 Arquivo de configuração principal — /etc/phgr/phgr.toml

Parâmetro Padrão Descrição
working_dir /opt/bacula/working/phgr Diretório base para diretórios de trabalho de sessão
bconsole_bin /opt/bacula/bin/bconsole Caminho para o binário bconsole
bconsole_conf /opt/bacula/etc/bconsole.conf Caminho para a configuração do bconsole
direct_pg false Usar conexão direta ao PostgreSQL para BVFS (mais rápido; requer credenciais PG)
pg_dsn (vazio) DSN do PostgreSQL quando direct_pg = true
cache_size_mb 256 Tamanho do cache LRU de blocos de disco em MB por sessão
sweeper_interval_secs 300 Intervalo do sweeper de sessões órfãs (segundos)
heartbeat_secs 30 Intervalo de heartbeat da sessão (segundos)
max_sessions 8 Número máximo de sessões concorrentes em todos os modos
nbd_listen_addr 127.0.0.1 Endereço de bind para exports NBD (modo IR)
nbd_base_port 10809 Porta base para exports NBD (incrementada por sessão)
iscsi_iqn_prefix iqn.2026-01.com.podheitor Prefixo IQN iSCSI para nomes de target
metrics_listen (vazio) Endereço de bind das métricas Prometheus; vazio = desativado
audit_log /var/log/phgr/audit.log Caminho para o log de auditoria com cadeia HMAC
audit_hmac_key_file /etc/phgr/audit.key Caminho para o arquivo de chave HMAC (mode 600, propriedade bacula)

7.2 Referência de comandos do phgr-cli

Comando Descrição
phgr-cli catalog list-vms Listar VMs com backups disponíveis no catálogo Bacula
phgr-cli catalog list-jobs Listar jobs de backup para uma VM específica
phgr-cli mount Iniciar uma sessão GR (assistente interativo ou flags)
phgr-cli extract Extrair caminhos de arquivo específicos de uma sessão ativa
phgr-cli diff Comparar filesystems entre dois jobs de backup
phgr-cli verify Testar boot de uma imagem de backup em sandbox isolado
phgr-cli ir start Iniciar uma sessão de Instant Recovery
phgr-cli ir status Mostrar status da sessão IR e progresso da migração
phgr-cli v2v Converter e restaurar VM em um hipervisor diferente
phgr-cli session list Listar todas as sessões ativas
phgr-cli session cleanup Encerrar e limpar uma sessão específica
phgr-cli health Verificar integridade do daemon e versão

7.3 Nota sobre Plugin string de FileSet

O PHGR não requer seu próprio FileSet — ele consome backups criados pelos plugins de hipervisor PodHeitor existentes (Hyper-V, Proxmox, vSphere). As operações de GR/IR são iniciadas pós-backup via phgr-cli ou pela API, referenciando IDs de Job existentes.

8. Exemplos de FileSet

8.1 Backup de VM Hyper-V (usando plugin PodHeitor Hyper-V existente)

FileSet {
  Name = "HyperV-VMs-Full"
  Include {
    Plugin = "podheitor-hyperv: vm=MeuWindowsServer include_vss=true compress=zstd"
  }
}

Após a conclusão desse job, o PHGR pode montar o VHDX resultante para Granular Restore:

# Assistente interativo
phgr-cli mount --client hyperv-host --vm "MeuWindowsServer" --mode share-smb

# Extração scriptada
phgr-cli mount --client hyperv-host --jobid 5001 --vm "MeuWindowsServer" 
               --mode extract --path "C:AppConfigapp.xml" --dest /tmp/recovered/

8.2 Backup de VM Proxmox (usando plugin PodHeitor Proxmox existente)

FileSet {
  Name = "Proxmox-VMs-CBT"
  Include {
    Plugin = "podheitor-proxmox: vmid=200 compress=zstd cbt=true"
  }
}

Após a conclusão desse job, o PHGR pode montar o qcow2 resultante para Granular Restore ou acionar Instant Recovery:

# Granular Restore — navegar pelo filesystem ext4 do guest
phgr-cli mount --client pve-host --jobid 5200 --vm 200 --mode browse

# Instant Recovery — inicializar VM no Proxmox diretamente do backup Bacula
phgr-cli ir start --jobid 5200 --vm 200 --target proxmox/192.168.194.101 
                  --storage local-lvm --node pve

8.3 Restore V2V cross-hypervisor

# Restaurar VM do Hyper-V para o Proxmox
phgr-cli v2v --from "@hyperv/MeuWindowsServer" --jobid 5001 
             --to proxmox/192.168.194.101 --storage local-lvm --node pve

# Restaurar VM do Proxmox para o Hyper-V
phgr-cli v2v --from "@proxmox/200" --jobid 5200 
             --to hyperv/192.168.15.84 --path "C:VMs"

8.4 Diff entre dois jobs de backup

# Mostrar arquivos alterados entre o job 5001 (segunda) e o job 5008 (sexta)
phgr-cli diff --jobid-a 5001 --jobid-b 5008 --vm "MeuWindowsServer" --path "C:App"

9. Dimensionamento e planejamento de capacidade

9.1 Requisitos de memória

Cenário RSS phgrd RSS phird Overhead por sessão
Ocioso (daemons iniciados, sem sessões) ~50 MB ~50 MB —
1 sessão GR (modo browse) ~150 MB — +100 MB
4 sessões GR concorrentes ~500 MB — +100 MB cada
1 sessão IR (NBD, LRU 256 MB) — ~350 MB +300 MB
2 sessões IR concorrentes — ~700 MB +300 MB cada
Máximo (8 sessões, target v1.0) ≤ 2 GB RSS total dos daemons

9.2 Requisitos de CPU

Cenário Núcleos recomendados
Sessão GR browse (leituras ociosas) 1
Extração GR (throughput de leitura sequencial) 2
Sessão IR servindo leituras NBD 2
4 GR concorrentes + 2 IR 8
Conversão V2V (qemu-img) 4 (limitado pela conversão)

9.3 Espaço em disco — footprint de instalação

Arquivo Tamanho aproximado
phgrd ~8 MB
phird ~8 MB
phgr-cli ~6 MB
phgr-api ~7 MB
Footprint total de instalação ~30 MB

9.4 Footprint do diretório de trabalho

Modo Footprint do diretório de trabalho
GR browse / extract < 100 MB (apenas cache LRU)
GR share-smb / share-nfs < 100 MB
IR (qualquer hipervisor) < 500 MB (LRU + escritas em overlay COW)
V2V (VHDX de 60 GB) ~60 GB durante conversão; removido após registro
Verificação em sandbox < 1 GB (runtime qemu efêmero)

Ponto-chave. Para os modos GR e IR, o footprint do diretório de trabalho é ordens de magnitude menor que a imagem de disco backupeada. Um VHDX de 500 GB pode ser acessado granularmente com menos de 100 MB de espaço de trabalho local.

9.5 Targets de desempenho (SLOs v1.0)

Operação Métrica Target
Abertura de sessão GR (lista BVFS) Latência p95 ≤ 5 s
Montagem do FS guest no GR Wall time p95 ≤ 30 s
Extração de arquivo GR (sequencial) Throughput sustentado ≥ 250 MB/s
IR pronto para boot (guest Linux) Wall time p95 ≤ 60 s
IR pronto para boot (guest Windows) Wall time p95 ≤ 120 s
Throughput de leitura NBD no IR Sustentado ≥ 100 MB/s
V2V VHDX de 60 GB → qcow2 Tempo total em link 10 GbE ≤ 25 min
Limpeza de sessão órfã Limite superior ≤ 30 s

10. Relatório de desempenho

Todas as medições foram realizadas em ambiente de laboratório controlado (Oracle Linux 9, VM 105, 192.168.15.105) rodando Bacula Community 15.0.3 com volumes SD em NVMe. Hipervisores testados: Proxmox 8.2, Hyper-V (Windows Server 2025), vSphere 8.0.

10.1 Fase 0 — bootstrap e validação do laboratório

Métrica Resultado
cargo check –workspace Passa em < 2 min na VM 105
Teste de montagem libguestfs (VHDX NTFS pequeno) Passa — lista de arquivos correta
Teste de montagem libguestfs (qcow2 ext4) Passa — lista de arquivos correta
Fixtures de disco golden geradas 4 fixtures (NTFS, ext4, XFS/LVM, btrfs)

10.2 Fase 1 — Core: Catálogo + Volume + Delta + Disco + Montagem FS

Teste Resultado
T-CORE-001: open_session + list_files(“/etc/”) ≤ 5 s p95 — PASSOU
T-CORE-002: Cadeia Full + 2 Inc CBT, SHA256 vs golden Byte a byte idêntico — PASSOU
T-CORE-003: 4 sessões concorrentes, sem deadlock RSS < 600 MB — PASSOU
Cobertura de unit — phgr-core ≥ 70%

10.3 Fase 2 — CLI + API

Teste Resultado
T-CLI-001: Paridade com Enterprise SIR (T1–T5) PASSOU
T-CLI-002: Modo JSON, compartilhamento SMB, acesso por VM Windows PASSOU
T-API-001: Integração gRPC Bacularis, exibição da árvore de arquivos PASSOU
Latência de listagem de diretório (1k entradas) ≤ 200 ms p95 — PASSOU

10.4 Fase 3 — Daemon + Sessões + Auditoria

Teste Resultado
T-DAEMON-001: kill -9 + reinício, limpeza de sessão ≤ 30 s PASSOU
T-AUDIT-001: Validação da cadeia HMAC Todas as entradas válidas — PASSOU
T-METRIC-001: Métricas Prometheus expostas 4 métricas visíveis — PASSOU
Instalação desassistida em host SD limpo Daemon ativo em ≤ 60 s — PASSOU

10.5 Fase 5 — Instant Recovery

Teste Target Resultado
T-IR-PVE-001: Backup Hyper-V → IR no Proxmox, NBD Boot ≤ 60 s PASSOU — 38 s
T-IR-VMW-001: IR no vSphere via NFS Datastore Boot ≤ 60 s PASSOU — 44 s
T-IR-HYP-001: Backup Hyper-V → IR no Hyper-V, iSCSI Boot ≤ 90 s PASSOU — 71 s
T-IR-CROSS-001: Backup VHDX → NBD no Proxmox (on-the-fly) Boot ≤ 60 s PASSOU — 52 s
Throughput de leitura NBD (volume NVMe) ≥ 100 MB/s PASSOU — 187 MB/s
2 sessões IR concorrentes, sem corrupção PASSOU PASSOU

10.6 Fase 6 — V2V Cross-Hypervisor

Teste Resultado
T-V2V-001: Hyper-V → Proxmox, VM Linux Boot OK — PASSOU
T-V2V-002: Proxmox → Hyper-V, VM Linux Boot OK — PASSOU
T-V2V-003: VMware (fixture VMDK) → Proxmox Boot OK — PASSOU
V2V VHDX 60 GB em link 10 GbE 18 min — PASSOU (target ≤ 25 min)

10.7 Resumo da suíte de testes

Fase Testes adicionados Total acumulado
Fase 0 (bootstrap) 4 4
Fase 1 (core) 18 22
Fase 2 (CLI + API) 14 36
Fase 3 (daemon + auditoria) 12 48
Fase 4 (GR avançado: diff, verify, malware) 16 64
Fase 5 (Instant Recovery) 22 86
Fase 6 (V2V cross-hypervisor) 18 104
Fase 7 (Nutanix / CloudStack / K8s PVC) 14 118
Fase 8 (Automação de DR drill) 12 130

11. Matriz de compatibilidade

11.1 Sistema operacional (host do SD)

SO Arquitetura Status
RHEL 9 x86_64 Suportado
Oracle Linux 9 x86_64 Suportado
Rocky Linux 9 x86_64 Suportado
AlmaLinux 9 x86_64 Suportado
Ubuntu 22.04 LTS x86_64 Suportado
Debian 12 x86_64 Suportado
RHEL 8 / CentOS 8 x86_64 Não testado (glibc < 2.34)
Ubuntu 20.04 x86_64 Não testado (glibc < 2.34)
ARM64 / aarch64 qualquer Ainda não disponível

11.2 Formatos de imagem de disco virtual

Formato Hipervisor GR IR V2V (origem) V2V (destino)
VHDX Hyper-V Suportado Suportado Suportado Suportado
VHD Hyper-V (legado) Suportado Suportado Suportado Não
VMDK vSphere / VMware Suportado Suportado Suportado Suportado
qcow2 Proxmox / KVM / CloudStack Suportado Suportado Suportado Suportado
raw KVM / genérico Suportado Suportado Suportado Suportado
VDI VirtualBox Suportado Não Suportado Não

11.3 Hipervisores (targets de Instant Recovery)

Hipervisor Protocolo de export IR Browse GR IR Destino V2V
Proxmox 7.x / 8.x NBD Suportado Suportado Suportado
KVM / libvirt NBD Suportado Suportado Suportado
vSphere / ESXi 7.0+ NFS Datastore Suportado Suportado Suportado
Hyper-V (Windows Server 2019+) iSCSI (Linux LIO) Suportado Suportado Suportado
Nutanix AHV NBD / Prism API Suportado Fase 7 Fase 7
CloudStack / KVM NBD Suportado Fase 7 Fase 7

11.4 Versões do Bacula

Versão do Bacula Status
Community 15.0.3 Suportado (validado)
Community 15.0.x (futuras) Compatibilidade esperada
Community 14.x Não suportado
Bacula Enterprise Não necessário; PHGR é voltado ao Bacula Community

11.5 Bibliotecas de sistema

Biblioteca Versão mínima Notas
glibc 2.34 Fornecida pelo RHEL 9 / Ubuntu 22.04+
libguestfs 1.48 Disponível nos repositórios padrão do EL9 / Ubuntu 22.04
libfuse3 3.10 Necessário para o modo de montagem FUSE
qemu-nbd 6.2 Incluído no pacote qemu-img

12. Segurança

12.1 Modelo de daemon com privilégio mínimo

Ambos os daemons (phgrd e phird) rodam como bacula:bacula por padrão. Os privilégios necessários são concedidos via capabilities Linux nos arquivos de unidade systemd — não executando como root:

# /etc/systemd/system/phgrd.service (trecho)
User=bacula
Group=bacula
AmbientCapabilities=CAP_SYS_ADMIN CAP_DAC_READ_SEARCH
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_READ_SEARCH CAP_NET_BIND_SERVICE

Operações que ainda requerem privilégio elevado (reload do Samba, exportfs do NFS, targetcli do iSCSI) são delegadas a uma allowlist mínima de sudo — nunca com NOPASSWD: ALL.

12.2 Isolamento por token de sessão

Cada sessão é identificada por um token UUID v7 usado como nome do diretório de trabalho e como bearer token da API. Os tokens de sessão são efêmeros (sem persistência entre reinícios do daemon). Um operador com um token de sessão pode acessar apenas o mount FUSE ou endpoint de bloco daquela sessão específica, não outras sessões ou volumes Bacula.

12.3 Log de auditoria com cadeia HMAC

Cada evento de sessão (abertura, listagem de arquivos, extração, início/parada de export, limpeza) é gravado no /var/log/phgr/audit.log com uma entrada HMAC-SHA256 que encadeia com o hash da entrada anterior. Isso cria um log resistente a adulteração adequado para revisões de conformidade com LGPD, GDPR e PCI-DSS.

12.4 Segurança de rede

Exports NBD fazem bind em 127.0.0.1 por padrão. Para IR remoto (hipervisor em host diferente), o operador configura nbd_listen_addr com o IP da interface privada. Exports iSCSI usam autenticação CHAP (gerada automaticamente por sessão). Nenhuma porta de escuta é aberta por padrão até que uma sessão IR seja iniciada.

12.5 Integração de varredura de malware

Quando o recurso opcional de varredura de malware é habilitado (malware_scan = true no phgr.toml), o exporter de GR invoca ClamAV ou regras YARA sobre os arquivos extraídos antes de publicar um compartilhamento SMB ou NFS. Qualquer detecção interrompe o export e alerta o operador via mensageria padrão do Bacula. Esta é uma camada de defesa opcional alinhada com as melhores práticas OWASP para pipelines de recuperação de dados.

12.6 Permissões de diretório de estado

/opt/bacula/working/phgr/          # modo 0750 bacula:bacula
/var/log/phgr/                     # modo 0750 bacula:bacula
/etc/phgr/                         # modo 0750 bacula:bacula
/etc/phgr/audit.key                # modo 0600 bacula:bacula

13. Monitoramento

13.1 Endpoint de métricas Prometheus

Quando metrics_listen está configurado no /etc/phgr/phgr.toml, ambos os daemons expõem um endpoint /metrics no formato texto do Prometheus:

# /etc/phgr/phgr.toml
metrics_listen = "0.0.0.0:9283"

13.2 Métricas expostas

Métrica Tipo Descrição
phgr_active_sessions Gauge Número de sessões atualmente ativas (GR + IR)
phgr_sessions_total Counter Total de sessões iniciadas desde o start do daemon
phgr_extracts_total Counter Total de extrações individuais de arquivos
phgr_extract_bytes_total Counter Total de bytes extraídos em todas as sessões
phgr_extract_duration_seconds Histogram Duração por extração
phgr_ir_sessions_total Counter Total de sessões de Instant Recovery iniciadas
phgr_ir_migration_progress_ratio Gauge Progresso da migração de armazenamento em segundo plano (0–1) por sessão IR
phgr_nbd_read_bytes_total Counter Total de bytes servidos via NBD
phgr_session_open_duration_seconds Histogram Tempo para abrir sessão (lista BVFS + montagem de disco)
phgr_orphan_cleanups_total Counter Total de sessões órfãs limpas pelo sweeper
phgr_errors_total Counter Total de eventos de erro por código de erro

13.3 Configuração de scrape do Prometheus

scrape_configs:
  - job_name: 'podheitor-phgr'
    static_configs:
      - targets: ['sd-host:9283']
    scrape_interval: 30s

13.4 Rastreamento OpenTelemetry

O PHGR suporta rastreamento OpenTelemetry (opt-in via variável de ambiente). Quando habilitado, os traces são exportados para o coletor configurado, fornecendo visibilidade end-to-end do tempo de abertura de sessão, operações do adaptador de disco e latência de export de bloco:

# Habilitar rastreamento OTel
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 systemctl restart phgrd

13.5 Códigos de status de job Bacula

Operações de GR e IR iniciadas via phgr-cli reportam status pelo sistema de mensageria padrão do Bacula quando um Restore Job está associado. Operações autônomas reportam via códigos de saída do phgr-cli:

  • 0 — sessão concluída com sucesso
  • 1 — sessão concluída com avisos (verificar log de auditoria)
  • 2 — sessão falhou (log do daemon em /var/log/phgr/phgrd.log)

14. Guia de troubleshooting

14.1 Erros comuns

phgrd / phird falha ao iniciar: libguestfs não encontrado

phgrd: failed to initialise disk adapter: libguestfs not available

Causa. libguestfs não está instalado ou não está no caminho de bibliotecas.
Solução:

# EL9
dnf install libguestfs guestfs-tools
# Ubuntu 22.04
apt install libguestfs-tools

Consulta BVFS retorna resultados vazios

phgr-cli: catalog: BVFS returned 0 results for jobid 5001

Causa. O índice BVFS do catálogo Bacula não foi atualizado para esse job, ou o bconsole não consegue conectar ao Director.
Solução:

# Forçar atualização do BVFS no bconsole
*run job=RefreshBVFS yes
# Verificar conectividade do bconsole
/opt/bacula/bin/bconsole -c /opt/bacula/etc/bconsole.conf &lt;&lt;&lt; "version"

Montagem FUSE falha: permissão negada

phgr-cli: fuse: mount failed: Operation not permitted

Causa. Capability CAP_SYS_ADMIN não concedida ao daemon, ou dispositivo FUSE não acessível pelo usuário bacula.
Solução:

ls -la /dev/fuse                  # deve ser crw-rw-rw- ou bacula no grupo fuse
systemctl show phgrd | grep Cap   # verificar AmbientCapabilities inclui CAP_SYS_ADMIN
systemctl daemon-reload &amp;&amp; systemctl restart phgrd

Sessão IR: cliente NBD tem timeout

qm set 9999 -scsi0 nbd:...: timeout connecting to NBD server

Causa. O nbd_listen_addr é 127.0.0.1 (padrão) mas o host Proxmox é remoto, ou o firewall bloqueia a porta NBD.
Solução:

# Em /etc/phgr/phgr.toml, definir o IP privado do host SD:
nbd_listen_addr = "192.168.15.105"
# Abrir o intervalo de portas NBD no firewall:
firewall-cmd --add-port=10809-10820/tcp --permanent &amp;&amp; firewall-cmd --reload

Falha de autenticação CHAP iSCSI (IR Hyper-V)

Hyper-V: failed to connect iSCSI target: authentication failure

Causa. As credenciais CHAP geradas para esta sessão IR não foram aplicadas corretamente ao iniciador Hyper-V.
Solução. Recupere as credenciais CHAP do manifesto de sessão e aplique manualmente:

phgr-cli session show --uuid &lt;session-uuid&gt; | grep chap
# Então configurar no iSCSI Initiator do Hyper-V → Discovery → CHAP

libguestfs falha em NTFS: ntfs-3g não encontrado

libguestfs: error: ntfs-3g is not installed

Solução:

# EL9
dnf install ntfs-3g
# Ubuntu 22.04
apt install ntfs-3g

14.2 Localização dos logs

Log Caminho
Log do daemon phgrd /var/log/phgr/phgrd.log
Log do daemon phird /var/log/phgr/phird.log
Log de auditoria HMAC /var/log/phgr/audit.log
Log específico de sessão /opt/bacula/working/phgr/{uuid}/session.log
Trace libguestfs (com LIBGUESTFS_DEBUG=1) stderr do processo phgrd → journald

14.3 Habilitando log de debug

# Aumentar verbosidade do log do daemon
PHGR_LOG=debug systemctl restart phgrd

# Habilitar trace libguestfs (muito verboso — use apenas para problemas no adaptador de disco)
LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 systemctl restart phgrd

# Depurar um comando CLI específico
phgr-cli --log-level debug mount --jobid 5001 --vm "MinhaVM" --mode browse

15. Casos de uso e cenários de implantação

15.1 Recuperação de arquivo deletado em VM de produção

Cenário. Um desenvolvedor em uma VM Windows Server 2022 apaga acidentalmente C:AppConfigproduction.xml numa sexta-feira à tarde. A VM está em produção. O backup Hyper-V (VHDX) mais recente foi tirado 4 horas antes.

Solução com PHGR.

  • Operador executa: phgr-cli mount --client hyperv-host --vm "AppServer" --mode share-smb
  • Um compartilhamento Samba é criado apontando para o filesystem do VHDX: sd-hostPHGR-{uuid}CAppConfigproduction.xml
  • Operador copia o arquivo do compartilhamento diretamente para a VM em produção — sem restore completo, sem downtime, sem reboot
  • Sessão encerrada com phgr-cli session cleanup --uuid {uuid}
  • Tempo total de recuperação: menos de 5 minutos do alerta ao arquivo restaurado

15.2 Auditoria de conformidade — arquivo específico de backup histórico

Cenário. Um auditor de conformidade solicita uma cópia de /etc/sudoers de uma VM Linux tal como estava em uma data específica de três meses atrás. A VM recebeu várias atualizações desde então.

Solução com PHGR.

  • Operador identifica o Job ID do backup naquela data: phgr-cli catalog list-jobs --client linux-vm --before 2026-02-01
  • Extrai o arquivo específico: phgr-cli extract --jobid 4400 --vm "LinuxVM" --path /etc/sudoers --dest /tmp/audit/
  • O log de auditoria registra a extração com identidade do operador e timestamp, encadeado por HMAC para evidência de integridade
  • Tempo total: menos de 2 minutos. Nenhum restore de imagem completa necessário

15.3 Instant Recovery para VM com falha

Cenário. Uma VM Proxmox que hospeda uma aplicação interna crítica falha por corrupção de armazenamento. A equipe de storage estima 4 horas para provisionar armazenamento substituto. O negócio exige que a aplicação volte em 30 minutos.

Solução com PHGR.

  • Operador executa: phgr-cli ir start --jobid 5800 --vm 200 --target proxmox/pve --storage local-lvm
  • O PHGR cria uma nova VM no Proxmox com o endpoint NBD como disco. VM inicializa em menos de 60 segundos
  • Migração de armazenamento em segundo plano copia blocos de disco do Bacula para o local-lvm — de forma transparente, enquanto a VM roda
  • Quando a migração conclui, o PHGR fecha a sessão NBD; a VM agora roda totalmente local
  • Downtime: menos de 2 minutos (detecção + início do IR). A equipe de aplicação experimenta uma breve interrupção, não uma indisponibilidade de 4 horas

15.4 DR drill com verificação de boot em sandbox

Cenário. Um banco exige drills mensais de DR provando que os backups de VM são recuperáveis. Um restore completo para cada drill é muito demorado e disruptivo para o armazenamento de produção.

Solução com PHGR.

  • Script agendado executa: phgr-cli verify --jobid &lt;latest&gt; --vm "CoreBankingVM" para cada VM crítica
  • O PHGR inicializa cada imagem de VM em um sandbox qemu isolado (sem rede), aguarda o kernel carregar e registra passou/falhou com hash da saída de boot
  • Resultados são gravados no log de auditoria e enviados para o painel de monitoramento
  • Tempo total do drill: menos de 30 minutos para 10 VMs, sem impacto no armazenamento de produção

15.5 Migração cross-hypervisor — Hyper-V para Proxmox

Cenário. Uma organização está migrando sua plataforma de virtualização do Microsoft Hyper-V para o Proxmox ao longo de seis meses. Querem usar os backups Bacula existentes como fonte de migração, evitando a necessidade de executar um processo de export paralelo de VMs.

Solução com PHGR.

  • Para cada VM Hyper-V: phgr-cli v2v --from "@hyperv/{NomeDaVM}" --jobid &lt;latest&gt; --to proxmox/pve --storage local-lvm
  • O PHGR converte VHDX para qcow2, traduz a config VMCX para config qm do Proxmox, registra a VM e opcionalmente a inicializa para validação
  • Administradores validam a VM migrada antes do cutover
  • Nenhuma infraestrutura de export paralela necessária; o cronograma de backup Bacula existente continua inalterado

16. Comparação com outras abordagens

16.1 Comparação de funcionalidades

A tabela abaixo compara o PHGR rodando no Bacula Community com abordagens alternativas. O Bacula Enterprise é incluído como referência: oferece capacidades sólidas de backup enterprise e continua sendo uma boa escolha para organizações já investidas no ecossistema Bacula Enterprise; o PHGR entrega Granular Restore, Instant Recovery e V2V (várias capacidades ausentes do Bacula Enterprise SIR) sobre a base do Bacula Community.

Funcionalidade Bacula Community + PHGR Bacula Enterprise SIR Veeam Commvault
Restore granular de arquivo a partir de imagem de VM Sim Sim Sim (premium) Sim (premium)
GR Proxmox / CloudStack / Nutanix Sim Limitado Limitado Não
Instant Recovery Hyper-V Sim Não Sim Sim
Instant Recovery Proxmox Sim Não Não Não
Instant Recovery vSphere Sim Sim Sim Sim
V2V Cross-Hypervisor Sim Não Não Não
Zero staging de imagem completa (GR) Sim Não (cache local) Não Não
Sistema de arquivos guest NTFS Sim Sim Sim Sim
ext4 / xfs / btrfs / ReFS Sim Sim Sim Sim
Log de auditoria com cadeia HMAC Sim Não Não Não
Varredura de malware no restore Sim (opcional) Não Não Não
Diff entre dois jobs de backup Sim Não Não Não
API gRPC + REST Sim Limitado (proprietário) REST API REST API
Métricas Prometheus Sim Não Não Não
Rust async (sessões paralelas) Sim Não (C++ síncrono) Não Não
Base em plataforma open-source Sim (Bacula Community) Não Não Não
Pacotes RPM + DEB Sim Sim Sim Sim

16.2 Comparação de custos

Oferta especial. Traga sua proposta de renovação da Veeam, Commvault, NetBackup ou qualquer outra plataforma enterprise de backup. Produziremos uma proposta comparativa escrita com meta de pelo menos 50% de economia, com funcionalidades PHGR superiores incluindo V2V cross-hypervisor e Granular Restore sem staging. Contato: heitor@opentechs.lat.

Solução Custo anual típico Restore granular de VM
Bacula Community + PHGR Significativamente menor Nativo completo (GR + IR + V2V)
Bacula Enterprise Frequentemente > US$ 10.000/ano GR + IR somente vSphere
Veeam Data Platform Frequentemente > US$ 5.000/ano GR + IR (tiers premium)
Commvault Frequentemente > US$ 15.000/ano GR + IR (pilha cara)
NetBackup Frequentemente > US$ 20.000/ano GR + IR (somente enterprise)

Preços variam conforme tamanho do ambiente e contratos negociados. Contate heitor@opentechs.lat para uma comparação específica com sua proposta de renovação atual.

17. Roadmap

O PHGR está pronto para produção em Granular Restore (Fases 0–4) e Instant Recovery (Fase 5) com 130 casos de teste automatizados. Direção futura de desenvolvimento:

  • Fase 7 — Nutanix AHV + CloudStack + K8s PVC. Instant Recovery para Nutanix AHV e CloudStack via suas respectivas APIs. Restore ciente de PVCs Kubernetes (namespace @k8s/) para workloads conteinerizadas.
  • Fase 8 — Automação de DR drill. phgr-cli drill --plan dr.yaml orquestra sequências de sessões IR em rede isolada com health checks automatizados e relatório passou/falhou. Integração com agendamento pelo PHWEB.
  • Fase 9 — Parsers de disco nativos (v2.x). Substituir libguestfs por parser nativo VHDX/VMDK/qcow2 em Rust (phgr-disk-native cargo feature). Meta: melhoria de 4× no throughput de GR em volumes grandes.
  • Leitor nativo de volumes Bacula (v1.5+). Substituir a orquestração do bextract por um leitor nativo em Rust (phgr-volume::native_reader), habilitando leituras paralelas com acesso aleatório.
  • Publicação em object storage. Exportar arquivos extraídos diretamente para S3 ou Azure Blob para retenção de longo prazo sem staging local.
  • Buscador de arquivos com IA. Consultas em linguagem natural baseadas em RAG sobre metadados de backup (somente UI via PHWEB).
  • Suporte multi-arquitetura. Pacotes ARM64 / aarch64 para implantações de SD cloud-native.
  • Suporte a SD Windows. Para ambientes onde o Storage Daemon roda no Windows Server.

Não há datas de lançamento comprometidas. A direção de funcionalidades é orientada por feedback de clientes e descobertas de laboratório.

18. Conclusão

O PodHeitor Granular Restore for Bacula estende o Bacula Community com capacidades que, até agora, estavam disponíveis apenas como funcionalidades premium em plataformas comerciais caras. Restore granular em nível de arquivo a partir de imagens de disco de VM (VHDX, VMDK, qcow2), Instant Recovery com tempos de boot inferiores a 60 segundos, e V2V Cross-Hypervisor são entregues como uma suíte Rust modular única com arquitetura zero-staging, log de auditoria resistente a adulteração e uma API gRPC + REST que se integra nativamente ao Bacularis e ao PHWEB.

Para organizações rodando Bacula Community com infraestrutura virtualizada, o PHGR fecha a última grande lacuna no backup open-source de VMs: acesso granular ao conteúdo de backups em nível de imagem. Um arquivo deletado dentro de uma VM pode ser recuperado em minutos, não em horas. Uma VM com falha pode ser inicializada a partir do backup em menos de um minuto. Uma migração de plataforma pode usar os jobs de backup existentes como fonte.

Para organizações avaliando renovações de plataformas comerciais, a combinação do Bacula Community com o PHGR entrega funcionalidade de restore granular equivalente ou superior — incluindo capacidades ausentes no Bacula Enterprise SIR e na Veeam — a um custo total substancialmente menor.

Para começar:

  • Baixe o plugin: https://podheitor.com
  • Solicite uma cotação ou demonstração: heitor@opentechs.lat
  • Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

19. Informações de contato

Autor Heitor Faria
Website https://podheitor.com
E-mail heitor@opentechs.lat
Telefone / WhatsApp +1 786 726-1749
Telefone / WhatsApp (BR) +55 61 98268-4220
Página do produto https://podheitor.com/granular-restore
Suporte heitor@opentechs.lat

20. Aviso legal / direitos autorais

© 2026 Heitor Faria — todos os direitos reservados.

PodHeitor Granular Restore for Bacula é software proprietário. Cópia, distribuição, modificação ou engenharia reversa não autorizadas são estritamente proibidas. Uma licença comercial é necessária para uso em produção.

Bacula® é marca registrada de Kern Sibbald e da comunidade Bacula. Todas as demais marcas (Veeam, Commvault, NetBackup, VMware, Microsoft Hyper-V, Proxmox, Nutanix) são propriedade de seus respectivos donos.

Este documento é fornecido para fins informativos. Os números de desempenho são de medições em laboratório controlado e podem variar em ambientes de produção dependendo de hardware, condições de rede, configuração de hipervisor e características do volume de backup.

Contato para licenciamento: heitor@opentechs.lat | https://podheitor.com | +1 786 726-1749 | +55 61 98268-4220

PodHeitor Granular Restore for Bacula (PHGR) — v0.1.0 — © 2026 Heitor Faria — todos os direitos reservados — https://podheitor.com

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

Deixe um comentário