"Tenho snapshot diário, estou protegido." Essa frase antecede uma parcela grande dos desastres de infraestrutura que ajudamos a investigar. Snapshot é um recurso excelente e você deve usar. Ele simplesmente não protege contra a maioria das coisas das quais você precisa ser protegido — e a confusão entre os dois conceitos só é descoberta no momento em que já não há o que fazer.

O que um snapshot é de fato

Um snapshot é uma referência a um instante no tempo, gravada no mesmo storage onde o dado vive. Ele não copia nada quando é criado: o sistema apenas passa a preservar os blocos antigos em vez de sobrescrevê-los. Por isso é instantâneo e por isso ocupa pouco espaço no início — ele cresce conforme o dado muda.

Essa característica é a origem tanto da utilidade quanto da limitação. É útil porque criar um snapshot custa quase nada e permite voltar atrás em segundos. É limitado porque o snapshot depende do storage original estar íntegro. Ele é um ponteiro para dentro do mesmo lugar, não uma cópia em outro lugar.

O que o snapshot protege bem

Existe um cenário em que o snapshot é a ferramenta perfeita, e é um cenário frequente: a mudança que você mesmo vai fazer agora.

• Atualizar o sistema operacional de uma VM. Deu problema, você volta em segundos.
• Aplicar uma migração de banco de dados. Falhou no meio, você reverte.
• Instalar uma versão nova da aplicação. Não funcionou, volta ao estado anterior.
• Testar uma alteração de configuração que é difícil de desfazer manualmente.

Nesses casos, o snapshot é melhor que backup: mais rápido para criar, mais rápido para restaurar e sem impacto na rede. A regra que funciona é tratá-lo como rede de proteção de curtíssimo prazo — cria antes da mudança, valida depois e apaga.

O que o snapshot não protege — e é aqui que dói

O snapshot mora no mesmo storage do dado. Então ele não sobrevive a nada que atinja o storage:

• Falha do storage. Pool corrompido, controladora com defeito, cluster Ceph perdido: o dado e todos os snapshots vão juntos.
• Perda do nó, em cenário de storage local sem replicação.
• Exclusão da VM. Apagar a VM apaga os snapshots dela. Não existe lixeira.
• Ransomware. Boa parte das famílias modernas procura e destrói snapshots antes de cifrar, justamente porque sabe que é o primeiro recurso de recuperação.
• Corrupção lógica descoberta tarde. Se o banco corrompeu há três semanas e você mantém snapshots de sete dias, todos os seus pontos de recuperação contêm a corrupção.
• Incidente no datacenter. Fogo, enchente, perda de acesso físico.

Esse último item é o que separa conceitualmente as duas coisas. Backup é cópia em outro lugar, com retenção própria, independente do original. Snapshot é estado anterior no mesmo lugar. São categorias diferentes, não graus de proteção.

O comparativo direto

Onde o Proxmox suporta snapshot, e onde não

Um detalhe operacional que pega gente de surpresa: não é todo storage do Proxmox que suporta snapshot. Depende da tecnologia por baixo.

ZFS, Ceph RBD, LVM-thin e discos em formato qcow2 suportam. Já disco em formato raw sobre LVM tradicional não suporta snapshot de VM — e a descoberta costuma acontecer no pior momento, quando alguém vai criar o snapshot antes de uma atualização crítica e o botão não está disponível.

Vale saber também que VM e container se comportam de forma diferente: em VM é possível incluir o estado da memória no snapshot, o que permite voltar com a máquina ligada exatamente como estava. É poderoso para depurar um problema difícil de reproduzir, e caro em espaço.

O custo escondido do snapshot esquecido

Snapshot antigo não é neutro. Ele tem dois custos que crescem em silêncio.

O primeiro é espaço. O snapshot preserva os blocos antigos; quanto mais o dado muda, mais ele cresce. Um snapshot de três meses numa VM de banco de dados ativo pode ocupar mais que o disco original. Storage cheio por snapshot esquecido é um dos incidentes mais comuns e mais evitáveis em Proxmox.

