Backup é aquele investimento que ninguém percebe até o dia em que precisa. E, no dia em que precisa, três perguntas decidem tudo: o backup existe, ele restaura, e ele restaura rápido. O Proxmox Backup Server (PBS) foi desenhado para responder "sim" às três.

O que é o PBS

O PBS é a solução de backup do ecossistema Proxmox, feita para proteger VMs, containers e hosts. Ele conversa nativamente com o Proxmox VE, mas resolve o problema que todo mundo conhece: backup ocupando espaço demais, demorando demais e sem garantia de que vai restaurar.

Três mecanismos fazem o trabalho pesado: deduplicação, compressão e criptografia. E dois processos garantem que o resultado se sustente no tempo: verificação de integridade e retenção com liberação real de espaço.

Como o PBS se organiza por dentro

Entender a estrutura ajuda a operar sem sustos. São quatro peças:

• Datastore: o repositório onde os backups vivem. Fica sobre um sistema de arquivos do servidor — ZFS é a escolha comum, por integridade e flexibilidade.
• Chunk store: dentro do datastore, os dados são guardados em blocos (chunks) endereçados pelo próprio checksum. É a base da deduplicação.
• Índices de backup: cada snapshot é, na prática, uma lista de quais chunks compõem aquele disco naquele momento. Isso é o que permite ter dezenas de pontos de restauração sem multiplicar espaço.
• Cliente: no Proxmox VE, a integração é nativa. Para servidores físicos e outros sistemas Linux, o proxmox-backup-client faz backup de diretórios e blocos direto para o datastore.

Deduplicação: pare de guardar a mesma coisa

Servidores têm muito dado repetido — o mesmo sistema operacional, as mesmas bibliotecas, os mesmos arquivos em dezenas de máquinas. O PBS trabalha em blocos: cada bloco único é guardado uma vez. Se dez VMs têm o mesmo bloco, ele existe uma vez no repositório.

A deduplicação é global no datastore, não por VM. Ou seja, ela funciona tanto entre backups diferentes da mesma máquina quanto entre máquinas distintas que compartilham o mesmo sistema operacional. Em parques homogêneos — dezenas de VMs com a mesma distribuição — o ganho é impressionante.

O efeito prático é grande. Backups diários que, somados, ocupariam terabytes cabem em uma fração disso. E como só os blocos novos são gravados a cada execução, o backup incremental fica rápido.

Incremental de verdade: o dirty bitmap

Há um detalhe que explica por que um backup de VM no PBS pode terminar em minutos. Enquanto a VM continua ligada, o QEMU mantém um mapa dos blocos que mudaram desde o último backup — o dirty bitmap. Na execução seguinte, o PBS lê apenas esses blocos, em vez de varrer o disco inteiro.

A consequência operacional é importante: se a VM é reiniciada ou migrada, o bitmap se perde e o próximo backup volta a ler o disco completo. Não é erro, é comportamento esperado — só ajuda a entender por que uma execução ocasional demora mais que as outras.

Compressão Zstandard: menos espaço, sem penalizar velocidade

Sobre os blocos deduplicados, o PBS aplica compressão com Zstandard (zstd) — um algoritmo que entrega ótima taxa de compressão sem cobrar caro em CPU. O resultado: repositório menor e janela de backup mais curta ao mesmo tempo.

Criptografia AES-256-GCM: seguro do lado do cliente

O PBS cifra os dados com AES-256-GCM do lado do cliente, antes de saírem para o servidor de backup. Na prática, isso significa que quem tem acesso ao repositório não tem acesso ao conteúdo — a chave fica com você. É a diferença entre "ter backup" e "ter backup que não vira vazamento".

E aqui vai o aviso mais importante deste artigo: sem a chave, não há restauração. Nem o fornecedor, nem a Proxmox, nem ninguém recupera o conteúdo. Guardar a chave fora do ambiente que ela protege — em gerenciador de segredos, cofre físico ou ambos — não é burocracia, é a diferença entre um backup útil e um arquivo inútil cifrado.

Verificação e retenção: o backup que você pode confiar

