Snapshot vs Backup: Diferenças e Quando Usar Cada Um

Pontos-Chave deste Artigo

• Snapshot ≠ backup — são complementares, não substitutos
• Snapshots ficam no mesmo storage dos dados — se o storage morre, os snapshots morrem junto
• Ransomware sofisticado deleta snapshots VSS como primeiro passo do ataque
• A proteção real combina snapshots (curto prazo) + backup imutável offsite (longo prazo)

O Que é Snapshot

Um snapshot é uma fotografia instantânea do estado de um disco, volume ou máquina virtual em um momento específico. Diferente de um backup que copia fisicamente os dados para outro local, o snapshot apenas "congela" o estado atual e rastreia as mudanças que acontecem depois.

Pense em um snapshot como um "undo" para servidores. Você vai aplicar uma atualização do Windows? Tire um snapshot antes. Se a atualização quebrar algo, reverta o snapshot e o servidor volta ao estado anterior em segundos — não em horas.

Como Funciona Tecnicamente

Snapshots usam técnicas como copy-on-write (CoW) ou redirect-on-write (RoW):

• Copy-on-Write: quando um bloco de dados é modificado após o snapshot, o bloco original é copiado para um espaço reservado antes da modificação. O snapshot mantém referências aos blocos originais
• Redirect-on-Write: as novas escritas são redirecionadas para um local diferente. O snapshot aponta para os blocos originais inalterados

Em ambos os casos, o snapshot é criado em milissegundos — não copia todos os dados, apenas prepara o rastreamento de mudanças. Por isso é rápido. Por isso também não é backup.

Snapshot vs Backup: A Comparação Completa

Aspecto	Snapshot	Backup
O que é	Fotografia do estado em um instante	Cópia independente dos dados
Velocidade de criação	Segundos	Minutos a horas
Onde fica armazenado	Mesmo storage dos dados originais	Local separado (nuvem, offsite)
Proteção contra falha de hardware	Não — se o disco morre, o snapshot morre	Sim — cópia independente
Proteção contra ransomware	Parcial — ransomware pode deletar snapshots	Sim — com backup imutável
Retenção	Curto prazo (horas a dias)	Longo prazo (meses a anos)
Impacto em performance	Sim — acumula delta, degrada I/O	Mínimo — roda em janela agendada
Restauração granular	Limitada — tudo ou nada	Sim — 1 arquivo, 1 e-mail, 1 tabela
Compliance (LGPD, ISO)	Não atende — sem isolamento	Sim — offsite, criptografado, auditável

Tipos de Snapshot

1. Snapshot de Volume/Disco

Captura o estado de um volume de storage inteiro. Exemplos: LVM snapshots (Linux), ZFS snapshots, snapshots de storage arrays (Dell EMC, NetApp, HPE). Útil para proteção de volumes de dados em servidores físicos.

2. Snapshot de VM (Máquina Virtual)

Captura o estado completo de uma VM — disco, memória, configuração. Tecnologias: VMware snapshots, Hyper-V checkpoints, Proxmox snapshots. O mais comum em ambientes virtualizados. Permite reverter a VM inteira para um ponto anterior.

3. VSS (Volume Shadow Copy Service)

Tecnologia Microsoft que coordena snapshots application-consistent em Windows. Antes de capturar o snapshot, o VSS notifica aplicações (SQL Server, Exchange, IIS) para que descarreguem buffers e garantam consistência. Sem VSS, o snapshot pode capturar dados parcialmente escritos — resultando em corrupção.

4. Snapshot de Aplicação

Snapshots específicos de bancos de dados (SQL Server, Oracle, PostgreSQL). Garantem consistência transacional — todas as transações são completadas ou revertidas antes do snapshot.

---

Tecnologias de Snapshot por Plataforma

Cada plataforma de virtualização e storage implementa snapshots de forma diferente, com capacidades, limitações e boas práticas distintas. A tabela abaixo compara as principais tecnologias encontradas em ambientes empresariais brasileiros.

