Backup 3-2-1 na prática: o que separa uma cópia de uma proteção real contra ransomware
A regra 3-2-1 é simples de enunciar e difícil de fazer direito. O que o ransomware moderno mudou e por que ter backup não é o mesmo que estar protegido.
7 min de leitura
Quase toda empresa tem backup, e quase nenhuma descobre que o backup não servia antes de precisar dele. O ransomware moderno vive exatamente nessa distância entre ter uma cópia e ter uma proteção, e aprendeu a atacar o backup primeiro.
Este guia explica a regra 3-2-1 de forma clara e mostra, com honestidade, por que fazer isso bem é um projeto de engenharia, e não uma configuração de fim de semana.
Resumo rápido
- A regra 3-2-1 pede três cópias dos dados, em duas mídias diferentes, com uma cópia fora do local.
- O ransomware moderno procura e destrói o backup, então a regra evoluiu para a 3-2-1-1-0: uma cópia imutável ou offline e zero erros nos testes de recuperação.
- Onde os projetos falham não é na ferramenta, é no isolamento, no teste periódico e na operação contínua.
- Se você hesitou em qualquer pergunta do teste no fim deste texto, existe uma lacuna que só aparece na hora errada.
O que é a regra 3-2-1
É a base da proteção de dados e cabe numa linha. Você mantém três cópias dos seus dados, sendo a de produção mais duas de backup, guardadas em duas mídias ou tecnologias diferentes, com pelo menos uma cópia fora do local.
Cada número existe para que um mesmo problema não leve todas as cópias juntas. Duas cópias no mesmo disco somem com o disco, por isso as duas mídias, como um repositório em disco local e uma fita, ou um storage local e um serviço de nuvem. E tudo que está no mesmo prédio está sujeito ao mesmo incêndio, à mesma inundação ou ao mesmo furto, por isso a cópia fora do local, na nuvem ou num segundo data center.
Simples de dizer. O problema é que o ransomware moderno tornou essa regra necessária, porém insuficiente.
O que o ransomware mudou
Muitos ataques não criptografam na hora. O invasor entra, passa dias ou semanas mapeando a rede e procura justamente o seu backup. O guia #StopRansomware da CISA registra que muitas variantes tentam encontrar backups acessíveis para apagá-los ou criptografá-los. Se o backup está acessível pela mesma rede e com as mesmas credenciais, ele é atingido junto, e no dia do ataque você fica com três cópias inúteis.
Por isso a regra evoluiu para incluir mais duas garantias. A primeira é uma cópia imutável ou offline, que não pode ser alterada nem apagada, nem por um administrador comprometido, e funciona como a rede de segurança que o ransomware não alcança. A segunda é a verificação, porque backup que ninguém testou não conta, e a restauração precisa ser rotina e não uma descoberta na emergência.
A regra 3-2-1-1-0
A Veeam formaliza essas duas garantias acrescentando dois dígitos à regra clássica:
| Dígito | O que pede |
|---|---|
| 3 | Três cópias dos dados: a de produção e mais duas |
| 2 | Duas mídias ou tecnologias de armazenamento diferentes |
| 1 | Uma cópia fora do local |
| 1 | Uma cópia imutável ou offline (air gap) |
| 0 | Zero erros na verificação de recuperação |
A CISA chega ao mesmo ponto por outro caminho: o guia #StopRansomware recomenda manter backups offline e criptografados dos dados críticos e testar regularmente a disponibilidade e a integridade deles num cenário de recuperação.
Imutável ou offline: duas formas de ter a cópia intocável
As duas cumprem o mesmo papel, de formas diferentes, e muitas empresas combinam as duas.
Cópia imutável. Os arquivos de backup ficam protegidos contra alteração e exclusão durante um período definido. Dois exemplos no ecossistema Veeam:
- Hardened Repository. Um repositório em servidor Linux no qual, durante o período de imutabilidade, os arquivos de backup não podem ser movidos, modificados nem excluídos, apenas copiados. As credenciais usadas para incluir o servidor são de uso único e não ficam guardadas na infraestrutura de backup.
- Object storage com Object Lock. Em repositórios compatíveis com S3, a imutabilidade usa o recurso de Object Lock, que normalmente precisa ser habilitado na criação do bucket, junto com o versionamento.
Cópia offline (air gap). A cópia fica fisicamente ou logicamente desconectada da rede de produção, como uma fita retirada da biblioteca e guardada em outro local. O que não está conectado não pode ser criptografado remotamente.
Em qualquer das duas, o desenho em volta importa tanto quanto o recurso: credenciais do ambiente de backup separadas das contas do dia a dia, MFA no acesso à console, acesso administrativo restrito e monitoramento de quem tenta mudar retenções ou apagar pontos de restauração.
Testar a restauração: o zero da regra
Ter o arquivo de backup não prova que ele restaura. O zero da regra pede que a recuperação seja verificada, de preferência de forma automática e recorrente.
No Veeam, essa verificação é feita pelo SureBackup: as máquinas são iniciadas a partir do backup num ambiente isolado, e testes confirmam que o sistema sobe e que as aplicações respondem, sem afetar a produção. Isso responde se o backup funciona. Para saber se a operação volta a tempo, vale também ensaiar periodicamente a restauração de um sistema crítico inteiro, cronometrando cada etapa.
Dois números orientam esse trabalho e precisam ser decididos com a área de negócio:
- RPO, quanto de dado a empresa aceita perder, que define a frequência dos backups.
- RTO, em quanto tempo cada sistema precisa voltar, que define a arquitetura de recuperação e a ordem de restauração.
Onde os projetos falham na prática
Cada ponto abaixo é fácil de entender e difícil de manter funcionando, e é aqui que a maioria empaca.
A imutabilidade de verdade não é marcar uma caixa, e sim arquitetar o isolamento para que credenciais roubadas não consigam desligar a proteção. Os testes de restauração também enganam, porque restaurar um arquivo é bem diferente de restaurar a operação inteira dentro de um prazo, e sem simular você não conhece o seu tempo real de recuperação. A janela e a retenção pedem decisão consciente sobre quanto de dado você aceita perder e por quanto tempo guarda, já que errar isso custa caro nos dois sentidos. E a cobertura precisa de processo, porque o servidor novo, o dado que foi para a nuvem e o sistema que ninguém mapeou continuam desprotegidos até alguém incluir.
Um time consciente monta boa parte disso sozinho. O que costuma faltar não é a ferramenta, já que Veeam e similares resolvem bem, mas o desenho do isolamento, o teste periódico e a operação contínua que garantem que, no pior dia, a última linha de defesa esteja de pé.
O teste de um minuto
Responda honestamente às três perguntas a seguir. Se um ransomware criptografasse tudo hoje, incluindo o servidor de backup, você teria uma cópia intocável? Quando foi a última vez que alguém restaurou de verdade e cronometrou? Você sabe, em horas, o seu tempo de recuperação da operação inteira?
Se hesitou em qualquer uma, existe uma lacuna, e lacuna em backup só aparece na hora errada.
Fontes
- Veeam: a regra de backup 3-2-1 e a 3-2-1-1-0
- Veeam Backup & Replication: Hardened Repository
- Veeam Backup & Replication: Enabling Immutability em object storage
- Veeam Backup & Replication: How SureBackup Works
- CISA: #StopRansomware Guide
O próximo passo
A Lavineda é revenda Veeam, e você encontra mais sobre a plataforma na página da Veeam. Se quiser ver o backup dentro de um plano mais amplo de preparação, o nosso kit anti-ransomware percorre prevenção, resposta e recuperação.
Num diagnóstico gratuito revisamos a sua estratégia atual de backup e continuidade, apontamos por onde o ransomware entraria e mostramos o que falta para uma proteção real, sem compromisso.
Peça o seu diagnóstico gratuito e descubra o seu tempo real de recuperação antes que alguém o descubra por você.