Como fazer backup das máquinas virtuais do Proxmox VE

O que você vai configurar

O BackupZit faz backup das máquinas virtuais (QEMU) e contêineres (LXC) do Proxmox VE sem instalar nada dentro dos convidados. Um pequeno agente roda em cada nó Proxmox, cria um snapshot temporário de cada convidado, lê seus discos e os grava no armazenamento escolhido. Um console web agenda as tarefas, guarda o histórico e executa as restaurações.

• O que é preciso
• 1. Console
• 2. Armazenamento
• 3. Agente no nó
• 4. Tarefa de backup
• 5. Backups consistentes
• 6. Cópia externa
• 7. Testes de restauração
• Restauração
• Configuração do host
• Limites

O que é preciso

• Um ou mais nós com Proxmox VE 7, 8 ou 9 (são baseados em Debian, então o pacote Debian do agente serve).
• Um lugar para o console do BackupZit: uma pequena VM Linux com 2 vCPU, 2–4 GB de RAM e disco de 16–20 GB. O console não guarda dados de backup, então pode rodar como VM no mesmo cluster.
• Armazenamento de backup fora do nó Proxmox — por exemplo um servidor Linux ou NAS via SFTP, um compartilhamento SMB, um bucket compatível com S3 ou um repositório reforçado do BackupZit (hardened repository). Os agentes gravam diretamente nele.
• Rede: os agentes acessam o console pela porta TCP 8443.

Passo 1 — Instalar o console

O jeito mais rápido no Proxmox é a imagem de appliance pronta backupzit-appliance.qcow2 da página de download (Debian, PostgreSQL e o console, já configurados):

1. Crie uma VM sem disco: 2 vCPU, 2–4 GB de RAM, rede VirtIO.
2. Copie backupzit-appliance.qcow2 para o nó e importe-o como disco da VM (substitua <vmid>):

   qm importdisk <vmid> backupzit-appliance.qcow2 local-lvm

3. Anexe o disco importado como SCSI, torne-o o disco de inicialização e ative o QEMU guest agent nas opções da VM.
4. Inicie a VM. A tela dela mostra o endereço do console web e a senha inicial do usuário admin. Abra https://<endereço>:8443, entre e altere a senha.

Na tela da VM você pode entrar como bzadmin para definir um endereço estático, o nome do servidor e o fuso horário (o appliance inicia em UTC e os agendamentos seguem o fuso horário do console). Prefere um servidor Debian, Ubuntu, AlmaLinux ou Rocky Linux existente? O script de instalação de uma linha da página de download faz o mesmo lá.

Passo 2 — Adicionar um destino de armazenamento

No console, abra Armazenamento e adicione um destino. Escolhas típicas para backups do Proxmox:

Deixe Criptografar backups (AES-256) ativado (padrão): tudo é criptografado com AES-256-GCM no nó antes de sair dele. O console então mostra uma chave de recuperação — imprima a folha de recuperação ou guarde a chave num gerenciador de senhas, longe dos backups. Com a chave, o local do armazenamento e suas credenciais você restaura mesmo sem o console; sem a chave ninguém consegue ler os backups.

Passo 3 — Instalar o agente em cada nó

1. No console, abra Agentes e clique em Criar token de registro. Você recebe um código de registro (BZ1-…) válido por 7 dias e para qualquer número de máquinas.
2. Baixe o pacote Agente Linux — Debian / Ubuntu da página Agentes para o nó e execute:

   apt install ./backupzit-agent_*.deb
   backupzit-agent enroll --code "BZ1-..."
   systemctl enable --now backupzit-agent

3. Em até um minuto o nó aparece na página Agentes com o selo Proxmox VE · N guests.

O agente usa as ferramentas do próprio nó (qm, pct, pvesm, LVM, ZFS, Ceph). Nenhum token de API do Proxmox nem senha de root fica guardado no console. Em um cluster, instale o agente em cada nó.

Passo 4 — Criar a tarefa de backup