Plataforma	Tecnologia de Snapshot	Tipo	Limite Recomendado	Application-Consistent?	Impacto em Performance
VMware vSphere	VMDK Snapshots (redo logs)	Redirect-on-Write	3 snapshots, máx. 72h	Sim (com VMware Tools + VSS)	Alto se acumulados (I/O fragmentado)
Hyper-V	Checkpoints (Standard e Production)	Copy-on-Write	50 checkpoints (mas recomendado 2-3)	Sim (Production Checkpoints usam VSS)	Moderado
Proxmox	QEMU Snapshots / ZFS Snapshots	Copy-on-Write (ZFS)	Sem limite técnico em ZFS; 2-3 recomendados	Parcial (requer QEMU Guest Agent)	Baixo com ZFS; alto com QEMU em LVM-thin
Windows Server (VSS)	Volume Shadow Copy Service	Copy-on-Write	64 por volume	Sim (nativo)	Baixo a moderado
ZFS (Linux/FreeBSD)	ZFS Snapshots	Copy-on-Write	Sem limite prático	Crash-consistent (application via scripts)	Muito baixo (design nativo)
LVM (Linux)	LVM Snapshots	Copy-on-Write	1-2 (espaço alocado fixo)	Crash-consistent	Alto (degrada write performance)
Dell EMC (Unity/PowerStore)	Array-based Snapshots	Redirect-on-Write	256-1024 por volume	Sim (com integração VSS/VAAI)	Baixo (offload no storage)
NetApp (ONTAP)	NetApp Snapshots (WAFL)	Redirect-on-Write	1023 por volume	Sim (com SnapManager)	Muito baixo (design nativo do WAFL)

Observações Importantes por Plataforma

• VMware: nunca use snapshots como backup de longo prazo. Snapshots VMware criam arquivos delta (-delta.vmdk) que crescem sem limite. Se o delta ficar maior que o disco base, a performance degrada drasticamente. Consolidar snapshots antigos também gera I/O intenso e pode causar indisponibilidade temporária.
• Hyper-V: sempre prefira Production Checkpoints (padrão no Server 2016+) em vez de Standard Checkpoints. Production Checkpoints usam VSS para garantir consistência de aplicação. Standard Checkpoints salvam o estado da memória (como hibernação) e podem causar problemas em bancos de dados.
• Proxmox: use ZFS como backend de storage quando possível — os snapshots ZFS são nativos, eficientes e praticamente sem impacto em performance. Evite snapshots QEMU em LVM-thin para cargas de trabalho de banco de dados.
• Storage arrays: snapshots em nível de storage (Dell EMC, NetApp, HPE) são os mais eficientes e com menor impacto, porque o processamento é feito pelo hardware do storage, não pelo hipervisor.

---

Gerenciamento de Cadeia de Snapshots

Um dos maiores problemas operacionais com snapshots é o gerenciamento da cadeia (snapshot chain). Cada snapshot cria uma camada de dados delta. Com o tempo, essas camadas se acumulam e criam uma cadeia que afeta performance, consome espaço e complica a administração.

Como a Cadeia de Snapshots Funciona

Imagine um livro. O disco base é o livro original. Cada snapshot é uma folha de errata colada em cima. Para ler a versão atual, o sistema precisa consultar o livro original e todas as erratas em ordem. Quanto mais erratas, mais lento fica.

1. Snapshot 1: cria delta 1 — apenas blocos alterados após o snapshot
2. Snapshot 2: cria delta 2 — blocos alterados após snapshot 2 (delta 1 congela)
3. Snapshot 3: cria delta 3 — e assim por diante
4. Leitura atual: sistema precisa consultar disco base + delta 1 + delta 2 + delta 3

Problemas de Cadeias Longas

