Snapshot não é backup: entenda a diferença

O que é um snapshot e o que ele realmente faz

Um snapshot é uma fotografia do estado de uma máquina virtual em um momento específico. No VMware vSphere, por exemplo, quando você cria um snapshot, o hypervisor congela o disco virtual original (o arquivo VMDK base) e passa a gravar todas as alterações subsequentes em um arquivo delta separado. O estado da memória e das configurações da VM também pode ser capturado. A partir daí, é possível "voltar no tempo" para aquele ponto, descartando tudo o que aconteceu depois.

Essa mecânica é extremamente útil em cenários controlados: antes de aplicar um patch no sistema operacional, antes de atualizar uma aplicação crítica ou antes de uma mudança de configuração arriscada. Se algo der errado, a reversão leva minutos. É justamente essa conveniência que cria a falsa sensação de segurança: se eu posso voltar ao estado anterior, isso não é um backup?

Não é. O detalhe técnico que muda tudo está na dependência: o snapshot não é uma cópia independente dos dados. O arquivo delta só faz sentido em conjunto com o disco base original. Se o disco base for corrompido, apagado ou o storage onde ambos residem falhar, o snapshot morre junto. Ele nunca sai do mesmo lugar onde está o dado que deveria proteger.

O que caracteriza um backup de verdade

Backup, por definição, é uma cópia completa e independente dos dados, armazenada em local separado da origem, com capacidade de restauração mesmo que o ambiente original deixe de existir por completo. Essa independência é o critério central: um backup legítimo sobrevive à destruição total do servidor, do storage e até do datacenter de origem.

Um backup profissional carrega ainda outros atributos que o snapshot não possui:

• Retenção de longo prazo: políticas de dias, semanas, meses ou anos, atendendo requisitos de compliance e auditoria — enquanto snapshots são projetados para viver horas ou poucos dias;
• Versionamento: múltiplos pontos de restauração ao longo do tempo, permitindo recuperar um arquivo como ele estava há três semanas, não apenas no último ponto criado;
• Restauração granular: recuperar um único arquivo, uma caixa de e-mail ou um registro de banco de dados, sem precisar reverter a máquina inteira;
• Verificação de integridade: ferramentas como Veeam SureBackup testam automaticamente se o backup é de fato restaurável, iniciando a VM em ambiente isolado;
• Isolamento contra ransomware: cópias imutáveis ou air-gapped, fora do alcance de um atacante que comprometa o ambiente de produção.

Nenhum desses atributos existe em um snapshot. Ele é um mecanismo de conveniência operacional do hypervisor, não uma estratégia de proteção de dados. Confundir os dois é como achar que o Ctrl+Z do editor de texto substitui salvar o documento em outro lugar.

Os riscos reais de tratar snapshot como backup

O primeiro risco é o mais óbvio e o mais fatal: ponto único de falha. Snapshot e disco original vivem no mesmo datastore, no mesmo storage físico. Uma falha de controladora, um RAID degradado que colapsa, um LUN corrompido ou um ransomware que criptografa o datastore levam embora produção e "backup" no mesmo instante. Empresas já perderam anos de dados exatamente assim — acreditando que os snapshots diários eram sua rede de proteção.

O segundo risco é de performance e estabilidade. Snapshots antigos crescem sem parar: cada bloco alterado na VM é gravado no arquivo delta, que pode ultrapassar o tamanho do disco original. O resultado é degradação severa de I/O (a VM precisa consultar a cadeia de deltas a cada leitura), datastores que enchem até travar todas as VMs do cluster, e consolidações de snapshot que podem levar horas com a aplicação sofrendo. A própria VMware recomenda oficialmente não manter um snapshot por mais de 72 horas e nunca acumular mais de 2 ou 3 na cadeia.

A recomendação da VMware é explícita na documentação oficial: "snapshots não são backups". Um snapshot mantido por semanas em ambiente de produção não é uma política de proteção — é um incidente esperando data para acontecer.