1. Abra Tarefas de backup, crie uma tarefa e selecione o agente do nó.
2. Escolha Máquinas virtuais (Proxmox VE, Hyper-V, VMware) e depois Todas as VMs (e contêineres) do host — convidados criados depois entram automaticamente — ou marque convidados específicos.
3. Escolha o destino de armazenamento do passo 2.
4. Defina um agendamento, por exemplo todo dia útil às 22:00. Tarefas também podem se repetir a cada 15 minutos até 12 horas, rodar uma vez por mês ou começar depois de outra tarefa.
5. Defina a retenção. Exemplo: 3 mais recentes, 7 diários, 4 semanais, 6 mensais mantêm cerca de meio ano de histórico com uns 20 pontos de restauração.

O que acontece em cada execução:

1. Um snapshot temporário do Proxmox (backupzit_…) é criado; o convidado continua rodando.
2. Cada disco é lido do snapshot em blocos de 1 MiB. Blocos vazios não são gravados e blocos que já estão no repositório não são enviados de novo — após o primeiro backup só os dados alterados passam pela rede. Ainda assim, cada backup é um ponto de restauração completo.
3. O snapshot é removido. A configuração do convidado (CPU, memória, rede, discos) é gravada com o backup.

Como dados inalterados são gravados uma única vez, uma retenção longa custa pouco espaço extra.

Quais discos podem ser copiados com o convidado ligado

Convidados parados podem ser copiados em todos eles. Discos marcados Backup: no (backup=0), discos físicos em passthrough e bind mounts são ignorados e aparecem como aviso.

Passo 5 — Backups consistentes no nível da aplicação

Se o QEMU guest agent roda dentro da VM e está ativado nas opções dela, o Proxmox congela os sistemas de arquivos da VM para o snapshot, e bancos de dados e aplicações ficam num estado limpo. Sem ele o backup é consistente contra falhas — como depois de uma queda de energia.

Numa VM Debian ou Ubuntu:

apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Em VMs Windows instale as VirtIO guest tools. Depois ative o agente para a VM no nó (vale após o próximo desligamento e inicialização completos da VM):

qm set <vmid> --agent enabled=1

A página de cada execução mostra, por convidado, quais discos foram lidos e como o convidado foi capturado.

Passo 6 — Manter uma cópia externa (3-2-1)

A regra 3-2-1: três cópias dos seus dados, em duas mídias diferentes, uma delas fora do local. Adicione uma segunda tarefa do tipo Cópia de backup, com a tarefa do Proxmox como origem e um destino externo, como um bucket S3 com Object Lock ou um repositório reforçado em outro prédio.

• O agente copia os backups existentes; as VMs não são lidas de novo.
• Só os dados que ainda não estão no destino são enviados, criptografados com a chave do destino.
• Por padrão a cópia roda depois de cada backup da tarefa de origem; qualquer agendamento serve, por exemplo uma vez por noite numa linha lenta.
• A cópia tem sua própria retenção, por exemplo 7 diários no NAS e 12 mensais na nuvem.

As VMs são restauradas da cópia como do original — VMs inteiras, arquivos avulsos e recuperação instantânea. Mais sobre cópias imutáveis na proteção contra ransomware.

Passo 7 — Provar que os backups inicializam

Blocos legíveis não provam que uma VM ainda inicializa. Em Configurações → Testes de restauração ative o Teste de inicialização para backups de VMs do Proxmox. O teste de restauração então inicia cada VM do backup mais recente, uma após a outra, no nó da tarefa, direto do backup, com um novo ID e as placas de rede desconectadas para não conflitar com o original — e depois a apaga.

• Uma VM passa quando seu QEMU guest agent responde a tempo, ou seja, o sistema operacional iniciou. VMs sem guest agent passam se continuarem rodando por um minuto e aparecem como em execução em vez de inicializadas.
• O nó precisa de memória livre para mais uma VM durante o teste.
• Além disso, uma verificação de dados (mensal por padrão) lê todos os dados armazenados e os confere com o checksum, para encontrar danos no próprio armazenamento antes de você precisar do backup.

Restauração

Abra uma execução de backup (na página da tarefa ou em Atividade) e escolha Restaurar uma VM ou contêiner.

VM ou contêiner inteiro

