O que são RPO e RTO e como definir os da sua empresa?

RPO (Recovery Point Objective) define a quantidade máxima de dados que sua empresa pode perder, medida em tempo — quantas horas de transações você aceita perder em um desastre. RTO (Recovery Time Objective) define o tempo máximo tolerável para que o serviço seja restaurado após uma falha. Juntos, eles determinam a arquitetura e o custo da sua solução de continuidade.

Definições precisas

RPO — Recovery Point Objective

O RPO responde à pergunta: “Se um desastre acontecer agora, qual é o ponto mais antigo dos dados para o qual posso restaurar e ainda operar?”

Imagine que sua empresa faz backup diário às 23h e um incidente ocorre às 17h do dia seguinte. Você perde 18 horas de dados. Esse é o RPO real dessa solução. O RPO é sempre uma medida de dados, expressa como intervalo de tempo entre a última cópia válida e o momento do desastre.

RTO — Recovery Time Objective

O RTO responde à pergunta: “Quanto tempo posso ficar com o serviço indisponível antes de causar dano inaceitável ao negócio?”

Se seu e-commerce ficar fora do ar por 4 horas em uma Black Friday, o dano é calculável. Esse cálculo define o RTO. O RTO é uma medida de tempo de indisponibilidade, do momento da falha até a restauração completa do serviço.

A relação entre os dois

RPO e RTO são independentes, mas relacionados ao custo. Um sistema com RPO de 0 (sem perda de dados) e RTO de 0 (sem interrupção) é tecnicamente possível — e extremamente caro. Na prática, o negócio precisa definir qual combinação é aceitável e quanto está disposto a pagar por ela.

Como calcular o impacto financeiro do downtime

Antes de definir metas de RPO e RTO, você precisa quantificar o custo do downtime. Sem esse número, qualquer meta é arbitrária — e fica impossível justificar o investimento para a diretoria.

Componentes do custo de downtime:

• Receita perdida: Para comércio eletrônico e SaaS, calcule a receita horária média (receita mensal / (dias × horas de operação)).
• Produtividade interna: Número de colaboradores impedidos de trabalhar × custo/hora.
• Recuperação de dados: Custo de reprocessar transações perdidas (horas de equipe, custo de reconciliação com fornecedores/clientes).
• Multas contratuais: SLAs com clientes, penalidades regulatórias (ex: BACEN para IFs).
• Dano de reputação: Mais difícil de quantificar, mas real — churn de clientes após um incidente grave.

Fórmula simplificada:

Custo por hora de downtime = receita horária + custo de produtividade + exposição regulatória/hora

Com o custo por hora em mãos, o RTO máximo aceitável é o ponto onde o custo do downtime supera o custo de uma solução mais robusta.

Relação entre RPO/RTO e custo da solução

Quanto menores as metas, maior o custo — a relação não é linear:

DR quente (hot standby): Ambiente secundário sempre ligado, com dados replicados em tempo quase real. Failover em minutos.

DR morno (warm standby): Ambiente secundário provisionado, mas com capacidade reduzida. Dados replicados. Requer ativação manual parcial.

DR frio (cold standby): Infraestrutura apagada ou apenas hardware reservado. Dados em backup. Requer provisionamento completo antes do restore.

Exemplos por setor

Setor financeiro (bancos, corretoras, fintechs):

• RPO: 0 (replicação síncrona — qualquer transação confirmada não pode ser perdida)
• RTO: menor que 1 hora (regulatório e reputacional)
• Solução típica: cluster ativo-ativo entre dois datacenters com replicação síncrona de banco de dados, failover automático de rede via BGP

E-commerce e varejo digital:

• RPO: menor que 4 horas (pedidos das últimas horas são recuperáveis via logs de sistemas de pagamento)
• RTO: menor que 2 horas (cada hora fora do ar em pico tem impacto financeiro direto)
• Solução típica: DR morno com replicação assíncrona e snapshots a cada hora

Indústria e manufatura:

• RPO: menor que 24 horas (sistemas ERP toleram perda de um dia de registros, que podem ser reprocessados)
• RTO: menor que 4 horas (linha de produção pode operar por horas sem sistemas, mas não indefinidamente)
• Solução típica: backup corporativo com retenção diária + ambiente de DR frio pré-configurado

Serviços e escritórios:

• RPO: menor que 24 horas
• RTO: menor que 8 horas (próximo dia útil)
• Solução típica: backup diário com restore testado mensalmente

Como documentar RPO e RTO

RPO e RTO devem estar documentados no BCP (Business Continuity Plan) ou DRP (Disaster Recovery Plan), não apenas na cabeça do gestor de TI. Quando um incidente acontece, não é hora de lembrar onde estavam as instruções — é hora de executar.

O documento mínimo deve conter:

1. Inventário de sistemas críticos com RPO e RTO definido para cada um. Sistemas diferentes podem ter metas diferentes.
2. Runbook de recuperação — procedimento passo a passo para restaurar cada sistema, com responsáveis nomeados e contatos de escalonamento.
3. Mapa de dependências — quais sistemas dependem de outros? Restaurar o ERP antes do banco de dados é inútil.
4. Critérios de declaração de desastre — quem tem autoridade para acionar o DR? Quais são os gatilhos?
5. Procedimento de comunicação — como notificar clientes, reguladores e colaboradores durante um incidente?

Como testar RPO e RTO na prática

RPO testado: Execute um restore de um backup antigo e verifique o timestamp do último dado presente. A diferença entre esse timestamp e o momento do backup é o RPO real da solução.

RTO testado: Meça o tempo total desde a declaração do incidente até o serviço estar operacional e validado. Inclua tempo de detecção, decisão, execução técnica e validação — não apenas o tempo de restore técnico.

Frequência de testes: Pelo menos uma vez por ano para sistemas críticos, ou após qualquer mudança significativa de infraestrutura. Reguladores como o BACEN para instituições financeiras exigem evidências de testes periódicos.

Tipos de teste:

• Tabletop exercise: Discussão estruturada do cenário de desastre sem execução real. Identifica lacunas no processo sem risco.
• Restore parcial: Restaurar um sistema não crítico em ambiente de testes para validar o procedimento.
• Failover real: Ativar o ambiente de DR com tráfego de produção redirecionado. O único teste que valida RTO com precisão.

A Adentro oferece soluções de Disaster Recovery e Backup Corporativo dimensionadas para diferentes metas de RPO e RTO. Fale com um especialista para avaliar o cenário da sua empresa.