Backup e Recuperação

A estratégia de backup do Romeo garante que dados possam ser recuperados em qualquer cenário — desde exclusão acidental até desastre total no datacenter. É a última linha de defesa contra perda de dados.

Implementamos a regra 3-2-1: 3 cópias dos dados, em 2 tipos de mídia diferentes, com 1 cópia offsite. Isso garante resiliência contra falhas de hardware, software e desastres físicos.

Princípio fundamental

Backup que não foi testado não é backup — é esperança. Realizamos testes de recuperação mensalmente e simulação completa de DR trimestralmente.

A regra 3-2-1 é o padrão da indústria para proteção de dados. O Romeo implementa essa estratégia em todos os níveis.

Os 3 componentes

Implementação no Romeo

Criptografia: Todos os backups são criptografados em repouso (AES-256) e em trânsito (TLS 1.3). Chaves gerenciadas via AWS KMS.

RTO (Recovery Time Objective) e RPO (Recovery Point Objective) são as métricas fundamentais de continuidade de negócio.

Definições

RTO por cenário

RPO por tipo de dado

Trade-off custo vs. RPO

RPO menor = mais custo (réplica síncrona, WAL contínuo). Priorizamos dados financeiros (RPO=0) e aceitamos RPO maior para dados regeneráveis.

O Romeo utiliza múltiplos tipos de backup para diferentes necessidades de recuperação.

Backup de banco de dados

Backup de arquivos

Backup de aplicação

Versionamento S3: Todos os buckets têm versionamento ativado. Mesmo exclusões são recuperáveis por 30 dias via versões anteriores.

Cada tipo de falha tem um procedimento de recuperação documentado e testado. Os runbooks estão acessíveis a todo o time de SRE.

Níveis de recuperação

Point-in-time recovery (PITR)

Para recuperação de um momento específico (ex: "como estava às 14:32"):

1. Identificar timestamp alvo (UTC)
2. Criar nova instância RDS com PITR para esse timestamp
3. Validar dados na nova instância (ambiente isolado)
4. Extrair dados necessários ou promover como nova produção
5. Documentar incidente e atualizar runbook se necessário

Recuperação de arquivo específico

Ambiente de teste

Toda recuperação é feita primeiro em ambiente isolado. Dados só são movidos para produção após validação completa.

Testes regulares garantem que os backups funcionam quando precisamos. Backup não testado é apenas ocupação de disco.

Calendário de testes

Teste automatizado semanal

Métricas de teste

Documentação: Cada teste gera relatório arquivado por 2 anos. Útil para auditorias e para demonstrar maturidade de DR a clientes.

O plano de DR cobre cenários onde o datacenter primário fica totalmente indisponível. O objetivo é restaurar operações em região secundária.

Cenários cobertos

Arquitetura multi-região

Procedimento de failover

1. Declaração de desastre (decisão do CTO ou SRE Lead)
2. Ativar infraestrutura em us-east-1 (Terraform apply)
3. Restaurar banco do último backup replicado
4. Atualizar DNS (Route53 health check ou manual)
5. Validar funcionalidades críticas (smoke tests)
6. Comunicar clientes sobre migração e possível perda de dados
7. Monitorar estabilidade por 24h antes de considerar recuperação completa

Comunicação durante DR

Simulação trimestral

A cada trimestre simulamos um cenário de DR completo: declaramos desastre fictício, ativamos região secundária, e operamos por 4 horas antes de reverter. Isso garante que o time sabe o que fazer quando for real.