Estratégia 3-2-1 para Bancos

A regra 3-2-1 é o padrão clássico de proteção de dados: manter três cópias dos dados, em duas mídias ou plataformas diferentes, com uma cópia fora da região ou do site principal. Aplicada a bancos de dados, a regra deixa de ser slogan e vira desenho concreto: o primário é a primeira cópia, o backup automatizado com PITR é a segunda, e a cópia cross-region em conta separada é a terceira. A força da regra está no princípio de independência entre cópias: cada camada deve falhar por razões diferentes, em domínios de falha diferentes, senão as três cópias morrem juntas no mesmo desastre. Em produção, a 3-2-1 não é um ritual de compliance, é a resposta estruturada às perguntas de quanto se perde (RPO) e quanto tempo leva para voltar (RTO), organizadas por camada de proteção. O elemento que separa estratégias reais de desenhos de papel é o teste de restore, tratado aqui como parte integral da regra, e não como atividade opcional.

Conceito e as três regras

Três cópias significa que os dados vivem em pelo menos três instâncias independentes, e o número não é arbitrária: uma cópia é a fonte de produção viva, sujeita a falha a qualquer momento; a segunda é a proteção de rotina; a terceira é a proteção contra desastres que alcançam as duas primeiras.

Duas mídias significa diversidade de mecanismo de armazenamento, e não apenas dois discos. Em nuvem, a interpretação moderna é diversidade de plataforma e de camada: storage de blocos para o banco primário, object storage (S3, GCS, Blob) para os arquivos de backup, e storage gerenciado da região secundária para a cópia de DR. Um erro de storage afeta uma mídia, não todas.

Uma cópia fora do site, em leitura atualizada da prática cloud native, significa fora do domínio de falha principal: outra região, outra conta, ou ambos. O domínio de falha de um banco na região sa-east-1 da conta de produção inclui essa região e essa conta; a cópia fora dele sobrevive a um desastre que apague qualquer coisa dentro.

A regra geral funciona para bancos de dados com uma ressalva estrutural: cópias de banco só são úteis se forem consistentes e restauráveis. Três cópias inconsistentes valem menos que duas boas, e por isso a consistência de captura (flush, quiesce, mecanismos do próprio banco) é pré-condição da regra, não detalhe.

A variação moderna 3-2-1-1-0 acrescenta dois números que valem leitura: uma cópia adicional imutável ou offline, proteção final contra ransomware, e zero erros na verificação de restore. O adicional de imutabilidade hoje costuma ser object storage com retenção de objeto (Object Lock do S3) ou cópia cross-account sem permissão de deleção. O zero traduz a filosofia deste arquivo: a contagem de cópias não é métrica de sucesso, o restore verificado sem erros é.

Aplicação a bancos em nuvem

Em nuvem, cada camada da regra mapeia para um mecanismo específico. O desenho a seguir é o padrão comum para um banco PostgreSQL de produção, adaptável a qualquer engine.

O primário com Multi-AZ protege contra falha de instância e de zona; o PITR protege contra erro lógico e contra falha do storage do primário; a cópia cross-region em conta separada protege contra desastre regional e contra comprometimento administrativo da conta. Cada camada existe porque as camadas anteriores têm vetores de falha que não cobrem.

Em self-hosted sobre nuvem ou datacenter próprio, o mesmo desenho usa snapshots de storage ou pg_basebackup na segunda camada e replicação física ou cópia de WAL para um segundo site na terceira. A essência é idêntica: rotina, granularidade fina e isolamento geográfico administrativo.

Uma adaptação relevante para bases grandes: a terceira cópia pode ser uma réplica cross-region em vez de cópia estática, reduzindo o RPO de DR para segundos ao custo de custo de instância contínuo. A decisão entre réplica viva e cópia fria é puramente a troca RTO e RPO versus custo, e ambos os desenhos cumprem a 3-2-1.

O isolamento de conta é o detalhe que mais se esquece na implementação em nuvem. A conta é o perímetro administrativo real: um papel IAM com permissão ampla, um token vazado ou uma automação desgovernada deletam snapshots na mesma conta com a mesma facilidade com que deletam volumes. A cópia cross-account com política de bucket que nega deleção fora de papéis específicos, mantida em conta administrativa separada com MFA obrigatório, é o desenho que sobrevive ao comprometimento da conta de produção.

A própria AWS Backup materializa a 3-2-1 como recurso first-class: backup plans definem cronograma e lifecycle por camada, backup vault guarda as cópias com vault lock de imutabilidade, e vaults cross-account compartilham cópias com contas de destino. O plano declarativo abaixo ilustra o mapeamento direto da regra em configuração.

# AWS Backup: plano declarativo que materializa a 3-2-1
backupPlan:
  name: estrategia-321-postgres-producao
  rules:
    - ruleName: rotina-diaria              # camada 2, backup contínuo local
      targetBackupVault: vault-producao
      scheduleExpression: "cron(0 4 * * ? *)"
      lifecycle:
        deleteAfterDays: 14                # retenção curta na camada quente
    - ruleName: copia-remota               # camada 3, fora da região e da conta
      targetBackupVault: vault-dr-conta-admin
      copyActions:
        - destinationBackupVaultArn: arn:aws:backup:us-east-1:999999999999:backup-vault:vault-dr-conta-admin
      lifecycle:
        deleteAfterDays: 90                # retenção longa na camada fria
        moveToColdStorageAfterDays: 35
  selection:
    resources:
      - arn:aws:rds:sa-east-1:111111111111:db:producao-app

RPO e RTO por camada

RPO e RTO não são números únicos de um sistema, são números por camada e por cenário. A tabela abaixo organiza a expectativa realista por tipo de incidente, que é a forma de pensar que sustenta decisões de investimento em DR.

