Transferência em recuperação de desastres: continuidade do negócio

A transferência de ficheiros em recuperação de desastres mantém as operações em funcionamento quando um site primário falha — através de replicação entre regiões (S3 CRR, Azure GRS), infraestrutura warm standby e runbooks de failover documentados. Um sistema de ficheiros preparado para DR copia continuamente as alterações para uma localização secundária dentro de um RPO de segundos a horas, suporta failover dentro do objetivo RTO e foi testado em condições realistas. O caminho mais curto para DR útil: escolha uma carga de trabalho, replique-a para uma segunda região, simule uma falha regional num sábado e meça o que realmente acontece.

Classificar Cargas de Trabalho por Impacto no Negócio

Nem todos os sistemas de ficheiros merecem replicação hot-hot. Uma análise de impacto no negócio categoriza os sistemas pela sua tolerância a tempo de inatividade e perda de dados:

• Tier 0 (missão crítica): processamento de pagamentos, sistemas clínicos. RPO <1 min, RTO <15 min.
• Tier 1 (crítico): gestão de encomendas, apps orientadas ao cliente. RPO <15 min, RTO <1 hora.
• Tier 2 (importante): ferramentas internas, relatórios. RPO <24 horas, RTO <8 horas.
• Tier 3 (padrão): materiais de formação, arquivos. RPO <1 semana, RTO <3 dias.

O Tier 0 custa 3-10x o Tier 3 para replicar. Mapeie os sistemas honestamente. A maioria das empresas tem 5-10% dos sistemas no Tier 0-1 e deve concentrar o investimento aí em vez de tratar tudo igualmente.

Topologias de Replicação

Três modelos de replicação dominam para armazenamento de ficheiros:

1. Active-passive: o primário aceita escritas, o secundário recebe réplica. O failover requer promoção. Usado pela maioria das configurações DR regionais.
2. Active-active: ambas as regiões aceitam escritas, com resolução de conflitos. Maior complexidade mas RTO próximo de zero. Usado por sistemas globais.
3. Baseado em backup: backup periódico para secundário. RPO mais alto mas mais simples. Usado para Tier 3.

O S3 Cross-Region Replication (CRR) implementa active-passive com RPO sub-minuto. Os S3 Multi-Region Access Points adicionam roteamento de failover. Para active-active, o DynamoDB Global Tables e o CockroachDB tratam bases de dados; para ficheiros, o rclone em ambas as direções com etiquetas de resolução de conflitos é uma abordagem DIY.

Escolher uma Região Secundária

Primária e secundária devem falhar de forma independente. Regras práticas:

• Região geográfica diferente (us-east-1 → us-west-2, não us-east-1 → us-east-2)
• Rede elétrica diferente (Costa Oeste vs Costa Leste nos EUA, diferentes redes de países europeus)
• Zonas tectónicas diferentes onde relevante

Para cargas de trabalho de conformidade, ambas as regiões devem satisfazer o regulamento. Os dados RGPD devem permanecer na UE — replique Paris para Frankfurt ou Dublin, não para Virginia. A HIPAA também exige um BAA na região secundária. Documente a seleção de região e o raciocínio; os auditores irão perguntar. Em Portugal, o RGPD (com supervisão da CNPD) exige que os dados pessoais de residentes europeus permaneçam em jurisdições adequadas.

Custo de Replicação Entre Regiões

A replicação tem três componentes de custo:

1. Armazenamento: duplica o custo primário (ambas as regiões guardam uma cópia)
2. Transferência de dados: a AWS cobra 0,02 EUR/GB para CRR entre regiões
3. Taxas de pedido: operações PUT no destino

Para 10 TB replicados mensalmente, espere cerca de 700 EUR/mês na AWS entre Virginia e Oregon. Mitigações: replicar para uma classe de armazenamento mais barata no destino (S3 Glacier Instant Retrieval em vez de Standard), filtrar replicação por prefixo ou etiqueta para excluir dados não críticos, e usar métricas de replicação de bucket para apanhar replicação descontrolada.

O Runbook de Failover

Um runbook que existe apenas como ideia é um runbook que falha. Um runbook pronto para produção cobre:

1. Critérios de ativação: que condições iniciam o failover (página de estado da região, verificações de saúde da aplicação, latência P99 acima do limiar)
2. Autoridade de decisão: quem toma a decisão (tipicamente VP de Engenharia + líder SRE, com limiares pré-aprovados para ativação automática)
3. Passos: comandos exatos, em ordem, com saída esperada
4. Verificação: como confirmar que cada passo funcionou
5. Rollback: como reverter se o próprio failover causou problemas
6. Comunicação: atualização da página de estado, notificação de clientes, Slack interno