O segundo é performance. Cadeias longas de snapshot degradam leitura e escrita, porque o sistema precisa resolver onde está a versão atual de cada bloco.

A prática que evita os dois: snapshot tem dono e prazo. Criou antes de uma mudança, validou a mudança, apagou. E vale uma verificação periódica em busca de snapshots que ninguém reclamou — quase sempre há algum.

O papel do Proxmox Backup Server

O PBS é a peça que cobre o que o snapshot não cobre, e faz isso com características que importam:

1. Backup incremental de verdade, enviando apenas os blocos alterados. A primeira cópia é integral; as seguintes são rápidas.
2. Deduplicação global no datastore. Vinte VMs derivadas do mesmo template não guardam vinte cópias do sistema operacional.
3. Criptografia do lado do cliente, com AES-256. O dado sai cifrado do host, o que torna viável guardar cópia em local que você não controla inteiramente.
4. Verificação de integridade agendada, que confere se o que está guardado ainda é restaurável. É a diferença entre ter backup e saber que o backup presta.
5. Restauração granular, permitindo recuperar arquivos individuais de dentro de um backup de VM sem restaurar a VM inteira.
6. Retenção por política, mantendo diários, semanais e mensais conforme a regra definida — o que resolve a corrupção descoberta tarde.

A combinação que funciona

Snapshot e backup não competem. O desenho completo usa os dois, com papéis claros:

• Snapshot para reversão imediata de mudança planejada. Vida curta, medida em horas.
• Backup diário no PBS com retenção escalonada, para recuperar de perda, exclusão e corrupção antiga.
• Cópia externa do datastore do PBS, em outro local ou provedor, para o cenário de perda do site. É o "1" fora do local da regra 3-2-1.
• Verificação automática dos backups e teste de restauração periódico — restaurar de verdade uma VM em ambiente isolado, não só olhar o relatório verde.

Esse último ponto é o que mais separa quem tem proteção de quem tem a impressão de ter. Backup nunca testado é uma hipótese, não uma garantia.

Consistência: o detalhe que decide a restauração

Backup de VM captura o disco como está naquele instante. Se a aplicação tem dado em memória ainda não gravado, a cópia pode ficar em estado que exige recuperação — para um banco de dados, isso significa restaurar e depender do mecanismo de recuperação dele.

Duas medidas resolvem. Instale o agente de convidado nas VMs, para o Proxmox coordenar o congelamento dos arquivos no momento do backup. E, para bancos de dados, mantenha também um dump lógico do banco além do backup da VM. São coisas complementares: o backup da VM devolve a máquina inteira rapidamente; o dump devolve o banco em estado consistente conhecido.

Erros comuns

• Chamar snapshot de backup e dimensionar a proteção por ele.
• Snapshot antigo esquecido enchendo o pool de storage.
• Cadeia longa de snapshots degradando a performance da VM.
• Descobrir na hora da mudança que o storage não suporta snapshot.
• Backup apenas no mesmo storage ou no mesmo datacenter.
• Nenhuma verificação de integridade, com relatório verde e backup ilegível.
• Nunca ter testado uma restauração completa.
• Banco de dados sem dump lógico, contando só com o backup da VM.
• Retenção curta demais para alcançar corrupção descoberta semanas depois.

Onde a Solvefy/Cloud entra

Desenhar essa camada é parte do que fazemos como parceiros oficiais Proxmox: definimos a política de snapshot, configuramos o Proxmox Backup Server com deduplicação, criptografia e verificação, estabelecemos a retenção que cobre o seu risco real e implantamos a cópia externa. E, principalmente, executamos o teste de restauração com você — porque a única forma de saber que um backup funciona é restaurá-lo antes de precisar.

Quer saber se a sua proteção resiste a um incidente de verdade? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.