Proxmox VE: automatize backup de VMs com vzdump e retenção

Backup manual falha por um motivo banal: alguém esquece de rodar. O Proxmox VE já traz tudo para eliminar essa dependência — o utilitário vzdump, um agendador nativo (pvescheduler) e um sistema de retenção que decide sozinho quais pontos de restauração manter, sem exigir o Proxmox Backup Server. Neste guia você configura o storage de destino, testa o backup manualmente, define a política de retenção e agenda tudo por linha de comando — sem depender da interface gráfica.

Por que automatizar (e não só agendar)

Agendar um vzdump sem configurar retenção resolve metade do problema: o backup roda, mas os arquivos se acumulam até o storage de destino encher e o job começar a falhar silenciosamente — normalmente descoberto só na hora de restaurar, quando já é tarde. A automação completa cobre três frentes: geração do backup, poda dos backups antigos (prune-backups) e verificação de que a restauração realmente funciona.

Pré-requisitos

• Proxmox VE 8.x com acesso root via SSH ou console do node
• Um storage de destino para os backups: diretório local, NFS/CIFS ou Proxmox Backup Server
• Espaço livre suficiente para pelo menos duas gerações completas de backup

Passo a passo

1. Defina o storage de destino

Backup em disco local só protege contra falha de VM, não de hardware. Sempre que possível, aponte para um storage fora do node — um servidor NFS já resolve a maior parte dos casos sem custo extra.

pvesm add dir backup-local --path /mnt/backup --content backup

Ou, para um destino em rede:

pvesm add nfs backup-nfs --server 192.168.1.10 \
  --export /export/backup --path /mnt/pve/backup-nfs --content backup

2. Teste um backup manual antes de automatizar

Nunca agende algo que você não validou rodando na mão. O modo snapshot é o recomendado para VMs: usa o backup ao vivo do Proxmox, com o menor downtime possível, e aciona o guest agent para congelar o sistema de arquivos se ele estiver ativo.

vzdump 100 --storage backup-local --mode snapshot --compress zstd

zstd é o algoritmo de compressão mais rápido dos três suportados (junto com gzip e lzo) e o único com suporte real a multi-thread — use-o como padrão, a menos que precise de compatibilidade com ferramentas antigas.

3. Configure a retenção com prune-backups

A opção prune-backups aceita uma lista separada por vírgula, processada nesta ordem: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. Cada regra cobre um período; a próxima só considera backups mais antigos que o período já coberto.

pvesm set backup-local --prune-backups keep-last=3,keep-daily=7,keep-weekly=4,keep-monthly=6

Essa configuração mantém pelo menos 3 backups recentes (mesmo que rodados fora do horário agendado), 7 dias de backups diários, 4 semanas de semanais e 6 meses de mensais — sem isso, um node que gera um backup por dia acumula um ano de arquivos em 12 meses, e ninguém percebe até o disco travar a próxima gravação.

4. Agende o job de backup

O agendamento do Proxmox VE usa o formato de eventos de calendário do systemd, não a sintaxe de cron — 0 2 * * * não funciona aqui. Para rodar todo dia às 2h da manhã, o valor é simplesmente 02:00.

pvesh create /cluster/backup --storage backup-local --schedule "02:00" \
  --all 1 --mode snapshot --compress zstd \
  --prune-backups keep-last=3,keep-daily=7,keep-weekly=4,keep-monthly=6 \
  --mailto seu-email@dominio.com --enabled 1 --repeat-missed 1

--all 1 inclui todos os convidados do node no job; para restringir, troque por --vmid 100,101,105. O flag --repeat-missed garante que, se o node estiver desligado no horário agendado, o job roda assim que ele voltar — evita janelas de backup perdidas em servidores que não ficam ligados 24/7.

O job vai para /etc/pve/jobs.cfg e é executado pelo daemon pvescheduler, que já roda por padrão — não é preciso configurar cron separadamente.

5. Valide a sintaxe e confirme o job criado

Antes de confiar no agendamento, teste a expressão isoladamente:

systemd-analyze calendar "02:00" --iterations=3

E confirme que o job existe:

pvesh get /cluster/backup

6. Configure notificação de falha

Um backup que falha sem avisar ninguém é pior do que não ter backup — dá falsa sensação de segurança. O parâmetro --mailto usado no passo 4 já envia e-mail via sendmail a cada execução. Para ambientes com Slack, Telegram ou webhook, configure um alvo de notificação em Datacenter → Notifications e associe um matcher ao evento de backup — assim a falha chega no canal certo, não só numa caixa de e-mail que ninguém lê.

7. Teste a restauração — não pule esta etapa

Backup não testado é uma suposição, não uma garantia. Restaure em uma VM de teste com ID diferente do original para validar o arquivo sem risco:

qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2026_08_23-02_00_00.vma.zst 999 \
  --storage local-lvm

Para containers, o comando equivalente é pct restore. Faça esse teste pelo menos uma vez por trimestre — políticas de retenção e storages mudam, e é melhor descobrir um backup corrompido num teste do que numa recuperação real.

Erros comuns

Confundir sintaxe systemd com cron. Colar uma expressão cron como 0 2 * * * no campo de agendamento não produz o resultado esperado — valide sempre com systemd-analyze calendar.

Backup local sem cópia externa. Um storage de backup no mesmo node protege contra erro humano e corrupção de VM, mas não contra falha de disco ou do servidor inteiro.

Nunca testar a restauração. É o erro mais caro: só aparece no pior momento possível.

Perguntas frequentes

Preciso do Proxmox Backup Server (PBS) para automatizar backup?
Não. vzdump com um storage de diretório ou NFS já cobre backup completo agendado com retenção. O PBS adiciona deduplicação, backups incrementais e restauração de arquivo único — vale a pena em volumes maiores, mas não é pré-requisito.

Qual modo de backup usar: snapshot, suspend ou stop?
snapshot é o padrão recomendado para VMs, com o menor downtime. suspend existe por compatibilidade e tende a gerar mais tempo de indisponibilidade sem ganho real de consistência. stop garante a maior consistência possível, mas desliga o convidado durante o backup — reserve para casos em que a integridade importa mais que a disponibilidade.

O que acontece se o node estiver desligado no horário do backup?
Sem --repeat-missed, o job simplesmente é pulado. Com a opção ativa, o pvescheduler roda o job assim que o node volta a ficar online.

zstd, gzip ou lzo: qual compressão escolher?
zstd na prática — é o mais rápido dos três e o único com paralelismo real entre múltiplos núcleos. Use gzip apenas se precisar de compatibilidade com ferramentas que não leem .zst.

Backup incremental é possível sem o PBS?
Não. Com storages de arquivo (dir/NFS), o vzdump sempre gera backups completos. Incremental de verdade — com deduplicação por chunk — exige o Proxmox Backup Server como destino.

Conclusão

Com o storage configurado, a retenção definida via prune-backups, o job agendado em formato de calendário do systemd e a restauração validada pelo menos uma vez, o backup do cluster para de depender de alguém lembrar de rodar um comando. O próximo passo natural, se o volume de dados crescer, é migrar o destino para um Proxmox Backup Server dedicado — a rotina de agendamento e retenção que você acabou de montar continua valendo, só troca o tipo de storage.