• Restaure em qualquer nó com o agente — também num nó de outro cluster.
• Como novo convidado com o próximo ID livre (padrão) enquanto o original continua rodando; a cópia recebe novos endereços MAC. Ou com o ID original depois que o convidado foi apagado, substituindo opcionalmente um existente.
• Escolha o nome e o armazenamento dos discos e se o convidado deve iniciar após a restauração.
• Toda restauração dá às VMs um novo generation ID (vmgenid), para que controladores de domínio Windows detectem a volta no tempo com segurança.

Recuperação instantânea: a VM roda em segundos

Uma restauração normal leva o tempo de copiar os discos. Com Instantaneamente, rodando a partir do backup o agente serve os discos somente leitura a partir do backup e inicia uma nova VM cujas gravações vão para overlays locais. Quando estiver satisfeito, Concluir move os discos para o armazenamento escolhido enquanto a VM continua rodando (qm disk move); Descartar VM apaga a VM e suas alterações. A VM é tão rápida quanto o armazenamento de backup, por isso um repositório em disco local ou compartilhamento de rede rápido é o ideal. A recuperação instantânea é para VMs, não para contêineres.

Arquivos avulsos

Clique em Navegar pelos arquivos na tabela de convidados de uma execução. O console lê o disco direto do backup — nada é restaurado antes — e permite navegar por NTFS, ext2/3/4 e XFS, também dentro de LVM. Baixe arquivos (vários como ZIP) ou restaure-os numa pasta em qualquer agente. Navegar no console exige um backup em armazenamento de rede (SFTP, S3, SMB, Azure ou repositório reforçado).

Réplicas para os convidados mais importantes

Em Avançado na tarefa, Manter réplicas das VMs mantém atualizada após cada backup uma cópia desligada de cada convidado em outro nó ou cluster. Só blocos alterados são gravados — normalmente alguns segundos por backup. Se um convidado se perde, Iniciar réplica o inicia com os dados do último backup, sem restauração.

Pela linha de comando

Tudo funciona também sem o console, por exemplo para reconstruir um nó após um desastre:

backupzit-agent pve list
backupzit-agent pve show    --repo ... latest
backupzit-agent pve restore --repo ... --vmid 100 --new-vmid -1 --storage local-lvm --start latest

Backup do próprio host Proxmox

Os convidados são só metade de um nó: definições de armazenamento, rede, usuários, firewall, certificados e as configurações de cada VM e contêiner ficam na configuração dele. Faça o backup com uma tarefa comum de Arquivos e pastas no agente do nó, por exemplo diária, com os caminhos /etc (inclui /etc/pve, a rede e /etc/hosts) e /var/lib/pve-cluster (o banco de configuração config.db). Para uma cópia totalmente consistente do banco com o nó em uso, adicione isto como Comando antes do backup e inclua também /root/pve-config.db:

# one-time: apt install sqlite3
sqlite3 /var/lib/pve-cluster/config.db ".backup /root/pve-config.db"

Para reconstruir um nó com falha: instale a mesma versão do Proxmox VE com o mesmo nome de host e endereço, instale o agente, restaure /etc/network/interfaces e /etc/hosts, pare o serviço do cluster (systemctl stop pve-cluster), restaure config.db em /var/lib/pve-cluster, inicie o serviço de novo e depois restaure os convidados. Num cluster, junte o nó reinstalado ao cluster de novo em vez de restaurar config.db.

Limites a conhecer

• São suportados o Proxmox VE 7, 8 e 9. O XCP-ng não é suportado.
• Discos de contêineres em subvolumes ZFS ainda não são suportados.
• Discos raw em armazenamento de diretório, NFS ou CIFS e discos em LVM espesso só podem ser copiados com o convidado parado.
• Num cluster, uma tarefa faz backup dos convidados do próprio nó. Um convidado migrado para outro nó gera um aviso — use Todas as VMs (e contêineres) do host em cada nó para que os convidados migrados continuem cobertos.
• Unidades cloud-init não são gravadas; são recriadas a partir da configuração na restauração.

Próximos passos

O BackupZit é gratuito e de código aberto (AGPLv3), sem limite de VMs ou nós. Baixe-o, veja todos os recursos para Proxmox ou leia o capítulo completo sobre Proxmox VE no guia integrado ao console. Perguntas são bem-vindas nas GitHub Discussions. Empresas podem contratar suporte comercial da MaxZit (somente em inglês).