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.

Neste artigo, vamos falar sobre a regra 3-2-1-1-0: quantas cópias manter, como distribuir essas cópias e por que simplesmente armazená-las não é suficiente. O último número da regra não representa mais um local de armazenamento. Ele representa algo ainda mais importante: zero erros no restore.

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

O job de backup pode estar verde. Isso só afirma que o processo terminou sem erro. Não afirma que o dado está inteiro, consistente ou restaurável. Quem trata o check verde como recuperação descobre o contrário no dia em que precisa do restore.

A regra 3-2-1-1-0 existe para essa distinção. Os quatro primeiros números desenham a topologia da cópia. O zero exige que essa topologia tenha sido exercitada.

  • 3 cópias além do original
  • 2 atravessando um limite lógico (outra conta ou outra região)
  • 1 num cofre imutável
  • 1 local, para o restore operacional
  • 0 erro depois de testar o backup e verificar se ele recupera

Estratégias de proteção do backup: 3 cópias além do original, 2 em contas ou regiões diferentes, 1 em cofre imutável, 1 local para restore operacional, e 0 erro depois de testar o restore.

O que os quatro primeiros números realmente compram

Três cópias além do original não são vaidade. Snapshot na mesma conta, na mesma região, no mesmo IAM, é uma cópia só com nomes diferentes. Um erro de retenção, uma policy larga demais ou uma identidade comprometida alcança as três de uma vez. A segunda e a terceira cópia só existem se falharem por motivos distintos.

Dois limites lógicos servem a isso. Outra conta AWS não compartilha o mesmo conjunto de roles. Outra região não compartilha o mesmo blast radius de uma AZ ou de um controle regional. Se produção e backup autenticam no mesmo IdP, com o mesmo admin, o desenho mente: o limite é cosmético.

O cofre imutável fecha o buraco que o isolamento sozinho não fecha. Isolamento impede o caminho fácil. Imutabilidade impede o delete, mesmo quando o caminho aparece. Quem já leu incidente de ransomware sabe o padrão: a produção cai e, em seguida, some o repositório de backup. Sem Vault Lock (ou equivalente) em modo que o próprio operador não desliga no susto, a cópia é um alvo, não um plano.

A cópia local é o outro extremo. Cofre isolado e imutável protege contra o pior dia. Não é, necessariamente, o caminho mais rápido numa terça comum: um volume corrompido, uma tabela dropada, um objeto sobrescrito. Restore operacional precisa de uma cópia que se abra sem montar um exercício entre contas. Sem ela, o time ou viola o cofre a cada incidente pequeno, ou deixa o incidente pequeno virar grande.

Isso é engenharia de falha, não poster. Ainda assim é incompleto.

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 job de backup está verde. O restore falhou. Cópia não é recuperação.

A pergunta que o dashboard não faz

“Temos backup?” é a pergunta errada. Quase todo mundo tem.

A pergunta certa é mais estreita e mais honesta: quando o último restore foi feito de propósito, por alguém que não estava em pânico, contra um destino real, e o resultado foi um sistema usável?

Se a resposta for o dashboard, vocês têm cópia. Talvez tenham o 3, o 2 e os dois 1.

Falta o zero.