A regra de backup 3-2-1-1-0. Tínhamos tudo, menos o zero

Backup parece simples até o dia em que você precisa dele.

Em termos simples, fazer backup significa criar uma cópia dos seus dados para que eles possam ser recuperados caso o original seja perdido, corrompido ou apagado.

Mas existe uma diferença importante entre ter um backup e conseguir recuperar seus dados a partir dele.

Imagine que todos os dias um processo automatizado execute o backup do seu banco de dados. No final, o sistema mostra um grande sinal verde: o processo terminou sem erros.

Você pode pensar: "está tudo protegido".

Mas o que esse sinal verde realmente significa?

Apenas que o processo conseguiu executar as etapas previstas. Ele não garante, sozinho, que a cópia esteja íntegra, que os dados estejam consistentes ou que seja possível recuperá-los quando você realmente precisar.

É aqui que entra a regra 3-2-1-1-0.

Ela é uma estratégia para reduzir o risco de perder os dados mesmo quando alguma coisa dá errado. Os números representam como as cópias devem ser mantidas e protegidas:

• 3 cópias dos dados
• 2 tipos diferentes de mídia ou armazenamento
• 1 cópia mantida fora do ambiente principal
• 1 cópia isolada ou imutável
• 0 erros durante o teste de recuperação

O último número é o mais interessante.

O zero não representa mais uma cópia ou outro lugar para armazenar seus backups. Ele representa uma exigência: quando chegar a hora de recuperar os dados, o restore precisa funcionar.

Porque backup que nunca foi restaurado é, até certo ponto, uma hipótese.

A cena abaixo é o ponto de partida para entender essa conta e, principalmente, a lógica por trás de cada número.

O que falha quando falta um número

A regra só vale se cada número segura uma falha diferente. Se dois números quebram do mesmo jeito, você não tem cinco controles. Tem repetição.

Sem o 3, produção e “backup” moram no mesmo destino. Um erro de retenção, uma policy larga ou uma identidade comprometida apaga o original e as cópias juntas. Três nomes no mesmo lugar não são três cópias.

Sem o 2, as cópias usam o mesmo tipo de mídia ou o mesmo serviço de armazenamento. A falha se repete: corrupção, quota, API, região. Dois discos iguais, na mesma conta, falham do mesmo jeito.

Sem o 1 fora do ambiente principal, o incidente do ambiente leva o backup junto. Conta comprometida, IdP único, região indisponível. A cópia precisa estar onde esse incidente não alcança.

Sem o 1 isolado ou imutável, quem chegou na produção também chega no delete do backup. Isolamento corta o caminho fácil. Imutabilidade impede o delete mesmo quando o caminho aparece. Ransomware que mira produção costuma mirar o repositório de backup em seguida. Sem essa trava, a via de volta some com o original.

Sem o 0, o job está verde e a caixa não abre. Os quatro primeiros números respondem onde a cópia está. O zero responde se ela volta.

Isso é engenharia de falha, não poster. Ainda assim é incompleto enquanto o restore não for exercitado.

O job verde mente por omissão

Um job de backup bem-sucedido responde a uma pergunta estreita: o writer conseguiu persistir o que foi pedido, no destino configurado, dentro da janela. Ele não responde se a cadeia incremental está íntegra. Não responde se o banco foi capturado em estado aplicável (com flush, com snapshot consistente, com backup nativo), ou só como um disco no meio de um write. Não responde se a chave KMS do restore ainda existe, se a identity que restaura tem permissão no cofre, se o engine de destino aceita aquela versão, se o tempo de volta cabe no que o negócio chama de aceitável.

Integridade é o backup estar completo e coerente. Disponibilidade é conseguir acessá-lo e aplicá-lo. Nenhuma das duas é o exit code do job.

Por isso o zero não é quantidade. Não é “mais um vault”. É o critério de aceite: restaurar de propósito, ver o dado voltar, medir quanto tempo levou, e só então chamar o desenho de 3-2-1-1-0. Teste do job. Teste da recuperabilidade. Os dois. Um sem o outro deixa um check verde em cima de uma caixa que não abre.

O que o teste de recuperação precisa mostrar

O zero não pede um laboratório. Pede quatro respostas, obtidas de propósito, sem pânico:

• o dado voltou?
• voltou consistente, num estado que a aplicação aceita?
• alguém do time conseguiu fazer o restore sem improvisar permissão, chave ou destino?
• o tempo de volta cabe no que o negócio aguenta?

Se alguma resposta for “o job estava verde”, o teste ainda não aconteceu. Dashboard mede o writer. Recuperação mede o caminho de volta.

O backup funciona quando você precisa dele?

"Temos backup?"

Essa parece ser a pergunta certa. Mas, na prática, ela diz pouco. A maioria dos ambientes consegue responder que sim.

A pergunta que realmente importa é outra:

Quando foi a última vez que alguém restaurou esse backup de propósito, em um ambiente real, e confirmou que o sistema voltou a funcionar?

Um dashboard pode mostrar que o backup terminou com sucesso. Pode mostrar que a cópia existe, que o armazenamento está saudável e que o último job foi concluído sem erros.

Mas nenhum desses indicadores responde se você consegue recuperar o sistema quando realmente precisar.

Se a única evidência de que o backup funciona é um dashboard verde, você sabe que tem uma cópia. Talvez já tenha o 3, o 2 e os dois 1.

Mas ainda falta o zero.

O zero é a prova de que o caminho de volta funciona.