Ter backup não basta; ele precisa restaurar. O PBS faz verificação de integridade dos backups periodicamente, comparando checksums e apontando qualquer corrupção antes que ela seja um problema. Somado às políticas de retenção (quantos diários, semanais, mensais manter), você tem controle real do ciclo de vida do dado.

Vale entender que retenção no PBS acontece em duas etapas, e confundi-las é a causa mais comum de "o disco não liberou espaço":

1. Prune aplica a política e marca como removíveis os snapshots que não se encaixam mais em nenhuma regra de retenção.
2. Garbage collection é o processo que efetivamente apaga os chunks que nenhum índice referencia mais, liberando espaço em disco.

Sem GC agendado, o prune sozinho não devolve espaço. Os dois precisam estar na rotina, e o GC merece uma janela em que o datastore não esteja sob carga máxima.

Restauração: as três formas que importam

A qualidade de uma solução de backup se mede na restauração. O PBS oferece caminhos diferentes para situações diferentes:

• Restauração completa: recria a VM ou o container a partir do snapshot. É o caminho para perda de máquina, corrupção grave ou migração.
• Restauração de arquivo único: você navega dentro do backup e extrai apenas o que precisa. Resolve o caso mais frequente do dia a dia — alguém apagou uma pasta, uma configuração precisa voltar — sem derrubar nada.
• Live restore: a VM começa a rodar enquanto os dados ainda estão sendo trazidos do backup. Reduz drasticamente o tempo até o serviço voltar, ao custo de desempenho degradado durante a transferência.

Saber qual usar em qual incidente, e ter isso escrito antes da crise, é metade da resposta a desastres.

Cópia externa: como o PBS sustenta a regra 3-2-1

Backup no mesmo prédio da produção protege contra falha de disco, não contra incêndio, roubo ou ransomware que alcance a rede. O PBS resolve isso com sync jobs: um segundo servidor PBS, em outro site, sincroniza os snapshots do primeiro. A deduplicação continua valendo, então o tráfego entre sites transporta apenas os chunks novos.

Com namespaces, um único servidor remoto pode receber backups de vários clientes ou unidades de negócio mantendo separação lógica e permissões distintas — arquitetura que provedores e MSPs usam para oferecer backup como serviço.

Dimensionar o datastore sem se arrepender

O erro clássico é tratar o servidor de backup como sobra de hardware. Alguns pontos que definem se o PBS voa ou arrasta:

• IOPS importam. Verificação e garbage collection percorrem grandes quantidades de metadados. Discos mecânicos sozinhos tornam essas tarefas lentas e barulhentas.
• Metadados em SSD. Em ZFS, um special device em SSD para metadados acelera GC e verify de forma perceptível, mantendo os dados em discos de maior capacidade.
• Espaço com folga. Planeje para a retenção desejada mais margem de crescimento; datastore cheio impede backup e complica o próprio GC.
• Rede dedicada. Backup competindo com tráfego de produção na mesma interface prejudica os dois.

Erros comuns que aparecem só na restauração

• Retenção configurada, GC não agendado — e o disco enche em silêncio.
• Verificação desativada "para economizar I/O", e a corrupção só aparece na hora do desespero.
• Chave de criptografia guardada apenas dentro do ambiente protegido.
• Nenhuma restauração de teste no ano — ninguém sabe quanto tempo leva voltar.
• Backup e produção no mesmo storage, ou pior, no mesmo servidor.

Onde isso te coloca

Com deduplicação, compressão, criptografia e verificação trabalhando juntos, o PBS entrega backup enxuto, seguro e testável — a base de qualquer estratégia séria de continuidade.

Mas configurar retenção, verificação, criptografia e a integração com o cluster de produção exige método. É o tipo de projeto em que um detalhe mal ajustado só aparece na hora da restauração — tarde demais.

Próximo passo

Na Solvefy/Cloud, desenhamos e sustentamos ambientes Proxmox VE + PBS de ponta a ponta, com política de backup pensada para o seu risco real de negócio — incluindo teste periódico de restauração, que é o que transforma "temos backup" em "sabemos que restaura".

Quer revisar como seus dados estão protegidos hoje? Fazemos um diagnóstico gratuito, sem compromisso. Fale com a gente em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.