A leitura estratégica da tabela: quanto mais grave o desastre, mais camadas saltam e pior ficam RPO e RTO. Por isso a cópia remota precisa de ciclo de atualização compatível com o RPO de DR contratado, e um ciclo de 24 horas não sustenta uma promessa de perder no máximo 1 hora em desastre regional.

O RTO da camada de PITR merece atenção específica: restaurar base + replay de 14 dias de WAL pode levar horas em bases com alta taxa de escritas. Quando o RTO de erro lógico exigido é menor, a resposta é aumentar a frequência de snapshots (encurtar o replay) ou manter réplica com delay intencional, que restaura para minutos atrás em minutos.

Testes de restore como parte da estratégia

Backup sem teste de restore é apenas dados duplicados com custo. O teste valida três coisas que nenhuma configuração garante por si: os arquivos existem e estão íntegros, o processo de restauração funciona do início ao fim, e o tempo real cabe no RTO prometido.

O formato de teste de produção é o game day automatizado: periodicamente (semanal ou mensal), a automação restaura o backup mais recente em ambiente isolado, aplica checagens de integridade de negócio (contagens, somas, registros de referência), mede o tempo total e destrói o ambiente. O resultado entra em métrica e em relatório, com alerta quando o teste falha ou o tempo degrada.

# Teste automatizado de restore, roteiro essencial de game day
# 1. Restaura o snapshot mais recente em ambiente efemero
SNAP=$(aws ec2 describe-snapshots \
  --owner-ids self --filters "Name=tag:camada,Values=remota" \
  --query 'max_by(Snapshots,&StartTime).SnapshotId' --output text)
aws ec2 create-volume --snapshot-id "$SNAP" \
  --availability-zone us-east-1a --volume-type gp3

# 2. Sobe a instancia efemera com o banco, apontando para o volume novo
terraform apply -var="env=restore-test" -auto-approve

# 3. Checagens de integridade de negocio, falham o teste se divergirem
psql -h endpoint-teste -c "SELECT count(*) FROM pedidos;"
psql -h endpoint-teste -c "SELECT max(created_at) FROM transacoes;"
./scripts/validar_integridade.sh --min-pedidos=1000000

# 4. Registra o tempo total e destrói o ambiente de teste
echo "RTO medido: $SECONDS s" >> metrics/restore_test.log
terraform destroy -var="env=restore-test" -auto-approve

A frequência dos testes escala com a criticidade: bancos de pagamento testam restauração semanal, sistemas internos mensais. O que não pode existir é banco crítico sem teste de restore no histórico dos últimos 90 dias, pois essa é a primeira pergunta de qualquer auditoria séria.

O resultado do teste precisa retornar ao desenho da estratégia. Um RTO medido três vezes acima da meta força decisão: redefinir a meta, aumentar a frequência de snapshots, investir em réplica de DR ou reavaliar o tamanho do banco. Tratar o número do teste como insumo de decisão arquitetural, e não como comprovante de auditoria, é a diferença entre a 3-2-1 viva e a 3-2-1 documental.

Automação e auditoria de backups

A 3-2-1 operada manualmente degrada em semanas: janelas esquecidas, cópias que falham silenciosamente e retenções inconsistentes entre camadas. A automação e a auditoria são o que mantém a estratégia viva ao longo do tempo.

• Captura e cópia automatizadas por política declarativa: Data Lifecycle Manager no EBS, backup plans do AWS Backup, políticas do snapshot manager; a regra vive em IaC e o desvio é visível em diff.
• Monitoramento de sucesso de cada job da cadeia: captura, arquivamento de WAL, cópia cross-region e teste de restore; cada elo precisa de alarme, e a ausência de sucesso em 24 horas é alerta.
• Guardrails de retenção: regras que impedem deleção dentro da janela mínima (retention lock, vault lock, políticas SCP que negam delete de snapshot etiquetado como protegido).
• Inventário auditável: lista automática de bancos, suas camadas de backup, última captura verificada e último teste de restore; o relatório alimenta auditoria e é gerado por consulta, não por planilha.
• Orçamento e alerta de custo por camada: cópias remotas e retenções longas são os multiplicadores típicos, e a fatura de backup deve ser rastreável por tag de camada.

A auditoria pergunta que a estratégia precisa responder sem esforço: para cada banco de produção, quais são as três cópias, quando cada uma foi capturada, onde vivem, quanto custam e quando foi o último restore testado. Se essa resposta depende de investigação manual, a automação ainda não existe de verdade.

Erros comuns e boas práticas

• Contar réplicas como backup: replicação propaga DELETE tão rápido quanto propaga UPDATE legítimo; camada de backup exige retenção temporal, não apenas outro nó.
• Três cópias no mesmo domínio de falha: dois backups na mesma conta, região e plataforma são uma cópia do ponto de vista de desastre; auditar independência real entre camadas.
• Prometer RPO de DR sem calcular o ciclo de cópia: uma cópia cross-region diária significa até 24 horas de perda em desastre regional; alinhar ciclo de cópia com a promessa.
• Ignorar a restauração do contexto: dados voltam, mas parameter groups, segredos, usuários e DNS precisam de runbook; testar o restore completo, incluindo a aplicação reconectando.
• Não criptografar nem isolar credenciais das cópias remotas; backup é cópia do dado mais sensível da empresa, e a camada remota precisa do mesmo (ou maior) rigor de acesso.
• Deixar o teste de restore ser evento de projeto, não rotina; game day periódico automatizado é o que mantém a capacidade real contra a deriva natural de configuração.
• Medir só a captura e reportar sucesso verde; a métrica que importa é o último restore testado com sucesso, e o dashboard de backup deve colocar esse número em primeiro lugar.