Dominando o Proxmox Backup Server: Deduplicação e Imutabilidade na Prática

Vamos ser honestos por um momento: você não tem um backup. Você tem, no máximo, uma esperança digitalizada de que seus dados estarão lá quando o ransomware criptografar seu servidor de arquivos ou quando aquele disco SAS rodando 24/7 desde 2018 finalmente decidir morrer. Backup não existe. Só existe Restore. Se você não testou a restauração, você tem apenas dados caros ocupando espaço em disco.

O Proxmox Backup Server (PBS) mudou o jogo para homelabs e pequenas empresas ao trazer deduplicação incremental para as massas. Mas ele não é mágico. Ele é uma ferramenta de Storage que exige respeito às leis da física dos discos. Se você tratar o PBS como um repositório SMB qualquer, você vai perder dados. Vamos dissecar como arquitetar essa besta para que ela salve sua pele, e não apenas consuma seus IOPS.

Resumo em 30 segundos

• Deduplicação custa IOPS: O PBS quebra arquivos em milhões de pedaços (chunks). Ler e escrever esses pedaços exige performance aleatória que HDDs sozinhos não conseguem entregar.
• Metadados em Flash é obrigatório: Para evitar que tarefas de manutenção (Garbage Collection) levem dias, use SSDs/NVMe para os metadados do ZFS (Special Devices).
• Confiança Zero no Disco: Jobs de verificação (Verify Jobs) são a única garantia de que o bit gravado hoje é o mesmo que será lido amanhã.

Quando o RPO colide com a física dos discos mecânicos

O maior erro que vejo administradores cometerem é desenhar o RPO (Recovery Point Objective) baseado no desejo da diretoria, e não na capacidade do subsistema de disco. O PBS opera num modelo "incremental-forever". Isso significa que, após o primeiro backup full, tudo são apenas deltas. Parece leve, certo? Errado.

Para montar um ponto de restauração, o PBS precisa consultar um índice massivo de hashes SHA-256. Se o seu datastore reside em um array de discos mecânicos (HDD) de 7200 RPM, você está limitado a cerca de 80 a 120 IOPS aleatórios por disco.

Quando você inicia cinco backups simultâneos de VMs, o PBS não está escrevendo um fluxo contínuo e sequencial. Ele está fazendo lookup de chunks existentes, verificando hashes e escrevendo novos chunks em locais dispersos. Isso gera um padrão de I/O altamente aleatório. Se o seu array não aguentar a carga, a latência de gravação dispara, o iowait do servidor sobe e seus backups começam a falhar por timeout. O RPO de 15 minutos que você prometeu torna-se tecnicamente impossível porque a física do braço mecânico do HD não permite.

💡 Dica Pro: Monitore a "IO Delay" no painel do Proxmox. Se ela passar consistentemente de 5-10% durante os backups, seus discos são o gargalo. Considere adicionar um ZIL (ZFS Intent Log) em Optane ou NVMe de alta durabilidade para absorver as escritas síncronas.

A matemática por trás do chunking variável e do formato pxar

Diferente de sistemas de backup legados que copiam arquivos inteiros, o PBS usa chunking variável. Por que isso importa para o seu storage?

Imagine que você tem um disco virtual de 100GB. Se usássemos blocos fixos de 4MB e você inserisse 1 byte no início do arquivo, todos os blocos subsequentes seriam deslocados e seus hashes mudariam. O backup seria, efetivamente, um novo full.

Com o chunking variável, o algoritmo detecta limites de blocos baseados no conteúdo (rolling hash), não na posição fixa. Isso isola a mudança. Apenas o chunk alterado e, talvez, seus vizinhos imediatos são regravados. O resto do disco — gigabytes de dados — é apenas referenciado.

Fig. 1: O fluxo de quebra (chunking) e hashing garante que apenas blocos únicos sejam gravados no disco.