Problema	Causa	Impacto	Solução
Degradação de I/O	Cada leitura precisa consultar múltiplos deltas	VM até 5x mais lenta	Manter máximo 2-3 snapshots ativos
Consumo de espaço	Deltas acumulam todas as mudanças	Datastore cheio, VMs pausam	Monitorar espaço livre; alertas automáticos
Consolidação lenta	Remover snapshots requer mesclar deltas no disco base	Downtime durante consolidação	Consolidar em janela de manutenção
Falha de consolidação	Disco bloqueado ou espaço insuficiente	VM fica em estado inconsistente	Manter 20% de espaço livre no datastore
Backup mais lento	Soluções de backup precisam processar toda a cadeia	Janela de backup estoura	Consolidar antes de executar backup

Boas Práticas de Gerenciamento

• Regra dos 3: nunca manter mais de 3 snapshots ativos simultaneamente em VMware ou Hyper-V
• Regra das 72h: snapshots devem ser consolidados em no máximo 72 horas — idealmente 24h
• Monitoramento automatizado: alertas quando snapshots existem há mais de 48h ou quando deltas ultrapassam 20% do disco base
• Documentar propósito: ao criar um snapshot, documentar por que foi criado e quando deve ser removido. Snapshots "esquecidos" são a principal causa de problemas
• Separar snapshot de backup: o backup da DataBackup não depende de snapshots de longa duração — cria snapshot temporário (segundos), copia os dados e remove o snapshot imediatamente

---

Por Que Snapshot Sozinho Não Protege Contra Ransomware

Este é o ponto mais crítico e mais mal compreendido. Muitas empresas acreditam que "temos snapshots, estamos protegidos". A realidade:

1. Ransomware deleta VSS: uma das primeiras ações de ransomwares como LockBit, BlackCat e Conti é executar vssadmin delete shadows /all /quiet — deletando todos os snapshots VSS do Windows antes de criptografar
2. Snapshots ficam no mesmo storage: se o ransomware compromete o storage (via credenciais admin), os snapshots são destruídos junto com os dados
3. Acesso administrativo: com credenciais de admin da infraestrutura virtual (vCenter, Hyper-V Manager), o atacante pode deletar snapshots de VMs
4. Storage arrays comprometidos: se o atacante acessa o console do storage, pode destruir snapshots no nível de hardware

A defesa que funciona: backup imutável com Object Lock em storage offsite. Mesmo com credenciais de admin, os dados não podem ser deletados ou alterados durante o período de retenção. Snapshots são o primeiro nível de defesa; backup imutável é o último — e mais importante.

---

Quando Usar Snapshots (Corretamente)

• Antes de atualizações: patching de SO, updates de aplicações, mudanças de configuração — snapshot como rede de segurança para rollback rápido
• Desenvolvimento e teste: clonar ambientes de produção via snapshot para testes, sem afetar produção
• Pontos de recuperação intra-dia: para proteger contra erros operacionais entre os ciclos de backup automático
• Complemento ao backup: snapshots para RPO de minutos (proteção rápida) + backup para RPO de horas e retenção de longo prazo

Quando NÃO Usar Snapshots

Tão importante quanto saber quando usar snapshots é saber quando não usar. Os cenários abaixo representam situações em que snapshots dão falsa sensação de segurança ou causam problemas operacionais:

Cenário	Por Que Não Usar Snapshot	O Que Usar em Vez
Proteção única contra ransomware	Ransomware deleta snapshots como primeiro passo	Backup imutável offsite com Object Lock
Retenção de longo prazo (meses/anos)	Degrada performance e consome espaço indefinidamente	Backup na nuvem com política de retenção
Compliance (LGPD, ISO 27001)	Auditorias exigem cópias independentes em local separado	Backup criptografado offsite com logs de auditoria
Proteção contra falha de hardware	Snapshot fica no mesmo disco/storage — se falhar, perde tudo	Backup em storage separado ou regra 3-2-1
Proteção contra desastre físico	Enchente/incêndio destrói storage e snapshots juntos	DRaaS com replicação offsite
Bancos de dados com alto volume de escrita	Deltas crescem rapidamente, fragmentam I/O e degradam performance	Backup application-aware com log truncation
Ambientes com muitas VMs e storage limitado	Snapshots competem por espaço — risco de datastore cheio	Backup incremental para storage externo

