Disaster Recovery (Recuperação de Desastres e Backups)

1. Visão geral da conceção e problema sistémico

Na engenharia de infraestrutura, falhas de hardware em SSDs, incidentes em datacenters de provedores, ransomware e erros humanos (DROP DATABASE production, um rm -rf acidental) não são uma questão de "se", mas sim de "quando".

A maioria das equipes vive na ilusão de segurança: adicionam uma linha no crontab para criar um dump diário e consideram o problema resolvido. Quando ocorre uma catástrofe real, descobre-se que:

• O último backup falhou há três meses devido ao disco cheio.
• O dump contém dados binários corrompidos.
• A restauração de um banco de dados de 100 GB leva 36 horas, paralisando o negócio (RTO inaceitável).
• O atacante, após comprometer o servidor, excluiu os backups junto com a base de produção, pois a chave API do S3 tinha permissões totais de exclusão (s3:DeleteObject).

Disaster Recovery (Recuperação de Desastres) é uma estratégia abrangente de continuidade de negócios. Não se trata apenas de salvar arquivos, mas de estabelecer metas RTO/RPO matematicamente calculadas, utilizar armazenamento imutável (Immutable Storage) e realizar treinamentos automatizados e recorrentes de implantação da infraestrutura do zero.

2. Taxonomia arquitetural e modelo mental

A matriz arquitetural de Disaster Recovery baseia-se no trade-off entre velocidade e frequência de captura de estado:

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIA DE RECUPERAÇÃO DE DESASTRES       │
├─────────────────────────────────────────────────────────────┤
│ 1. Recuperação em Ponto no Tempo (PITR) ➔ RPO ~ segundos    │
│    • Streaming de logs WAL (Write-Ahead Log) em tempo real   │
│    • Ferramentas: Litestream (para SQLite), pgBackRest (PG)  │
├─────────────────────────────────────────────────────────────┤
│ 2. Snapshots Deduplicados e Criptografados ➔ RPO ~ horas    │
│    • Snapshots atômicos de dados via Restic, BorgBackup, Kopia│
│    • Criptografia no lado do cliente AES-256 / ChaCha20      │
├─────────────────────────────────────────────────────────────┤
│ 3. Camada de Armazenamento Imutável Offsite (Anti-Ransomware)│
│    • S3 Object Lock (WORM - Write Once, Read Many)           │
│    • Armazenamentos geograficamente isolados (Cloudflare R2, AWS S3) │
├─────────────────────────────────────────────────────────────┤
│ 4. Standby Frio & Simulado Automatizado de Recuperação (Validação de RTO) │
└─────────────────────────────────────────────────────────────┘

1. Point-In-Time Recovery (PITR):
   • Em vez de um único dump pesado diário, o banco de dados transmite continuamente seu log binário de alterações (WAL) para a nuvem. Isso permite "rebobinar" o estado do banco para o segundo exato anterior à falha ou a uma consulta errônea do desenvolvedor (RPO < 10 segundos).
2. Snapshots incrementais deduplicados (Content-Addressed Snapshots):
   • Utilitários como Restic dividem os arquivos em blocos criptográficos. Se apenas 1% de um banco de dados de 50 GB mudou, somente os novos blocos são enviados, economizando até 95% de espaço em disco e tráfego de rede.
3. Armazenamento Imutável (Immutable WORM Storage):
   • Política de segurança S3 Object Lock, pela qual ninguém (nem mesmo um administrador com acesso root) pode excluir ou sobrescrever um arquivo criado durante um período definido (por exemplo, 30 dias).
4. Treinamentos de Recuperação (Recovery Drills):
   • Processo automático regular no CI que baixa o último arquivo, implanta-o em um container isolado, executa consultas SQL de verificação e confirma a integridade dos dados.

3. Pipeline técnico e mecânica interna

O ciclo de vida de um backup confiável com deduplicação e criptografia:

1. Congelamento consistente do estado (Snapshot Lock): O banco de dados entra em modo de preparação para cópia ou cria-se um snapshot transacional através dos mecanismos COW (Copy-on-Write) do sistema de arquivos ZFS/Btrfs.
2. Criptografia client-side no host: Antes do envio pela rede, os dados são criptografados com um algoritmo robusto (AES-256-GCM) usando uma passphrase conhecida apenas pelo engenheiro. O provedor de hosting S3 recebe exclusivamente ruído binário criptografado.
3. Upload paralelo para armazenamento em nuvem isolado: Os blocos são transmitidos via HTTPS para uma região geográfica independente (por exemplo, um servidor na Alemanha faz backup para um bucket Cloudflare R2 na Suécia).
4. Aplicação de política de rotação (GFS Retention Policy): O algoritmo mantém: as últimas 24 cópias horárias, 7 diárias, 4 semanais e 12 mensais (Grandfather-Father-Son), excluindo automaticamente snapshots intermediários antigos.
5. Verificação automática de integridade (Automated Integrity Check): Uma tarefa separada em background semanalmente executa o comando restic check --read-data-subset=5%, detectando possível degradação de bits (Bit Rot) no armazenamento.

4. Cenários práticos de engenharia em produção

01. Replicação contínua de SQLite usando Litestream

Para aplicações baseadas em SQLite/Turso:

• O Litestream opera como um processo de sistema em background, interceptando mudanças no arquivo WAL.
• A cada 10 segundos, novos frames são criptografados e enviados para o bucket Cloudflare R2.
• Em caso de perda total do servidor, uma nova máquina sobe com um único comando litestream restore -o /var/data/app.db, recuperando o estado do sistema praticamente sem perda de dados (RPO < 10 s, RTO < 60 s).

02. Proteção contra atacantes via S3 Object Lock

Prevenção contra destruição de infraestrutura por hackers:

• Mesmo que o atacante obtenha acesso root completo ao servidor e encontre a configuração com as chaves AWS_ACCESS_KEY_ID, a tentativa de executar aws s3 rm --recursive é bloqueada pela política AWS Compliance Lock no nível do datacenter Amazon.
• A empresa garante acesso aos backups imutáveis.

03. Plano de recuperação de standby frio via Terraform (IaC Standby)

Incidente nível OVH (incêndio no centro de processamento de dados em Estrasburgo):

• O servidor principal torna-se fisicamente inacessível.
• O engenheiro dispara o pipeline de CI: o Terraform provisiona uma nova instância na Hetzner em 3 minutos, o Ansible aplica a configuração base, um script baixa o último backup Restic e os registros DNS da Cloudflare apontam para o novo IP em 60 segundos.

5. Armadilhas comuns, erros típicos e segurança

• Armazenar a senha de descriptografia junto ao backup: Se a senha do repositório Restic for salva em um arquivo aberto /root/.backup_pass, a comprometimento do servidor abre simultaneamente acesso de leitura a toda a base de clientes nos backups.
• Tentar copiar arquivos de bancos ativos sem locks (Dirty Reads): Copiar simplesmente o diretório de dados do PostgreSQL (cp -r /var/lib/postgresql) durante consultas ativas gera um estado binário inconsistente (Torn Pages), impossível de iniciar após a restauração.
• Falta de memória/espaço para descompressão do dump: Se o novo servidor tiver um disco menor que o tamanho do banco de dados descompactado, o procedimento de restauração falhará no meio do processo com erro de falta de espaço em disco (No space left on device).
• Ignorar arquivos de configuração e variáveis de ambiente: Fazer backup apenas do banco de dados, sem preservar configurações do Nginx, certificados SSL e arquivos .env, aumenta o RTO de 15 minutos para vários dias de reconstrução manual das configurações.