Disaster Recovery em Cloud: Lições do Incêndio no Data Center Coreano

Em 15 de outubro de 2022, um incêndio no data center da SK C&C em Bundang, Coreia do Sul, destruiu servidores que mantinham serviços críticos como Melon e Kakao offline por 3 a 5 dias. As perdas econômicas ultrapassaram 100 milhões de dólares. A causa técnica? Falha no sistema de supressão de incêndio combinada com algo ainda mais crítico: muitas empresas mantinham seus backups na mesma zona de disponibilidade dos dados primários.

Quando o sistema de backup está sujeito ao mesmo ponto de falha que o sistema primário, você não tem backup de verdade – você tem uma ilusão de segurança. Este artigo explora as estratégias práticas de disaster recovery que emergem dessa lição cara, com foco nos trade-offs reais entre custo, complexidade e resiliência.

Anatomia de Uma Falha Sistêmica

Alta disponibilidade protege contra falhas de componentes individuais – um servidor, um switch, até uma zona inteira dentro de uma região. Disaster recovery protege contra eventos que comprometem uma região geográfica completa: incêndios, inundações, terremotos, ou até ataques coordenados. Não é apenas semântica.

O problema fundamental do incidente SK C&C foi confundir esses dois conceitos. Redundância dentro da mesma localização geográfica protege contra falhas de hardware, mas não contra desastres físicos. A AWS documenta explicitamente essa distinção: suas 33 regiões geográficas existem especificamente para disaster recovery, enquanto zonas de disponibilidade dentro de uma região servem para alta disponibilidade.

Durante o outage da AWS US-EAST-1 em dezembro de 2021, serviços como Netflix, Disney+ e Robinhood ficaram offline por mais de 7 horas. Empresas que mantinham infraestrutura apenas nessa região sofreram downtime completo, mesmo com múltiplas zonas de disponibilidade configuradas. A falha afetou a região inteira, não apenas uma zona.

Estratégias Multi-Região: Trade-offs Entre RTO, RPO e Custo

Recovery Time Objective (RTO) e Recovery Point Objective (RPO) definem os limites aceitáveis de downtime e perda de dados, respectivamente. A estratégia de DR que você escolhe depende diretamente desses números – e cada uma tem custos operacionais drasticamente diferentes.

Replicação Síncrona vs Assíncrona

GCP Cloud Spanner oferece RPO = 0 (zero data loss) com replicação síncrona multi-região e RTO menor que 10 segundos para failover automático. O custo dessa garantia? Latência adicional de 50-200ms em cada operação de escrita, porque o sistema precisa confirmar que os dados foram gravados em múltiplas regiões antes de considerar a transação completa.

AWS S3 Cross-Region Replication usa replicação assíncrona: RPO de aproximadamente 15 minutos, mas sem impacto perceptível na latência de escrita. Para dados que não exigem consistência imediata – logs, backups, dados analíticos – a replicação assíncrona oferece melhor custo-benefício.

Azure SQL Database com geo-replication encontra um meio termo: RPO menor que 5 segundos e RTO menor que 30 segundos, adequado para aplicações transacionais que toleram perda mínima de dados mas precisam de latência controlada.

A escolha não é puramente técnica. Netflix investe mais de 1 milhão de dólares por mês em redundância para atingir 99.99% de disponibilidade. Esse investimento permite que eles evacúem uma região inteira em menos de 40 minutos usando técnicas de Chaos Engineering desenvolvidas desde 2011. Para muitas empresas, 99.9% de disponibilidade (cerca de 8 horas de downtime por ano) é mais econômico que 99.99% (apenas 52 minutos).

Custos de Transferência e Armazenamento

Deployments multi-região aumentam custos em 2 a 3 vezes comparados com single-region. Parte disso vem de transferência de dados inter-região: AWS cobra $0.02/GB, Azure aproximadamente $0.02/GB, GCP cerca de $0.01/GB. Para aplicações que processam terabytes diariamente, esses custos se acumulam rapidamente.

AWS S3 Glacier oferece 99.999999999% (11 noves) de durabilidade para retenção de longo prazo a custos significativamente menores que S3 padrão. A estratégia recomendada combina retenção operacional de 30 dias em armazenamento de alta performance com retenção regulatória de 7 anos em storage classes mais econômicas.

A Evolução da Regra 3-2-1 e a Importância de Testes

A tradicional regra 3-2-1 de backup – 3 cópias dos dados, 2 tipos de mídia, 1 cópia offsite – evoluiu. A versão moderna é 3-2-1-1-0: adiciona 1 cópia offline (air-gapped, protegida contra ransomware) e 0 erros na verificação dos backups.