---

Snapshot + Backup: Boas Práticas para Proteção Completa

A proteção mais robusta combina snapshots para recuperação rápida de curto prazo com backup para proteção de longo prazo e resiliência. Abaixo, um framework prático para implementar ambos de forma integrada.

Framework de Proteção em Camadas

Camada	Tecnologia	RPO	RTO	Propósito
1. Snapshot local	Snapshots de VM ou VSS	Minutos	Segundos	Rollback rápido de erros operacionais e patches com problema
2. Backup local	Backup automático em storage dedicado	4-12 horas	1-4 horas	Restauração rápida de arquivos, VMs e bancos de dados
3. Backup offsite imutável	Backup imutável na nuvem	4-24 horas	4-12 horas	Proteção contra ransomware, desastre e falha de site
4. DRaaS	DRaaS com Run Direct	Conforme backup	15-30 minutos	Failover completo do servidor na nuvem

Checklist de Implementação: Snapshot + Backup

1. Snapshots automatizados antes de patches: configurar snapshot automático via script antes de qualquer atualização de SO ou aplicação
2. Limite de 3 snapshots ativos: alertas automáticos quando ultrapassar; consolidação em até 72h
3. Backup application-aware: usar VSS (Windows) ou pre/post scripts (Linux) para garantir consistência de bancos de dados
4. Backup offsite diário: enviar cópia para nuvem com criptografia AES-256 em trânsito e repouso
5. Imutabilidade obrigatória: ativar Object Lock para todas as cópias offsite — mínimo 30 dias de retenção imutável
6. Teste de restauração mensal: validar que tanto snapshots quanto backups podem ser restaurados com sucesso
7. Monitoramento de espaço: alertas quando datastore/LUN atingir 80% de capacidade — snapshots que crescem podem encher o storage
8. Documentação: registrar política de snapshots (quando criar, quando consolidar, quem é responsável) na política de backup

Workflow Recomendado: Snapshot Temporário para Backup

A abordagem mais eficiente — e usada pela DataBackup — combina snapshot e backup em um processo automatizado:

1. Início do backup: o agente de backup aciona snapshot application-consistent (VSS/QEMU Guest Agent)
2. Cópia dos dados: o backup lê os dados do snapshot (estado consistente, sem impacto na VM em execução)
3. Remoção do snapshot: imediatamente após a cópia, o snapshot temporário é removido — sem acumular deltas
4. Envio para nuvem: os dados são enviados para storage offsite com criptografia e imutabilidade

Esse workflow captura a vantagem do snapshot (consistência de aplicação sem parar a VM) sem os problemas do snapshot (acúmulo de deltas, degradação de performance). O snapshot existe por segundos a minutos — tempo suficiente para o backup copiar os dados.

---

A Estratégia Correta: Snapshot + Backup Imutável

A proteção completa combina as duas tecnologias:

Camada	Tecnologia	RPO	Propósito
1ª Linha	Snapshots (VSS, VM)	Minutos	Rollback rápido de erros operacionais
2ª Linha	Backup automático local	4-24 horas	Restauração local rápida
3ª Linha	Backup imutável offsite (nuvem)	4-24 horas	Proteção contra ransomware e desastre
4ª Linha	DRaaS com Run Direct	Minutos	Failover completo do servidor na nuvem

---

Benchmarks de Recuperação: Snapshot vs Backup por Cenário

A escolha entre snapshot e backup depende do tempo de recuperação aceitável para cada sistema. A tabela abaixo apresenta benchmarks realistas de tempo de recuperação para diferentes cenários, baseados em ambientes empresariais típicos com volumes entre 50 GB e 500 GB.