O formato pxar (Proxmox File Archive) é o contêiner que armazena esses dados. Ele é desenhado para alta vazão, mas gera uma quantidade absurda de metadados. Cada chunk tem um checksum. Cada backup tem um manifesto. Se o seu storage não conseguir entregar os metadados rápido o suficiente, a CPU do servidor ficará ociosa esperando o disco responder "onde está o bloco X?".

A armadilha de rodar Garbage Collection em HDDs convencionais

Aqui é onde os sonhos de backup morrem. A Deduplicação é ótima para economizar espaço, mas ela cria um problema: como saber quais chunks não são mais usados por nenhum backup antigo e podem ser deletados?

Entra o Garbage Collection (GC).

O processo de GC no PBS precisa ler todos os índices de todos os snapshots de backup para marcar quais chunks estão "vivos". Em um datastore de 10TB cheio de backups de VMs Windows (que adoram mudar pequenos blocos), isso pode significar milhões de acessos a pequenos arquivos.

Se você roda isso em um RAID-Z2 de HDDs mecânicos sem aceleração:

1. A cabeça de leitura do disco vai pular freneticamente (thrashing).

2. A performance do array cai para perto de zero.

3. Se um backup tentar rodar durante o GC, ele vai falhar ou demorar 10x mais.

Já vi processos de GC levarem mais de 72 horas em arrays de 40TB compostos apenas por HDDs. Durante esse tempo, seu RPO está em risco.

Fig. 2: Aceleração de metadados: onde o SSD faz a diferença entre um GC de 1 hora e um de 3 dias.

Arquitetando performance com ZFS Special Devices e Namespaces

A solução para o problema do GC e da performance de leitura não é "comprar mais discos", é "comprar os discos certos". O ZFS, sistema de arquivos subjacente recomendado para o PBS, possui uma funcionalidade crítica chamada Special Device.

Ao adicionar um espelho (mirror) de SSDs ou NVMes ao seu pool de HDDs e designá-lo como special, você instrui o ZFS a armazenar todos os metadados e, opcionalmente, blocos de dados pequenos (ex: <64K) nesses drives rápidos.

O impacto é brutal:

• Os HDDs ficam responsáveis apenas pelo "streaming" dos blocos de dados grandes (onde eles são bons).

• Os SSDs lidam com a busca de arquivos, atualizações de atime e travessia de diretórios.

• O tempo de Garbage Collection cai de dias para minutos ou poucas horas.

⚠️ Perigo: Se o seu special device falhar e não tiver redundância (RAID1/Mirror), você perde todo o pool. Nunca use um único SSD como special device para um array de dados críticos. A regra 3-2-1 exige redundância também no hardware.

Namespaces: Organização sem penalidade

Muitos administradores criam múltiplos Datastores para separar departamentos ou clientes. Isso é ineficiente pois quebra a deduplicação global. O PBS introduziu Namespaces. Eles funcionam como pastas lógicas dentro do mesmo Datastore.

Isso permite que você tenha Datastore-Principal/ClienteA e Datastore-Principal/ClienteB. Eles compartilham os mesmos chunks dedupicados (economizando TBs de espaço se ambos usarem o mesmo SO base), mas permitem permissões e políticas de retenção (Prune) separadas.

Validando a consistência criptográfica com Verify Jobs automatizados

Bit rot é real. Raios cósmicos, firmware de disco bugado ou cabos SATA ruins podem inverter um bit silenciosamente. Em um backup tradicional, você só descobre isso na hora do restore, quando o arquivo está corrompido.

O PBS permite agendar Verify Jobs. Essa tarefa relê os chunks do disco, recalcula o hash SHA-256 e compara com o registro no índice. Se houver divergência, o backup é marcado como corrompido.

Você deve ter uma política de re-verificação. O ideal é re-verificar snapshots antigos a cada 30 ou 45 dias. Isso garante que a mídia física (seus HDDs) ainda está honrando o que foi gravado. Lembre-se: um backup não verificado é apenas um arquivo aleatório ocupando espaço.

