Snapshots Não São Backups: A Ilusão da Recuperação Instantânea e o Risco para seu Storage

Por: Sysadmin Veterano (Anti-Hype)

Se eu ganhasse um centavo para cada vez que um "Arquiteto de Soluções" ou um "DevOps Ninja" me dissesse que não precisamos de uma estratégia de backup tradicional porque "o storage faz snapshots a cada 15 minutos", eu já teria me aposentado em uma fazenda sem sinal de internet, longe de qualquer contêiner Kubernetes.

Vamos deixar algo claro logo na primeira linha, antes que você corra para o LinkedIn postar sobre sua infraestrutura "ágil": Snapshots não são backups. Nunca foram, nunca serão.

Eles são uma conveniência. São um "Ctrl+Z" glorificado para quando o estagiário roda um UPDATE sem WHERE. Mas confiar neles para Disaster Recovery (DR) é o equivalente digital a dirigir a 180km/h sem cinto de segurança, confiando apenas que o airbag vai disparar. Vamos dissecar essa falácia técnica antes que o seu storage array decida lhe ensinar uma lição de humildade.

O Hype do "Botão Desfazer": Por que Juniors e Gerentes Amam Snapshots

Para a gerência e para os desenvolvedores que nunca tiveram que reconstruir um RAID degradado às 3 da manhã, o snapshot parece mágica.

"Olha só!", exclamam eles em reuniões de planejamento, apontando para slides coloridos de fornecedores de HCI (Hyper-Converged Infrastructure). "Podemos recuperar uma VM de 4TB em segundos! O RTO (Recovery Time Objective) é zero!".

O apelo é óbvio. Backups tradicionais são chatos. Eles envolvem agentes, janelas de backup que estouram, tráfego de rede, fitas (sim, elas ainda existem e são mais confiáveis que seu script Python) ou buckets S3 que custam uma fortuna em taxas de saída.

O snapshot, por outro lado, é instantâneo. Ele vende a ilusão de segurança sem o "custo" do trabalho pesado. É a gratificação instantânea aplicada à proteção de dados. Mas, como qualquer sysadmin que sobreviveu à era do Y2K sabe: se parece bom demais para ser verdade, é porque há uma pegadinha técnica desagradável escondida na camada de abstração.

A Realidade Operacional: A Mecânica do Copy-on-Write (CoW) e Redirect-on-Write (RoW)

Para entender por que seu snapshot é frágil, você precisa parar de olhar para a GUI bonita do vCenter e entender o que está acontecendo nos blocos do disco.

Um snapshot não é uma cópia dos seus dados. Se fosse, levaria o mesmo tempo que um backup completo. Um snapshot é, essencialmente, uma tabela de ponteiros e timestamps. É metadados.

Existem duas metodologias principais que governam essa feitiçaria, e ambas têm implicações de performance e integridade:

1. Copy-on-Write (CoW)

O método clássico e doloroso.

1. Você cria um snapshot. O sistema congela a tabela de alocação original.

2. O servidor tenta escrever um novo dado no Bloco A.

3. O storage array entra em pânico, lê o dado original do Bloco A, copia esse dado antigo para um espaço de snapshot, e só então escreve o novo dado no Bloco A.

O resultado: Penalidade de escrita. Cada operação de write vira três operações de I/O (Read original + Write old + Write new). Se o seu banco de dados é transacional e pesado, parabéns: você acabou de joelhar a performance do seu storage.

2. Redirect-on-Write (RoW)

O método "moderno" que a maioria dos storages All-Flash e sistemas como ZFS usam.

1. Você cria um snapshot.

2. O servidor tenta escrever no Bloco A.

3. O storage diz "esquece o Bloco A, ele agora é somente leitura" e redireciona a escrita para um novo Bloco B.

O resultado: Menos penalidade de escrita imediata, mas você acaba com um sistema de arquivos que parece um queijo suíço fragmentado. A leitura sequencial morre, porque o que logicamente é um arquivo contínuo, fisicamente está espalhado por todo o array.

Em ambos os casos, a verdade imutável permanece: Os dados do snapshot vivem no mesmo substrato físico e lógico que os dados de produção.

Figura: Figura 1: A diferença crítica entre a fragilidade de uma cadeia de snapshots e a robustez de um backup isolado.

Onde a Estratégia Falha: Dependência da Cadeia, Latência de Disco e Ransomware

Aqui é onde a realidade bate na porta com um pé de cabra. A dependência de snapshots como única linha de defesa falha em três cenários catastróficos que, estatisticamente, vão acontecer com você.

1. A Falácia da Dependência da Cadeia (Chain Dependency)

Um snapshot é um arquivo delta. Ele diz: "Eu sou a diferença entre o estado atual e o estado anterior". Se você tem uma cadeia de 50 snapshots e o snapshot base (ou o disco virtual pai) corrompe, todos os snapshots subsequentes são lixo digital inútil.

