A regra 3-2-1 do backup, explicada sem jargão — e o dígito que quase ninguém cumpre

A regra 3-2-1 cabe em uma linha: três cópias do dado, em duas mídias diferentes, com uma delas fora do local.

Traduzindo para o mundo real — se o prédio pegar fogo, se o servidor for roubado ou se um vírus criptografar tudo o que estiver conectado, ainda existe uma cópia intacta em outro lugar. É uma das poucas recomendações de segurança que atravessou duas décadas sem precisar ser reescrita, e é citada por praticamente todo fornecedor de TI do país.

O problema não é a regra. É que ela virou slogan. Todo mundo diz que segue; quase ninguém consegue mostrar.

Por que três cópias, e não duas

Porque a segunda cópia existe para o caso de a primeira falhar — e a terceira existe para o caso de a falha atingir as duas ao mesmo tempo.

Parece exagero até acontecer. O caso clássico é o backup que roda todo dia para uma pasta no mesmo servidor. O servidor é criptografado por ransomware, e a pasta de backup, que estava montada ali, vai junto. Havia duas cópias e zero cópias, ao mesmo tempo.

Por que duas mídias e não duas pastas

Porque mídia igual falha igual.

Dois discos do mesmo modelo, do mesmo lote, comprados no mesmo dia e ligados no mesmo equipamento envelhecem juntos, esquentam juntos e são atingidos pelo mesmo pico de energia. A separação de mídia existe para que a falha de uma não seja automaticamente a falha das duas.

Na prática de hoje, "duas mídias" costuma significar disco local mais armazenamento em objeto na nuvem, ou disco mais fita para quem tem volume alto e guarda longa. O que não conta como duas mídias é a mesma tecnologia duplicada no mesmo lugar.

E por que uma delas fora do local

Porque desastre é local por definição. Incêndio, alagamento, furto, interdição do prédio, queda de estrutura. Nenhuma dessas coisas respeita a divisão entre "o servidor" e "o backup do servidor" quando os dois estão na mesma sala.

Aqui cabe um esclarecimento que resolve metade das dúvidas: sincronizar arquivos com um serviço de nuvem não é a mesma coisa que ter cópia fora do local. Sincronização replica o que acontece — inclusive o apagamento e inclusive a criptografia do ransomware. Se o arquivo é destruído aqui, ele é destruído lá, em segundos. Backup é diferente: guarda versões anteriores, com prazo definido, e não é alterado pelo que acontece na origem.

A evolução: 3-2-1-1-0

Nos últimos anos a regra ganhou dois dígitos. São eles que separam quem faz backup de quem tem backup.

O primeiro 1 extra: uma cópia imutável

Imutável quer dizer protegida contra alteração e exclusão durante o prazo de guarda — inclusive por quem tem senha de administrador.

Esse detalhe final é o ponto inteiro. Ataque de ransomware moderno não começa criptografando: começa procurando o backup e apagando. E ele faz isso com credencial legítima, roubada de alguém da casa. Uma cópia comum, por melhor que seja a rotina, obedece a essa credencial. Uma cópia imutável, não — o próprio armazenamento recusa a ordem de apagar, venha ela de quem vier, até o prazo vencer.

É o cofre que nem o gerente do banco abre antes da hora. Não é uma configuração de conforto; é a diferença entre reabrir na terça e não reabrir.

E o zero, que é o que importa

O 0 significa zero erro na verificação: a cópia é restaurada em um ambiente separado e conferida. O sistema abre. Os dados estão lá. A data bate.

Sem esse passo, "backup concluído com sucesso" atesta uma coisa só — que a cópia foi gerada. Não que ela volta. E a distância entre as duas afirmações é onde moram os desastres.

Os motivos pelos quais uma cópia íntegra não restaura são banais e frequentes: falta a chave de criptografia, que ninguém guardou em outro lugar. Falta a licença do software que lê aquele formato. O backup do banco de dados foi feito com o serviço rodando, sem a rotina própria, e o arquivo é inconsistente. A rotina parou há três meses e o relatório de erro caía num e-mail que ninguém abre.

Nenhuma dessas causas aparece no painel. Todas aparecem no primeiro teste de restauração.

Com que frequência testar

A resposta útil não é uma frequência única, é uma proporção: quanto mais crítico o sistema, mais frequente o teste.

Para o que sustenta a operação — o sistema que, parado, faz a empresa parar — o teste de restauração faz sentido em ciclo curto e rotineiro, não anual. Para o resto, um teste completo por trimestre já muda o patamar da conversa.

E vale medir duas coisas em cada teste, porque são elas que respondem à pergunta do dono da empresa: de que ponto no tempo o dado volta (ou seja, quanto trabalho se perde) e quanto tempo a restauração leva (quanto tempo a empresa fica parada). Sem esses dois números, qualquer promessa de continuidade é chute.

Isso vale para empresa pequena?

Vale mais, e o motivo é desconfortável: empresa grande sobrevive a um mês ruim. Empresa de vinte pessoas, com o sistema de faturamento parado por uma semana, muitas vezes não.

O que muda com o porte é a escala, não o princípio. Três cópias, duas mídias, uma fora, uma imutável e uma restauração testada é uma descrição que cabe tanto num hospital quanto numa loja com duas filiais. O custo da versão pequena é bem menor do que a maioria das pessoas imagina — e infinitamente menor que o custo de descobrir o problema no dia errado.

Uma comparação que costuma resolver a conversa

Backup que ninguém testou é extintor que ninguém recarrega. Está na parede, tem lacre, dá a sensação de que a empresa está protegida — e você descobre que não funciona exatamente no dia em que precisa dele.

A pergunta que fecha o assunto numa reunião é sempre a mesma, e ela tem resposta com data: quando foi a última vez que alguém restaurou o backup desta empresa, e quanto tempo levou?

Se a resposta for "nunca testamos", é a mais comum que existe — e é a única que dá para mudar esta semana. Se quiser, a gente testa a restauração do seu backup atual e te diz em quanto tempo ele volta. Sem custo.