Esse último número é crítico. Segundo o Veeam 2024 Data Protection Report, 54% das empresas nunca testaram seus backups. Isso explica por que 21% das organizações que sofreram ataques de ransomware (85% das empresas reportaram pelo menos um ataque) não conseguiram recuperar seus dados mesmo tendo backups configurados.

O caso GitLab de 2017 ilustra essa falha. Uma deleção acidental no banco de dados primário deveria ser recuperável através do backup secundário. Descobriram durante o incidente que o backup secundário estava falhando há semanas sem alertas apropriados. Resultado: perda de 6 horas de dados de produção.

Replicação Não Protege Contra Corrupção Lógica

A documentação oficial da AWS, Azure e GCP é clara sobre uma limitação frequentemente ignorada: replicação cross-region não protege contra corrupção lógica ou ransomware. Se um atacante deleta dados ou um bug corrompe registros no banco primário, essa corrupção é replicada fielmente para todas as regiões secundárias em minutos.

Snapshots imutáveis – backups que não podem ser modificados ou deletados por um período definido – são essenciais. AWS Backup Vault Lock e Azure Immutable Blob Storage implementam essa proteção, mas exigem configuração explícita. Por padrão, a maioria dos sistemas de replicação assume que os dados primários estão corretos.

Spotify migrou para uma estratégia multi-cloud após incidentes recorrentes: GCP como primário com AWS como backup. A diversificação não é apenas geográfica, mas também de plataforma, reduzindo risco de vulnerabilidades específicas de um provider.

Infrastructure as Code: Backup Além dos Dados

A recuperação de desastres não envolve apenas dados. Durante o incidente SK C&C, as empresas afetadas precisaram reconstruir infraestrutura inteira em novos data centers. Servidores, configurações de rede, regras de firewall, políticas de acesso – tudo precisava ser recriado do zero.

Infrastructure as Code (IaC) transforma configuração de infraestrutura em artefatos versionados e testáveis. Terraform, CloudFormation, Pulumi – todas essas ferramentas permitem recriar ambientes completos executando código. Mas o estado desses sistemas (o arquivo terraform.tfstate, por exemplo) pode ser tão crítico quanto os dados da aplicação. Perda do state file pode tornar impossível gerenciar infraestrutura existente ou criar novos recursos sem conflitos.

A comunidade GitHub documenta casos onde perda do state management causou tanto problema quanto perda de dados. A solução é tratar state files como dados críticos: replicação multi-região, versionamento, backups regulares com testes de recuperação.

AWS Aurora Global Database oferece um exemplo de integração entre dados e infraestrutura. O RTO típico de 1-4 horas para failover multi-região inclui não apenas replicação de dados, mas também promoção automática de réplica secundária a primária, reconfigurações de DNS e ajustes de segurança. Tudo isso é codificável e testável.

Implementando Testes de Disaster Recovery

Netflix testa disaster recovery continuamente através de Chaos Engineering. O princípio é simples: cause falhas intencionais em produção para validar que os sistemas de recuperação funcionam. Eles desligam servidores aleatoriamente, simulam latência de rede, e até evacuam regiões inteiras da AWS durante horário comercial.

Essa abordagem exige maturidade organizacional significativa. A alternativa mais acessível? Game days: exercícios programados onde equipes simulam cenários de desastre em ambientes controlados. Azure Site Recovery documenta RTO menor que 2 horas e RPO menor que 15 minutos, mas esses números só são atingíveis se as equipes praticarem regularmente os procedimentos de failover.

GCP recomenda RPO menor que 1 hora para aplicações tier-1 e RTO menor que 4 horas. Alcançar esses objetivos requer não apenas tecnologia apropriada, mas processos bem documentados e testados. A ausência de testes regulares claramente correlaciona com falhas de recuperação reais.

Construindo Resiliência Pragmática

Disaster recovery efetivo equilibra investimento técnico com realidade operacional. Nem toda aplicação justifica a complexidade e custo de deployments active-active em múltiplas regiões. A questão fundamental: quanto custa cada hora de downtime versus quanto custa prevenir esse downtime?

Para sistemas críticos – processamento de pagamentos, registros médicos, sistemas financeiros – o investimento em RTO/RPO agressivos se paga rapidamente. Para sistemas internos ou aplicações de baixo tráfego, estratégias mais simples como backups regulares com procedimentos manuais de recuperação podem ser suficientes.

O incidente SK C&C ensinou uma lição que transcende tecnologia: sistemas de backup que compartilham pontos de falha com sistemas primários não são backups reais. Implementar DR verdadeiro significa assumir que sua região primária pode desaparecer completamente – e ter um plano testado para continuar operando quando isso acontecer. A diferença entre ter um plano e ter um plano testado foi, literalmente, 100 milhões de dólares em perdas.