Imagine que você tem um arquivo .vmdk (ou LUN) base e vários arquivos delta (-000001.vmdk, -000002.vmdk). Se o array de storage encontrar um bit rot ou um erro de setor no disco base, não importa quantos snapshots "de backup" você tenha. A fundação da casa ruiu; não adianta ter fotos das janelas do segundo andar.

2. Latência e Consolidação (O Pesadelo do "Delete All")

Você já tentou deletar (consolidar) um snapshot que ficou aberto por 6 meses em uma VM de produção? Se sim, você sabe que o servidor "congela". Para consolidar os dados, o hypervisor precisa commitar gigabytes de dados delta de volta para o disco base. Isso gera uma tempestade de I/O tão violenta que muitas vezes derruba a aplicação. Eu já vi DBAs chorando enquanto o storage array entrava em latência de 500ms durante uma consolidação de snapshot mal planejada.

3. Ransomware não liga para seus Snapshots Locais

Este é o ponto que faz os executivos suarem frio. As gangues de Ransomware modernas (LockBit, Conti, etc.) não criptografam apenas seus arquivos .docx. Eles atacam a infraestrutura. O primeiro passo de um script de ransomware sofisticado, após ganhar privilégios administrativos, é enumerar as cópias de sombra (VSS) e os snapshots do storage e executar algo simples como:

vssadmin.exe Delete Shadows /All /Quiet

Ou, se eles tiverem acesso à console do seu storage ou virtualizador:

# Exemplo hipotético de um atacante limpando snapshots via CLI
Get-Snapshot -VM "Critical-DB" | Remove-Snapshot -Confirm:$false

Se o seu "backup" reside no mesmo console de gerenciamento e no mesmo array físico que os dados criptografados, você não tem um backup. Você tem um refém criptografado duas vezes.

A Alternativa Chata que Funciona: Isolamento, Imutabilidade e a Regra 3-2-1

Eu sei, eu sei. Você quer ouvir sobre a nova ferramenta de IA que prevê falhas. Mas a solução para dormir tranquilo à noite é velha, chata e funciona.

Para que algo seja considerado um Backup Real, ele precisa ser independente da fonte. Ele deve ser capaz de sobreviver à destruição total do array de storage primário.

A Regra 3-2-1 (Ainda é Lei)

Não importa o que o vendedor de nuvem diga, a física exige redundância.

• 3 cópias dos dados.

• 2 mídias diferentes (ex: Storage Primário + Appliance de Deduplicação ou Fita).

• 1 cópia fora do site (Offsite/Cloud).

Comparativo: Snapshot vs. Backup

Característica	Snapshot	Backup Tradicional
Dependência	Depende do disco/volume original	Independente e autônomo
Performance de Restore	Quase instantânea (Rollback)	Lenta (Cópia de dados via rede)
Proteção contra Falha de Array	Nenhuma (Zero)	Total
Impacto no Storage	Alto (se mantido por muito tempo)	Baixo (se usar offloading correto)
Imutabilidade	Geralmente fraca (mesma console admin)	Alta (WORM, S3 Object Lock)

O Santo Graal: Imutabilidade

A única defesa real contra ransomware hoje é a imutabilidade. Backups onde, uma vez escritos, nem mesmo o administrador root pode deletar ou alterar por um período definido (Retention Lock). Seus snapshots no storage primário raramente oferecem isso de forma robusta. Um repositório Linux Hardened com XFS imutável ou um bucket S3 com Object Lock são as trincheiras onde a guerra é vencida.

Veredito Técnico: Pare de Brincar de Roleta Russa com a Infraestrutura

Snapshots são uma ferramenta operacional fantástica. Eu uso todos os dias antes de aplicar patches no sistema operacional ou atualizar esquemas de banco de dados. Eles são a rede de segurança para a estupidez operacional diária.

Mas confundir essa conveniência com uma estratégia de Disaster Recovery é negligência profissional.

Se o seu storage pegar fogo, se o controlador do RAID enlouquecer e corromper os metadados, ou se um invasor tiver acesso à sua console de gerenciamento, seus snapshots desaparecerão junto com seus dados de produção.

Portanto, parem de tentar reinventar a roda com "recuperação instantânea" baseada apenas em ponteiros de disco. Façam backups. Tirem os dados do prédio. Usem mídias diferentes. Testem o restore.

O tédio de um backup bem feito é o único luxo que um sysadmin pode ter quando o mundo (ou o datacenter) está pegando fogo.

---

Referências Técnicas

1. SNIA (Storage Networking Industry Association). "Data Protection: Snapshots are NOT Backups". Disponível em whitepapers técnicos da indústria.

2. VMware Knowledge Base. "Best practices for using snapshots in the vSphere environment (1025279)". Documenta a degradação de performance e riscos de consolidação.

3. NIST SP 800-209. "Security Guidelines for Storage Infrastructure". Enfatiza a necessidade de isolamento de dados para recuperação de ciberataques.

4. CISA (Cybersecurity and Infrastructure Security Agency). Alertas sobre Ransomware visando backups online e a necessidade de armazenamento offline/imutável.