Exemplo de passo de failover para uma aplicação suportada por S3: atualizar o Route 53 para apontar ficheiros.exemplo.com do CloudFront do bucket primário para o CloudFront do bucket secundário. Testar com dig e um carregamento canário. Objetivo de tempo: menos de 10 minutos.

Estratégia de DNS e Routing

O DNS normalmente conduz o failover. Opções:

• Route 53 Failover routing: active-passive com troca automática baseada em verificações de saúde
• Route 53 Latency routing: tráfego para a região saudável mais próxima
• CloudFront com failover de origem: transparente para os clientes
• Load balancer com backends multi-região: funciona mas adiciona complexidade

O TTL importa. Um registo DNS com TTL de 300 segundos falha em 5 minutos; um TTL de 3.600 segundos demora uma hora. Defina registos críticos para DR com TTL de 60-300 segundos, aceitando um pouco mais de tráfego DNS para convergência mais rápida.

Integridade dos Dados Durante o Failover

O lag de replicação significa que o secundário está ligeiramente atrás. O failover pode perder as escritas mais recentes. Documente o RPO como a perda máxima esperada e tenha um plano de reconciliação:

• Registe escritas não confirmadas na camada de aplicação para que possam ser reproduzidas
• Capture transações em curso e reproduza a partir de registos de eventos
• Aceite a perda explicitamente (para dados não críticos, mais simples é melhor)

Para carregamentos de ficheiros especificamente, um carregamento multipart interrompido pelo failover pode deixar carregamentos incompletos no secundário. Configure regras de ciclo de vida AbortIncompleteMultipartUpload em ambas as regiões para os limpar.

Testar DR a Sério

Um plano DR testado e um plano DR não testado são animais diferentes. Níveis de teste:

• Exercício de tabletop: percorrer o runbook verbalmente. Trimestralmente.
• Failover parcial: fazer failover de um subsistema (por exemplo, apenas o serviço de ficheiros). Semestralmente.
• Failover regional completo: fazer failover de tudo numa janela de manutenção programada. Anualmente.
• Chaos engineering: não programado, simulado, durante horas de expediente. Trimestralmente para sistemas Tier 0.

Registar tudo. O que falhou. Quanto tempo cada passo demorou realmente. Quem não conseguiu aceder à documentação quando precisou. Melhorar o runbook após cada teste. As equipas que fazem isto têm failovers que funcionam; as que não fazem descobrem problemas durante incidentes reais.

Os Canais de Comunicação Importam

Durante um incidente, a comunicação dentro da cloud pode estar indisponível. O Slack alojado na mesma região AWS que está a falhar é inútil. Pré-arrange canais out-of-band:

• Um workspace Slack secundário alojado numa região diferente
• Ponte SMS via Twilio ou Telnyx
• Uma árvore telefónica pessoal como último recurso
• Uma página de estado pública alojada fora da infraestrutura primária (Atlassian Statuspage, StatusGator)

Documente os canais no dossier físico. Pratique a mudança para eles.

Transferir Ficheiros de Recuperação Entre Pessoas

Quando uma falha regional bloqueia o acesso às ferramentas normais de colaboração, transferir ficheiros específicos — um dump de base de dados atual, uma exportação de configuração, um playbook de resposta a incidentes — precisa de um canal que funcione independentemente da infraestrutura. Uma ferramenta compatível com dispositivos pessoais ajuda.

O HexaTransfer funciona em qualquer browser sem configuração de conta — útil quando o fornecedor de SSO também está em baixo, ou quando consultores a responder ao incidente precisam de receber ficheiros sem ser aprovisionados no tenant. A cifração AES-256-GCM ponta a ponta significa que mesmo os momentos stressantes de mãos no teclado não vazam segredos pela rede.

Revisões Pós-Ação

Cada teste DR e cada incidente real merecem um postmortem sem culpa. Documentar:

• Cronologia dos eventos
• O que funcionou
• O que não funcionou
• Causas raiz (técnicas e de processo)
• Ações com responsáveis e datas-limite

Acompanhar as ações até à conclusão. Um postmortem com 20 ações e zero concluídas é pior do que nenhum postmortem — sinaliza à equipa que as melhorias não importam. Feche o ciclo, e o próximo incidente corre melhor do que o anterior.

A recuperação de desastres é sobretudo disciplina. Defina o RPO/RTO, replique continuamente, documente o runbook, teste trimestralmente e comunique out-of-band. A tecnologia é a parte fácil.

Experimente em hexatransfer.com — gratuito, sem conta necessária, máximo de 10 GB.