RPO (Recovery Point Objective) é a quantidade máxima de dados que você aceita perder, medida em tempo. RTO (Recovery Time Objective) é o tempo máximo que você aceita ficar sem operar. Juntos, esses dois números definem quanto vai custar sua estratégia de proteção — e qual tecnologia você precisa.
RPO: quanto dado você pode perder?
Imagine que seu sistema de ERP para de funcionar agora, às 14h de uma quinta-feira. Quando você consegue restaurá-lo, descobre que o último backup bom é das 8h de ontem quarta. Você perdeu 30 horas de transações — pedidos, notas fiscais, movimentações de estoque.
Isso é inaceitável? Para uma varejista de e-commerce, provavelmente sim. Para uma empresa de consultoria onde o ERP registra principalmente horas e relatórios, talvez seja tolerável — os dados podem ser inseridos manualmente.
O RPO é exatamente essa conversa. Não é uma decisão técnica; é uma decisão de negócio. O CTO e o gestor financeiro precisam responder: “Se perdermos X horas de dado, qual o impacto operacional e financeiro?” A tecnologia de backup é escolhida depois, para atender ao RPO decidido.
RPO de 24 horas: backup diário noturno é suficiente. Custo baixo.
RPO de 4 horas: backup a cada 4 horas durante o dia. Custo moderado, mais storage, mais jobs rodando.
RPO de 1 hora: backup frequente com snapshots contínuos. Custo mais alto, ferramentas específicas.
RPO de minutos ou segundos: Continuous Data Protection (CDP) ou replicação síncrona. Alto custo, tecnologia especializada — reservado para sistemas absolutamente críticos como sistemas financeiros de tempo real ou UTIs hospitalares.
RTO: quanto tempo você pode ficar parado?
Se o RPO define a granularidade do backup, o RTO define a velocidade do recovery. E é aqui que a maioria das empresas subestima o problema.
O problema real aqui é que o RTO não é o tempo de restore do dado — é o tempo total para que a operação esteja normalizada. Isso inclui: detectar o problema, decidir acionar o recovery, executar o restore, validar que os dados estão corretos, redirecionar o tráfego para o ambiente restaurado, comunicar usuários e, se necessário, reprocessar transações pendentes.
Um restore de 2 horas de dados pode ter um RTO total de 6 horas quando somado ao tempo de diagnóstico, validação e comunicação.
Calcular o custo de downtime é o passo fundamental para definir o RTO. A fórmula básica:
Custo por hora de downtime = Receita perdida + Custo operacional ocioso + Custo de recuperação manual + Multas contratuais + Dano reputacional estimado
Para um e-commerce que fatura R$ 500 mil/dia, uma hora de downtime custa R$ 20 mil em receita direta — sem contar os demais fatores. Para uma fábrica com linha de produção dependente de ERP, o custo pode ser muito maior.
Quando você coloca em perspectiva que uma solução de DR com RTO de 1 hora pode custar R$ 8 mil/mês a mais que o backup básico, e que uma hora de downtime custa R$ 20 mil, a matemática responde a pergunta por si mesma.
A relação entre RPO/RTO e custo da solução
Existe uma curva de custo clara: quanto menor o RPO e o RTO, maior o investimento necessário. Isso é intuitivo — manter dados mais atuais e recuperar mais rápido exige mais tecnologia, mais infraestrutura e mais operação.
| RTO | RPO | Solução típica | Custo relativo |
|---|---|---|---|
| 24–72 horas | 24 horas | Backup diário + processo de restore manual | Baixo |
| 4–24 horas | 4–8 horas | Backup frequente + ambiente de restore pré-provisionado | Moderado |
| 1–4 horas | 1 hora | Backup contínuo + replicação assíncrona + DR semi-ativo | Alto |
| 15–60 minutos | minutos | Replicação síncrona + DR ativo-ativo ou warm standby | Muito alto |
| < 5 minutos | segundos | Clustering ativo-ativo + CDP + DR ativo | Premium |
A armadilha mais comum é definir RPO e RTO aspiracionais — “queremos 1 hora de RPO e 15 minutos de RTO” — sem aprovar o orçamento necessário para atingi-los. O resultado é uma estratégia de backup dimensionada para custo baixo que não entrega os RTOs prometidos quando a crise chega.
Exemplos por setor
Varejo e e-commerce. Durante horário comercial, RPO de 1 hora e RTO de 2 horas são referência mínima. Em datas críticas (Black Friday, datas comemorativas), algumas empresas sobem para RPO de minutos com ambiente de DR aquecido.
Saúde. Prontuários eletrônicos em UTI e sistemas de monitoramento de pacientes exigem RPO de segundos e RTO de minutos — literalmente questão de vida. Sistemas administrativos de saúde (faturamento, agendamento) podem tolerar RPO de 4 horas e RTO de 8 horas.
Financeiro e seguros. Core banking e sistemas de liquidação financeira operam com RPO de segundos e são tipicamente ativos em cluster multi-datacenter. Sistemas de backoffice tolerem RPO de 1 hora.
Manufatura. Sistemas MES (Manufacturing Execution Systems) conectados à linha de produção têm custo de downtime muito alto — cada hora parada pode representar centenas de milhares de reais em produção perdida. RPO de 30 minutos e RTO de 1 hora são comuns para esses sistemas.
Serviços profissionais e escritórios. Para maioria das operações, RPO de 4 horas e RTO de 8 horas são suficientes e economicamente justificáveis.
Como documentar e testar
RPO e RTO só funcionam se estão documentados em um BCP (Business Continuity Plan) ou Plano de DR formal, e se são testados regularmente. A documentação deve especificar: para cada sistema crítico, qual o RPO e RTO acordado, qual tecnologia garante esse objetivo, quem é responsável por acionar o recovery, qual o procedimento passo a passo e qual foi o resultado do último teste.
O teste é o que valida se o RTO definido é real ou aspiracional. Um exercício de DR feito uma vez por ano, onde a equipe simula um failover e mede o tempo total de recovery, revela rapidamente se o processo funciona como planejado.
A Adentro ajuda sua empresa a definir RPO e RTO realistas e implementar a solução de backup e DR adequada para cada nível de criticidade. Fale com nossos especialistas.