Imutabilidade: A única defesa contra Ransomware

Se um atacante ganhar acesso root ao seu servidor de backup, ele pode deletar tudo. A única defesa lógica (além do Air Gap físico, como Fitas LTO) é a imutabilidade.

O PBS não possui "Imutabilidade" no sentido estrito de WORM (Write Once, Read Many) integrado ao hardware, mas oferece proteção via Maintenance Modes e políticas de retenção. No entanto, a funcionalidade mais crítica é o Ransomware Protection via Sync Jobs para um local remoto (Off-site) que é "Pull-only".

O servidor remoto se conecta ao local, puxa os dados, e o servidor local não tem credenciais para acessar o remoto. Se o local for comprometido, o remoto permanece seguro.

Além disso, você pode configurar datastores ou snapshots específicos com a flag "Protected". Isso impede que as tarefas automáticas de limpeza (Prune) removam esses backups, garantindo que você tenha pontos de restauração anuais ou mensais preservados, não importa o que a política de retenção diga.

Fig. 3: A flag 'Protected' impede que as políticas de retenção (Prune) eliminem backups críticos inadvertidamente.

O alerta final: A falácia do "Configure e Esqueça"

A tecnologia de deduplicação do Proxmox Backup Server é fascinante, mas ela adiciona complexidade. Um arquivo corrompido em um sistema tradicional afeta um arquivo. Um chunk corrompido no PBS pode afetar todas as VMs que dependem daquele bloco base (ex: o bloco zero do Windows Server 2022).

Não confie cegamente no dashboard verde.

1. Configure Verify Jobs agressivos.

2. Use ZFS com Special Devices espelhados; sem isso, a recuperação em desastre será lenta demais para ser útil.

3. Faça testes de restauração trimestrais. Suba a VM em uma rede isolada, faça login, abra uma planilha. Se você não consegue abrir o arquivo, o backup falhou.

Seus dados valem mais que a economia de não comprar dois SSDs para metadados. Arquitetem como pessimistas para poderem dormir como otimistas.

Referências & Leitura Complementar

1. OpenZFS Documentation - Special Allocation Class: Detalhes técnicos sobre como a alocação de metadados funciona e os riscos de vdevs especiais.

2. Proxmox Backup Server Documentation - Datastore Configuration: A bíblia oficial sobre chunks, índices e estrutura de diretórios .chunks.

3. RFC 6234 - US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF): Para entender a base matemática da integridade referencial usada no chunking do PBS.

Perguntas Frequentes

P: Posso usar discos SMR (Shingled Magnetic Recording) com Proxmox Backup Server? R: Absolutamente não. Discos SMR têm performance de reescrita terrível. O PBS faz muita reescrita de metadados e chunks. O uso de SMR causará falhas nos backups e timeouts no sistema. Use apenas CMR/PMR.

P: Qual o tamanho ideal do chunk para deduplicação? R: O PBS gerencia isso automaticamente, geralmente variando até 4MB. Não há necessidade (nem facilidade) de ajustar isso manualmente, pois o algoritmo é otimizado para equilibrar tamanho do índice e taxa de deduplicação.

P: Preciso de RAID de Hardware para o PBS? R: Não. O ZFS prefere acesso direto aos discos (HBA Mode). O RAID de hardware oculta a geometria do disco e impede que o ZFS faça a autocorreção de dados (bit rot healing) corretamente. Use um HBA IT Mode.

P: Como calculo o tamanho necessário para o Special Device? R: Uma regra prática conservadora é 0.3% a 0.5% da capacidade total do pool para metadados puros. Se você planeja armazenar também pequenos blocos de dados no SSD, precisará de mais espaço. Para 100TB de HDD, um espelho de 480GB ou 960GB SSD é um bom ponto de partida.