Blog/Artigos · Cloud e Plataforma
RTO e RPO, as quatro estratégias de backup a multi-site, a compensação entre custo e velocidade de recuperação, e o teste que separa plano de esperança.
Deus manda Noé construir a arca antes de a primeira gota cair. É a essência do disaster recovery: a arca não se constrói durante o dilúvio, se constrói na seca, quando ninguém acredita que o dilúvio virá. Todo sistema terá o seu dilúvio, a região que cai, o dado corrompido, o ataque que criptografa tudo, e a pergunta não é se, é quando. Quem só pensa em recuperação no dia do desastre já afundou, porque construir a arca leva tempo, e o dilúvio não espera. Disaster Recovery é a disciplina de construir a arca na seca: decidir de antemão quanto se aceita perder, montar o mecanismo de sobrevivência, e o mais esquecido, testar se a arca de fato flutua antes de a água subir.
Disaster recovery começa com duas perguntas de negócio, não de tecnologia, e delas sai tudo. A primeira é o RTO, o Recovery Time Objective: quanto tempo o sistema pode ficar fora antes que o dano ao negócio seja inaceitável? Minutos, horas, um dia? A segunda é o RPO, o Recovery Point Objective: quanto dado você aceita perder, medido em tempo? A última hora de transações, o último minuto, nada? RTO é sobre tempo parado; RPO é sobre dado perdido. As duas juntas definem o tamanho da arca que o negócio precisa.
O erro comum é responder essas perguntas com desejo, não com conta. Todo mundo quer RTO zero e RPO zero, recuperação instantânea sem perder nada, até ver o custo disso. RTO e RPO baixos custam caro, porque exigem infraestrutura duplicada e sempre pronta. A resposta madura vem do negócio: quanto custa cada hora parada, quanto custa cada transação perdida, e quanto vale a pena gastar para evitar. Um sistema de pagamento não tolera perder transação e paga por RPO quase zero; um relatório interno tolera perder um dia e não justifica gastar nada com isso. A arca se dimensiona pela cheia que se espera, não pela maior cheia imaginável.
A AWS organiza o disaster recovery em quatro estratégias, ordenadas por velocidade de recuperação e por custo, que crescem juntos. Backup e restore é a mais simples e barata: guarda-se cópia do dado e da infraestrutura, e no desastre reconstrói-se tudo a partir dela. RTO de horas, custo baixo. Pilot light mantém o núcleo mínimo sempre ligado, o banco replicado e desligado o resto, e no desastre acende-se o que faltava, como a chama piloto que espera para acender o fogão. RTO menor, custo médio.
As duas mais robustas custam mais. Warm standby mantém uma versão reduzida do sistema inteiro sempre rodando na outra região, pronta para assumir e escalar, com RTO de minutos. Multi-site ativo-ativo roda o sistema completo em mais de uma região ao mesmo tempo, servindo tráfego das duas, de modo que a queda de uma é quase imperceptível, RTO próximo de zero e RPO próximo de zero, ao custo de rodar tudo em dobro, para sempre. A escolha não é qual é a melhor; é qual o RTO e o RPO do negócio justificam, porque cada degrau de recuperação mais rápida se paga em infraestrutura ociosa esperando o dilúvio que talvez não venha este ano.
| Estratégia | Como funciona | RTO típico | Custo |
|---|---|---|---|
| Backup e restore | cópia guardada, reconstrói tudo no desastre | horas | baixo |
| Pilot light | núcleo mínimo ligado, acende o resto no desastre | dezenas de minutos | médio-baixo |
| Warm standby | versão reduzida sempre rodando, assume e escala | minutos | médio-alto |
| Multi-site ativo-ativo | sistema completo em duas regiões servindo ao mesmo tempo | quase zero | alto (tudo em dobro) |
A tensão central do disaster recovery é entre velocidade de recuperação e custo, e ela não tem escapatória. Recuperação mais rápida exige mais infraestrutura pronta e ociosa, esperando um desastre que na maioria dos meses não acontece. Recuperação mais barata aceita ficar mais tempo fora e perder mais dado. Não há solução que dê os dois; há a escolha consciente de onde, no espectro, cada sistema deve ficar, e essa escolha é por sistema, não por empresa: a mesma organização terá multi-site para o pagamento e backup e restore para o relatório interno.
O erro dos dois lados é caro. Gastar em multi-site ativo-ativo para um sistema que tolera ficar um dia fora é queimar dinheiro em resiliência que ninguém precisa. Deixar o sistema crítico com só backup e restore é uma bomba-relógio: no dia do desastre, o RTO de horas vira o prejuízo que fecha o negócio, e a economia de meses não paga uma hora daquele dia. A disciplina madura mapeia cada sistema ao seu ponto no espectro, guiada pelo RTO e RPO que o negócio de fato precisa, e revisita esse mapa quando a criticalidade muda. A arca de cada sistema é do tamanho da cheia que aquele sistema enfrenta, nem maior nem menor.
Aqui está a verdade que derruba a maioria dos planos de DR: o plano de recuperação nunca testado não é um plano, é uma esperança escrita. Empresas mantêm documentos de DR detalhados, backups religiosamente feitos, uma região secundária configurada, e descobrem no dia do desastre que o backup não restaura, que a região secundária tem uma versão velha da configuração, que o procedimento aponta para um sistema que não existe mais, ou que a única pessoa que sabia executar o failover saiu da empresa. A arca estava na garagem, e ninguém verificou se flutuava.
A defesa é o teste regular de DR, e é aqui que o disaster recovery encontra o chaos engineering: o game day de recuperação, o exercício agendado de derrubar de propósito e recuperar de verdade, medindo se o RTO e o RPO prometidos são cumpridos na prática. Esse teste é a única forma de transformar a esperança em plano. Ele acha o backup que não restaura antes do desastre, mantém a região secundária de fato sincronizada, e garante que mais de uma pessoa sabe executar. A regra que eu levo, e que dá nome a este próprio repositório, é simples: recuperação de desastre que não é ensaiada é ficção, e a hora de descobrir que a arca não flutua não pode ser a hora da cheia.
O disaster recovery amadurece da esperança à arca provada. No começo é o backup que talvez restaure, feito sem RTO nem RPO definidos. Depois vêm os objetivos por sistema e a estratégia escolhida para cada um. No meio vem o multi-região de verdade, com a região secundária sincronizada. No topo é o DR testado regularmente, com game days de recuperação que provam o RTO na prática, e a IA acompanhando o mapa de criticalidade e cronometrando os testes. Cada degrau troca uma parte da fé pela prova de que a arca flutua.
O disaster recovery se apoia em tudo o que veio antes neste eixo: na Landing Zone, que organiza as contas de recuperação; no IaC, que permite reconstruir a infraestrutura a partir do código, transformando recuperação em reaplicar o que está escrito; no chaos engineering, que fornece o método de teste. E ele protege o que mais importa: a continuidade do negócio quando o dilúvio chega. Construir a arca na seca não dá retorno visível no mês em que não há desastre, e é exatamente por isso que a disciplina exige maturidade, porque ela pede investimento contra um risco que a maioria prefere não pensar. Mas o dilúvio vem, cedo ou tarde, e naquele dia a única coisa que importa é se a arca foi construída antes, e se alguém já a viu flutuar.
Disaster recovery é construir a arca na seca, antes do dilúvio que todo sistema um dia enfrenta. RTO e RPO, vindos do negócio, definem o tamanho da arca; as quatro estratégias, de backup a multi-site, ordenam velocidade de recuperação e custo, que crescem juntos; e a escolha é por sistema, evitando a bomba-relógio do crítico subprotegido e o desperdício do tolerante superprotegido. Mas a verdade que derruba a maioria dos planos é que a arca nunca testada não é arca: só o game day de recuperação transforma esperança em plano. A IA dimensiona e cronometra. Decidir quanto o negócio aceita perder, porém, continua sendo escolha de quem responde pela continuidade.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaצַלְמָוֶת
Você não sabe se o sistema é resiliente até quebrá-lo de propósito. Chaos Engineering injeta a falha de forma controlada, com hipótese e raio de dano limitado, para descobrir a fraqueza num experimento tranquilo, e não numa madrugada de incidente real.
Operaçõesחֲצֹצְרֹת
No incidente, a prioridade é restaurar, não achar culpado. Papéis claros, severidade objetiva, comando único e postmortem blameless são o que transformam o caos em processo.