O terceiro risco é o ransomware moderno. Ataques atuais são operados por humanos que estudam o ambiente antes de agir. Ao obter acesso ao vCenter ou ao host ESXi — cenário cada vez mais comum, com famílias de ransomware feitas sob medida para ESXi — o atacante deleta os snapshots antes de criptografar os discos. Se sua única linha de defesa mora dentro do próprio ambiente virtualizado, ela será a primeira coisa eliminada.

Onde o snapshot brilha: os casos de uso corretos

Nada disso significa que snapshots são ruins. Significa que têm um papel específico, e dentro dele são excelentes. O uso correto do snapshot é sempre de curtíssima duração e escopo controlado:

1. Janelas de mudança: criar o snapshot imediatamente antes de aplicar patch, upgrade de aplicação ou mudança de configuração; validar o resultado; remover o snapshot em seguida — idealmente no mesmo dia;
2. Testes rápidos: experimentar uma alteração em ambiente de homologação com reversão instantânea;
3. Suporte ao próprio backup: ferramentas como Veeam Backup & Replication usam snapshots temporários como mecanismo interno para capturar a VM em estado consistente durante o job — o snapshot é criado, os dados são copiados para o repositório externo e o snapshot é removido automaticamente.

Esse último ponto merece destaque porque explica a relação correta entre as duas tecnologias: o snapshot é uma etapa transitória do processo de backup, nunca o destino final. O dado protegido de verdade é o que saiu do ambiente de origem e chegou a um repositório independente.

Uma disciplina operacional simples evita a maioria dos problemas: monitorar snapshots órfãos com alertas automáticos, definir política formal de tempo máximo de vida (24 a 72 horas), e auditar regularmente o ambiente em busca de cadeias esquecidas. Snapshots esquecidos por meses são um dos achados mais comuns em diagnósticos de infraestrutura — e um dos mais perigosos.

A regra 3-2-1: como estruturar proteção de verdade

A referência de mercado para proteção de dados continua sendo a regra 3-2-1: manter 3 cópias dos dados (a produção e dois backups), em 2 mídias ou sistemas diferentes, com 1 cópia fora do site principal. Versões modernas acrescentam o "1-0": uma cópia imutável ou offline, e zero erros de verificação — ou seja, backups testados, não apenas existentes.

Na prática, para um ambiente virtualizado típico de médio porte, isso se traduz em: backup diário das VMs com ferramenta dedicada (Veeam é o padrão de mercado para VMware), repositório primário em storage separado do ambiente de produção, cópia secundária replicada para nuvem ou site remoto, e retenção configurada conforme a criticidade de cada workload. Snapshots seguem existindo no dia a dia — mas apenas nas janelas de mudança, com remoção disciplinada.

Tão importante quanto fazer o backup é testar a restauração. Backup que nunca foi restaurado é uma hipótese, não uma garantia. Testes periódicos de restore — de arquivos individuais e de VMs completas — validam o RTO real da operação e evitam a pior descoberta possível: perceber que o backup estava corrompido justamente no dia do desastre.

Como a Duk estrutura backup e snapshots nos clientes

Na Duk Informática & Cloud, esse cenário é rotina: em diagnósticos de novos clientes, encontrar ambientes VMware "protegidos" apenas por snapshots — alguns com meses de idade e centenas de gigabytes em deltas — é mais frequente do que deveria. O trabalho começa exatamente por aí: sanear as cadeias de snapshot, implantar backup dedicado com repositório independente e cópia externa, e estabelecer políticas de retenção alinhadas ao negócio de cada empresa.

Com mais de 18 anos de experiência, 550+ empresas atendidas e certificação Microsoft Gold Partner, a Duk opera backup gerenciado com Veeam, replicação para nuvem em data center próprio em Alphaville, monitoramento contínuo de jobs e testes regulares de restauração — tudo com suporte 24/7 e SLA definido. O snapshot volta a ocupar o lugar que sempre deveria ter tido: uma ferramenta tática de janelas de mudança, enquanto o backup real garante que os dados da empresa sobrevivem a qualquer falha, erro humano ou ataque.

Se hoje a proteção do seu ambiente virtualizado depende de snapshots, vale tratar isso com urgência. Uma conversa com a equipe da Duk pode mapear os riscos do cenário atual e desenhar uma estratégia de proteção de dados que funciona quando mais importa: no dia em que algo dá errado.