Cenário de Recuperação	Snapshot Local	Backup Local (Storage Dedicado)	Backup na Nuvem	DRaaS (Run Direct)
Reverter atualização com problema (VM 50 GB)	10-30 segundos	20-45 minutos	1-3 horas	15-20 minutos
Restaurar 1 arquivo (5 MB)	N/A (tudo ou nada)	1-5 minutos	2-10 minutos	N/A
Restaurar VM completa (100 GB)	10-60 segundos	30 min - 2 horas	2-8 horas (depende da banda)	15-30 minutos
Restaurar banco de dados (50 GB)	10-30 segundos (crash-consistent)	20-60 minutos (application-consistent)	1-4 horas	15-25 minutos
Recuperar servidor completo após ransomware	FALHA (snapshots deletados pelo ransomware)	FALHA (se conectado à rede comprometida)	2-8 horas (backup imutável intacto)	15-30 minutos (failover direto)
Bare-metal recovery de servidor físico (500 GB)	N/A (snapshot é do storage, não do servidor)	2-6 horas	6-24 horas	30-60 minutos (boot via nuvem)

Os dados acima deixam claro por que snapshot e backup devem ser usados juntos, nunca como substitutos. O snapshot resolve problemas rápidos do dia a dia (patches, erros operacionais), enquanto o backup imutável é a última linha de defesa contra ameaças que destroem snapshots — como ransomware e falha de hardware.

---

Comparativo de Tecnologias de Snapshot: Quando Usar Cada Uma

A escolha da tecnologia de snapshot certa depende do ambiente de virtualização, do tipo de carga de trabalho e dos requisitos de consistência de aplicação. A tabela abaixo resume quando cada tecnologia é a melhor opção para cenários específicos:

Se Você Usa...	Melhor Tecnologia de Snapshot	Por Quê	Cuidado
VMware vSphere	VMDK Snapshots + VSS (via VMware Tools)	Suporte nativo a application-consistent snapshots. Integração com todas as soluções de backup enterprise	Nunca manter mais de 3 snapshots ou por mais de 72h. Consolidação gera I/O intenso
Hyper-V	Production Checkpoints (padrão no Server 2016+)	Usa VSS automaticamente para garantir consistência de bancos de dados e aplicações	NUNCA usar Standard Checkpoints em produção — salvam estado de memória como hibernação
Proxmox com ZFS	ZFS Snapshots	Copy-on-write nativo, impacto mínimo em performance, sem limite prático de snapshots	Requer QEMU Guest Agent para consistência de aplicação. Sem ele, é crash-consistent apenas
Proxmox com LVM-thin	QEMU Snapshots	Funciona sem ZFS, suportado nativamente pelo Proxmox	Impacto alto em performance. Evitar para bancos de dados com alto volume de escrita
Storage Dell EMC / NetApp	Array-based Snapshots	Processamento no hardware do storage, impacto mínimo nos servidores, suporte a milhares de snapshots	Custo do hardware. Requer integração com VSS/VAAI para application-consistency
Windows Server (físico)	VSS (Volume Shadow Copy)	Nativo, sem custo adicional, suporte a application-consistent para SQL Server, Exchange, IIS	Ransomware executa vssadmin delete shadows como primeiro passo — não é proteção contra ataques
Linux (físico)	LVM Snapshots ou ZFS	ZFS: eficiente e com impacto mínimo. LVM: disponível em praticamente toda distribuição	LVM snapshots degradam write performance. ZFS requer planejamento de storage

Independente da tecnologia de snapshot escolhida, o princípio é o mesmo: snapshots são complementos, não substitutos do backup. A DataBackup suporta backup application-aware para VMware, Hyper-V e Proxmox, criando snapshots temporários automaticamente durante o processo de backup — sem acumular deltas e sem impacto em performance. Combinado com backup imutável e backup incremental, a proteção é completa do curto ao longo prazo. Teste grátis 14 dias.

---

A DataBackup integra todas essas camadas em uma plataforma única. O backup application-aware para VMware, Hyper-V e Proxmox garante consistência de snapshots antes do backup. A imutabilidade com Object Lock garante que o backup está protegido. E a restauração granular permite recuperar desde 1 arquivo até o servidor inteiro via bare-metal recovery. Teste grátis 14 dias.