Backup no Proxmox depois de perder tudo: vzdump simples

Eu já usei o Proxmox Backup Server no meu homelab. Até o dia em que perdi o SSD do servidor e o HD de backup juntos. Não consegui recuperar nada, nem os backups. Tive que reconstruir tudo do zero (contei como a IA me ajudou nisso neste post).

Depois disso, troquei a solução sofisticada por uma simples e funcional: vzdump, a ferramenta de backup que já vem no Proxmox, rodando todo dia às 21h e gravando num HD externo ligado por USB, com histórico de até 12 meses. Neste post conto por que fiz essa troca, como o vzdump funciona e como passei a cumprir a regra 3-2-1, com uma cópia fora de casa.

O erro não foi a ferramenta #

Vale dizer logo: o Proxmox Backup Server é uma boa ferramenta. O meu problema foi de desenho. O servidor e a cópia de segurança estavam vulneráveis ao mesmo evento. Quando ele aconteceu, perdi os dois de uma vez, e não sobrou de onde restaurar.

Backup que pode morrer junto com o original não é backup, é uma cópia no mesmo lugar. Essa é a lição que eu levaria para qualquer ferramenta.

Por que voltei para o vzdump #

Depois do desastre, eu quis o caminho com menos peças possíveis. O vzdump:

• já vem instalado em todo Proxmox, sem servidor extra para manter;
• gera um arquivo por backup, que dá para copiar para qualquer lugar;
• restaura com um comando ou pela interface, sem depender de nada além do próprio Proxmox.

Para um homelab de um nó só, simplicidade vale muito. E eu já testei o que mais importa: já restaurei a partir desses backups sem nenhum problema.

Como o vzdump faz o backup #

Segundo a documentação do Proxmox, existem três modos:

Para containers, o modo snapshot exige um storage que suporte snapshots. Para compressão, o zstd é o mais rápido, segundo a documentação.

Os backups são agendados pela interface, em Datacenter > Backup, escolhendo os guests, o horário, o storage de destino, o modo e a compressão.

A minha rotina de backup #

Hoje tudo roda sozinho, toda noite, em três etapas:

O segundo passo existe porque o vzdump cuida das VMs e dos containers, não do host. Sem ele, se o SSD do servidor morrer, a configuração do próprio Proxmox não está em nenhum backup.

A auditoria resolve o pior tipo de falha. Backup que falha em silêncio é o pior tipo de backup: você só descobre no dia em que precisa dele.

Quando a auditoria termina, um script me manda um e-mail. Se está tudo certo, o assunto já chega com “Proxmox Backup OK”; se alguma verificação falhou, o e-mail avisa o que deu errado. Assim eu sei toda manhã se a noite foi boa, sem abrir nada.

Dentro do e-mail vem o relatório completo. A auditoria confere se o HD USB está montado, se o storage backup-usb está ativo no Proxmox, quanto espaço ainda sobra no disco e se o job do vzdump existe, está habilitado e inclui todos os guests:

Para acompanhar tudo isso sem abrir o Proxmox, criei um painel próprio que mostra cada etapa, quando rodou pela última vez e quando roda de novo:

Ele é uma das aplicações que desenvolvi para o meu dia a dia e merece um post só dele.

Retenção: 14 dias, 8 semanas e 12 meses #

Guardar todo backup para sempre lota qualquer disco. O Proxmox resolve isso com as opções de retenção (prune-backups), que dizem quantos backups manter em cada faixa de tempo:

• keep-last: os N mais recentes;
• keep-daily, keep-weekly, keep-monthly, keep-yearly: um por dia, semana, mês ou ano, nos N períodos mais recentes.

Elas se combinam. A minha política tem histórico de um ano sem guardar um backup por dia durante o ano todo. Em linha de comando, para um container, ficaria assim:

vzdump 101 --storage backup-usb --mode snapshot --compress zstd \
  --prune-backups keep-daily=14,keep-weekly=8,keep-monthly=12

Isso mantém os últimos 14 dias, as últimas 8 semanas e um backup por mês nos últimos 12 meses. Na prática, para voltar a ontem eu tenho um backup de cada dia; para voltar ao mês passado, um por semana; para voltar seis meses, um por mês. No meu caso, essa retenção está configurada no próprio job de backup, pela interface.

Restaurar é a parte que importa #

Um backup só vale se restaura. Pela documentação, os comandos são:

# container LXC: restaura o backup num novo ID (600)
pct restore 600 /caminho/vzdump-lxc-101-AAAA_MM_DD-HH_MM_SS.tar.zst

# máquina virtual: restaura o backup num novo ID (601)
qmrestore /caminho/vzdump-qemu-102-AAAA_MM_DD-HH_MM_SS.vma.zst 601

Restaurar num ID novo é o jeito seguro de testar: o original continua rodando e você confere se a cópia sobe direito antes de apagar qualquer coisa.

A regra 3-2-1: a cópia fora de casa #

A regra clássica de backup é 3-2-1:

• 3 cópias dos dados;
• em 2 mídias diferentes;
• 1 delas fora de casa.

Durante um tempo eu não cumpria a última parte: os backups ficavam só no HD externo aqui em casa. Isso protege de erro humano, de um container quebrado e de um SSD que morre, mas não de um problema que atinja a casa toda, como um raio, um roubo ou um incêndio.

Agora cumpro. Além do HD USB, uma cópia dos backups dos meus containers LXC (o vzdump do container inteiro) vai para o OneDrive com o rclone. A conta fica assim:

Como montei o envio com o rclone é assunto para um post só dele. O NAS continua nos planos, para concentrar os backups em casa.

Resumindo #

• O problema raramente é a ferramenta, é o backup morrer junto com o original.
• vzdump é suficiente para um homelab pequeno: já vem no Proxmox e restaura sem dependências.
• Automatize e audite: backup diário, a configuração do host salva à parte e um e-mail que avisa se deu tudo certo ou se algo falhou.
• Use a retenção para ter histórico longo sem lotar o disco.
• Teste a restauração num ID novo, de tempos em tempos.
• Leve uma cópia para fora de casa. A minha vai para o OneDrive com o rclone.

Perder tudo uma vez me ensinou que o melhor backup é o que você entende, consegue restaurar e não está no mesmo lugar do original.

Tags: backup, proxmox, vzdump, 3-2-1