VM destruída sem lixeira para recorrer, cluster sem quórum, pool ZFS degradado, volume LVM-thin cheio. Aqui está o caminho de volta em cada cenário — e como o SERVER BACKUP tira a cópia de dentro do seu ambiente e devolve a máquina em minutos.
Essa é a diferença que pega o técnico desprevenido. Ao remover uma máquina, o Proxmox apaga também o volume no storage — sem confirmação em duas etapas e sem lugar para recorrer depois. Se você é quem foi chamado para resolver, comece por aqui.
Destruir a VM remove o disco do LVM-thin, do ZFS ou do Ceph junto. E não reutilize o mesmo VMID para criar outra máquina: isso escreve por cima da área onde os dados ainda poderiam estar. Deixe o ID quieto.
Se o /etc/pve ficou somente-leitura e as VMs não iniciam, o problema costuma ser quórum do cluster, não os dados. A pior reação é reinstalar o nó. Restabeleça o quórum primeiro — as máquinas normalmente estão intactas.
Verifique se há arquivo de backup em /var/lib/vz/dump, no storage configurado ou no servidor de backup do ambiente. Restaurar de um dump íntegro é sempre mais rápido e mais seguro do que tentar recuperar volume corrompido.
Snapshot de ZFS ou de LVM-thin ajuda num rollback rápido, mas mora no mesmo pool: se o pool degradar ou o ransomware chegar, o snapshot vai junto. Snapshot é conveniência, backup é cópia isolada.
Com a máquina protegida pelo SERVER BACKUP, você escolhe o escopo conforme a urgência — e vale tanto para VM KVM quanto para container LXC.
Para quando a operação está parada e cada minuto custa. A VM sobe a partir da própria cópia e volta a atender em minutos, enquanto a restauração definitiva corre em segundo plano.
Devolve disco, configuração e estado para o nó original ou para outro nó do cluster. É o caminho quando o servidor foi perdido, quando o storage corrompeu ou quando a máquina precisa mudar de lugar.
Restauração granular: alguém apagou uma pasta, uma base foi sobrescrita. Você entra no conteúdo da cópia e tira só o que precisa, sem restaurar a máquina toda nem derrubar quem está trabalhando.
Antes de devolver para produção — ou para provar ao cliente que a cópia presta. É o nosso Restore Drill: sobe separado, valida a integridade e vira relatório.
Muita gente monta o backup do Proxmox no próprio ambiente — outro disco, outro nó, um servidor de backup na mesma sala. Isso resolve erro humano e falha de disco. Não resolve incêndio, furto, nem ransomware que chega pela rede interna.
A cópia precisa sair do prédio. É a diferença entre ter backup e ter backup que sobrevive ao pior dia.
No Proxmox, dois detalhes decidem a qualidade da restauração: o modo como a cópia é tirada e onde ela vai parar.
Máquinas virtuais e containers são protegidos pela mesma rotina, com a mesma política de retenção — sem precisar de dois processos e duas planilhas de controle.
A cópia é tirada de forma coordenada, para que o sistema dentro da máquina volte em estado íntegro. Quando há banco de dados envolvido, isso é a diferença entre restaurar e restaurar funcionando.
O destino não é outro disco do mesmo rack: é data center Tier-III no Brasil, replicado em dois estados. O que derruba o seu ambiente não alcança a cópia.
| Cenário no Proxmox VE | Caminho recomendado |
|---|---|
| VM destruída por engano | Restauração completa a partir da cópia. Não existe lixeira no Proxmox — sem backup, o volume já foi removido do storage. |
| Pool ZFS degradado ou LVM-thin cheio | Restaurar para outro storage ou outro nó. Volume thin que estoura costuma deixar a VM em estado inconsistente. |
| Cluster sem quórum, VMs não iniciam | Restabelecer o quórum antes de tudo. Se o nó for perdido, restaurar as máquinas em nó alternativo. |
| Ransomware no ambiente | Voltar a um ponto anterior à infecção, a partir da cópia externa. Com storage imutável contratado, a cópia não pode ser cifrada nem apagada. |
| Arquivo apagado dentro da VM ou do container | Restauração granular, sem parar a máquina nem os usuários. |
| Migrar máquina para outro nó ou outro hardware | Restauração em destino alternativo — o mesmo recurso do desastre, usado a favor. |
O mesmo padrão de proteção da bringback, aplicado ao ambiente Proxmox VE.
Dados cifrados em trânsito e em repouso. A chave é sua — só você acessa o conteúdo.
Com storage imutável (object lock / WORM) contratado, o dado não pode ser deletado, alterado ou criptografado.
Verificação periódica com correção: o dado é conferido para garantir que está 100% restaurável.
Elimina blocos repetidos e comprime — menos espaço, menos banda, mais retenção pelo mesmo custo.
Replicado em 2 data centers Tier-III em estados diferentes, de 3 que operamos no Brasil.
Políticas diária, semanal, mensal e anual, com versionamento — do jeito que a auditoria pede.
* A imutabilidade depende do tipo de storage contratado (armazenamento imutável / object lock / WORM). É uma característica da infraestrutura de armazenamento, definida na contratação.
Todo backup é monitorado 24/7 na Plataforma iCOM e passa por testes de recuperação (Restore Drill): periodicamente, os dados são restaurados em ambiente isolado, a integridade é validada e vira relatório. É esse relatório que você mostra quando o cliente — ou a auditoria — pergunta se o dado volta mesmo.
Sem backup, é muito difícil. O Proxmox remove o volume do storage junto com a máquina e não tem lixeira. Se acabou de acontecer, não crie nada novo no mesmo storage e principalmente não reutilize o VMID — cada gravação nova reduz a chance de qualquer perícia futura dar certo.
Não. O snapshot mora no mesmo pool da máquina. Se o pool degradar, se o hardware for perdido ou se o ransomware alcançar o host, o snapshot vai junto. Ele resolve rollback rápido de alteração recente — não perda real.
Está parcialmente. Isso cobre erro humano e falha de um disco. Não cobre incêndio, furto do equipamento, nem ransomware que se espalha pela rede interna e alcança o destino do backup. A cópia precisa sair do prédio.
Sim. VMs KVM e containers LXC entram na mesma rotina, com a mesma política de retenção e o mesmo processo de restauração.
Normalmente não. Sem quórum o /etc/pve fica somente-leitura e o Proxmox recusa iniciar máquinas, mas os discos continuam onde estavam. Restabeleça o quórum antes de qualquer medida drástica — reinstalar o nó nessa hora costuma transformar um susto em perda real.
Ligando direto do backup, ela pode voltar a operar em minutos, enquanto a restauração definitiva acontece. Uma restauração completa depende do tamanho do disco e do link disponível.
Sim. A restauração pode ir para o nó original ou para um destino alternativo — que é o caminho quando o servidor foi perdido ou quando você está renovando o parque.
Se você é o técnico que apaga o incêndio quando o cliente liga desesperado, existe um jeito de essa ligação não acontecer mais — e de virar receita recorrente sua. Manda o cenário no WhatsApp: quantos nós, quantas VMs e containers, o que precisa proteger. A resposta vem em linguagem de técnico, sem ligação e sem roteiro comercial.