No dia a dia da administração de servidores, a agilidade é fundamental. Provedores de Cloud e painéis como DirectAdmin facilitam a criação de “fotos” do sistema com um clique. No entanto, muitos administradores iniciantes cometem um erro que pode ser catastrófico: acreditar que snapshot não é backup é apenas um detalhe semântico.
Na prática, entender que um snapshot não é backup separa os profissionais que recuperam sistemas em minutos daqueles que enfrentam a perda total de dados após uma falha crítica de hardware ou corrupção de storage.
O que é, tecnicamente, um Snapshot?
Um snapshot é um registro do estado de um sistema de arquivos em um ponto específico no tempo. Ele funciona de forma quase instantânea porque, na maioria das vezes, utiliza a tecnologia Copy-on-Write (CoW).
Quando você tira um snapshot, o sistema não duplica os dados. Ele apenas marca os blocos de dados existentes. Quando um arquivo é alterado, o sistema preserva o bloco original (o “snapshot”) e escreve a mudança em um novo bloco.
As limitações do Snapshot
- Dependência da Origem: Se o disco físico ou o volume lógico falhar, o snapshot é perdido.
- Performance: Manter snapshots por muito tempo aumenta a latência de I/O, pois o sistema precisa gerenciar diversas camadas de “deltas” (diferenças de dados).
Por que Snapshot não é Backup?
A principal razão técnica pela qual afirmamos que snapshot não é backup é a independência. Para ser considerado um backup real, os dados precisam estar isolados da fonte original.
Imagine que você gerencia um servidor em AlmaLinux com CloudLinux. Se ocorrer uma corrupção grave na tabela de partições ou o SSD do servidor falhar fisicamente, todos os seus snapshots internos desaparecem instantaneamente. O backup, por outro lado, estaria seguro em um storage externo ou em uma nuvem S3, pronto para ser restaurado em um hardware totalmente novo.
Riscos de confiar apenas em Snapshots:
- Falha de Hardware: O Single Point of Failure (Ponto Único de Falha) permanece o mesmo.
- Corrupção Lógica: Se um sistema de arquivos for corrompido, o snapshot pode carregar a mesma inconsistência.
- Ransomware: Muitos malwares modernos conseguem identificar e deletar snapshots locais antes de criptografar os dados.
Backup: A sua última linha de defesa
Diferente do snapshot, o backup é uma cópia completa, independente e, idealmente, imutável. Um processo de backup robusto deve seguir a Regra 3-2-1:
- 3 Cópias dos dados.
- 2 Mídias ou tecnologias diferentes.
- 1 Cópia fora do seu datacenter (Offsite).
Quando usar cada um? (O Cenário Híbrido)
Um SysAdmin experiente utiliza ambos. O segredo está no caso de uso:
- Use Snapshots para: Testes de atualização de Kernel, modificações rápidas em arquivos de configuração (
/etc/my.cnfousysctl.conf) ou antes de instalar novos módulos no servidor. Se algo falhar, o rollback é imediato. - Use Backups para: Proteção de longo prazo, conformidade legal, recuperação após desastres naturais ou falhas do provedor de infraestrutura.
Conclusão
Utilize a agilidade dos snapshots para o seu fluxo de trabalho diário, mas nunca ignore a máxima da infraestrutura: snapshot não é backup. Garanta que seus dados mais preciosos estejam versionados e armazenados de forma independente.
FAQ
Não. O snapshot é uma imagem instantânea que depende do disco de origem. Se o disco falhar fisicamente, o snapshot é perdido. O backup é uma cópia independente em um local isolado.
O maior risco é o Ponto Único de Falha. Como o snapshot reside no mesmo storage que os dados ativos, uma falha de hardware, corrupção do sistema de arquivos ou ataque de ransomware que limpe o storage destruirá tanto a origem quanto os snapshots.
Sim, se mantidos por muito tempo. O acúmulo de snapshots cria uma cadeia de deltas que aumenta a latência de escrita e leitura (I/O Wait), impactando a performance de aplicações e bancos de dados.
Use snapshots para operações de curto prazo, como antes de atualizar o kernel, modificar configurações críticas no Apache/Nginx ou testar uma nova versão de uma aplicação. Após validar que está tudo certo, o snapshot deve ser removido.
Veja Mais:
Como Migrar VPS para Bare Metal: Planejamento e Arquitetura
Cloud Exit: Por que grandes empresas estão voltando ao Bare Metal?
Como Fazer Backup Incremental Sem Carga na CPU em Servidores
Guia Completo: Btrfs em Servidores de Produção (Instalação e Setup)

