Pular para conteúdo

Plano de Recuperação de Desastres

Plano de recuperação de desastres é o documento que responde, antes do incidente, a duas perguntas que ninguém consegue responder bem no meio dele: quanto de dado podemos perder e em quanto tempo precisamos voltar. Todo o resto — topologia, replicação, backup, custo — decorre dessas duas respostas.

Linha do tempo de desastre com RPO e RTO, e as três fases: declarar, executar failover e executar failback

RPO mede dado perdido; RTO mede tempo parado. São números de negócio, não de infraestrutura.

RPO e RTO

  • RPO (Recovery Point Objective) — o quanto de dado é aceitável perder, medido em tempo. RPO de 5 minutos significa aceitar perder até 5 minutos de transações.
  • RTO (Recovery Time Objective) — quanto tempo o serviço pode ficar indisponível até voltar a atender.

Os dois têm preço. RPO zero exige replicação síncrona, que cobra latência em toda escrita. RTO de segundos exige capacidade ociosa na outra região. O trabalho de arquitetura é encontrar o ponto em que o custo do risco e o custo da proteção se cruzam.

Nível RPO típico RTO típico Arranjo
Backup restaurável Horas Horas Backup fora do site, restauração sob demanda
Réplica assíncrona Segundos a minutos Minutos Réplica quente na outra região, promoção manual ou assistida
Réplica síncrona entre regiões Próximo de zero Dezenas de segundos Quórum entre br-sp-1 e br-sp-2, promoção automatizada
Multi-escrita distribuída Zero Sem interrupção de escrita CockroachDB com três domínios de falha

Cenários cobertos

Um plano que só prevê "o datacenter pegou fogo" cobre o cenário mais raro e ignora os frequentes.

Cenário Frequência Resposta
Falha de disco ou de nó Comum Réplica assume; nenhuma ação humana
Falha de host ou rack Comum Anti-affinity garante que o quórum sobrevive
Corrupção lógica / erro humano Comum Restauração pontual (PITR) — replicação não ajuda aqui
Falha de rede entre regiões Ocasional Fencing e quórum evitam split-brain
Perda de uma região inteira Rara Failover para a região sobrevivente
Ransomware / exclusão maliciosa Rara, grave Backup imutável com retenção protegida

O desastre mais comum é humano

Na prática, o incidente que mais destrói dado não é a queda do datacenter — é o comando errado, o deploy com bug e a exclusão indevida. Por isso backup com PITR faz parte do plano de DR, não é um assunto separado.

Estrutura do plano

O plano é um documento operacional, não uma apresentação. O que ele contém:

  1. Inventário — sistemas, bancos, dependências e criticidade de cada um.
  2. RPO e RTO por sistema — nem tudo precisa do mesmo nível, e tratar tudo como crítico encarece sem proteger mais.
  3. Critério de declaração — o que caracteriza desastre e quem tem autoridade para declarar. Sem isso, a primeira meia hora é gasta decidindo se é hora de agir.
  4. Procedimento de failover — passo a passo executável, com comandos, não com princípios.
  5. Comunicação — quem avisa clientes, equipe e, quando aplicável, autoridades.
  6. Procedimento de failback — como voltar, que é a metade esquecida da maioria dos planos.
  7. Registro do exercício — data e resultado do último simulado.

Failover entre regiões

As duas regiões da InteSys são brasileiras e ficam na região metropolitana de São Paulo — br-sp-1 (Cirion SAO1) e br-sp-2 (Equinix SP3) — interligadas por links Lan2Lan ou túneis criptografados. A latência entre elas permite replicação síncrona, o que torna viável RPO próximo de zero sem sair do país.

Sequência de failover:

  1. Detectar — mais de um observador confirma a perda. Um observador único não decide; falha de rede momentânea não é desastre.
  2. Declarar — a pessoa com autoridade declara, segundo os critérios escritos.
  3. Isolar (fencing) — o primário antigo é impedido de aceitar escrita. Sem isso, dois primários corrompem os dados.
  4. Promover — a réplica mais avançada da região sobrevivente assume, após verificação de posição de replicação.
  5. Redirecionar — o proxy passa a apontar para o novo primário; a aplicação mantém o mesmo endereço.
  6. Verificar — sanidade dos dados, latência e taxa de erro antes de declarar o serviço restabelecido.
  7. Comunicar — status para dentro e para fora, com estimativa de normalização.

Failback

Voltar é uma operação planejada, nunca urgente:

  1. reconstruir a região recuperada como réplica da atual;
  2. sincronizar e aguardar lag zero;
  3. escolher uma janela de baixa carga;
  4. executar a troca controlada, com o mesmo procedimento de fencing;
  5. confirmar que replicação, backup e alertas voltaram ao estado normal.

Não há pressa para o failback

Se a região sobrevivente está atendendo com desempenho aceitável, o retorno pode esperar a causa raiz ser corrigida. Failback apressado costuma gerar o segundo incidente.

Simulados

Um plano nunca executado é uma hipótese.

Exercício Frequência O que valida
Failover em ambiente de teste Trimestral O procedimento está correto e atualizado
Restauração completa cronometrada Semestral O RTO acordado é real
Failover controlado em produção Anual, em janela Que o plano funciona com dado e tráfego reais
Revisão de contatos e autoridade Semestral Que as pessoas do plano ainda são as certas

Cada exercício termina com um relatório: tempo medido, desvios do procedimento e correções aplicadas ao runbook.

Soberania de dados no plano de DR

O plano inteiro é executado dentro do Brasil. Réplicas, logs, backups e o destino do failover ficam em br-sp-1 e br-sp-2, sob jurisdição brasileira e sem transferência internacional de dados pessoais.

Quando o cliente pede uma cópia de contingência em outro país — exigência corporativa ou isolamento geográfico do backup — ela é configurada em volume criptografado, com a transferência internacional documentada no desenho da solução. É decisão do cliente, nunca padrão da plataforma.

Páginas Relacionadas