RTO e RPO: o que são, qual a diferença e como definir cada um

RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar um sistema após uma falha. RPO (Recovery Point Objective) é a quantidade máxima de dados que você aceita perder, medida em tempo. Em resumo: RTO é quanto tempo até voltar, RPO é quanto dado você pode perder.

Todo plano de continuidade se resume, no fim, a dois números. Quando um sistema cai, a primeira pergunta da diretoria é “quanto tempo até voltar?”. A segunda, assim que a poeira baixa, é “perdemos dado?”. Saber o que é RTO e RPO, e ter definido os dois antes do incidente, é o que separa uma resposta tranquila de uma reunião de crise. Este texto explica cada um, mostra a diferença em uma frase e ensina a definir os números certos para a sua operação.

O que é RTO

RTO, sigla de Recovery Time Objective, é o tempo máximo que a sua empresa aceita ficar com um sistema fora do ar antes de restaurá-lo. É a resposta para a pergunta “a partir do momento da falha, quanto tempo temos para voltar?”.

O RTO é uma decisão de negócio antes de ser uma decisão técnica. Ele define o orçamento e a arquitetura que você vai precisar. Um RTO de poucos minutos exige redundância ativa e failover automático, o que custa mais. Um RTO de um dia inteiro permite uma estratégia mais simples e barata. O número certo não é o menor possível, é o que equilibra o custo de prevenir contra o custo de ficar parado.

O que é RPO

RPO, sigla de Recovery Point Objective, é a quantidade máxima de dados que a sua empresa aceita perder em caso de falha, medida em tempo. Ele responde à pergunta “até que ponto no passado podemos voltar sem prejuízo grave?”.

Na prática, o RPO define a frequência dos seus backups e replicações. Se você aceita perder no máximo cinco minutos de dados, precisa replicar a cada cinco minutos ou menos. Se aceita perder um dia, um backup diário resolve. O RPO traduz o valor do seu dado em uma cadência de proteção: quanto mais crítico o dado, menor o RPO, e mais frequente a cópia.

A diferença em uma frase

A confusão entre os dois some com uma frase: RTO é sobre tempo de sistema parado, RPO é sobre quantidade de dado perdido.

Um exemplo deixa claro. Imagine que um banco de dados falha às 10h12. O último backup foi às 10h00. O sistema volta às 11h00. Nesse caso, o RPO real foi de 12 minutos, porque os dados gerados entre 10h00 e 10h12 se perderam. E o RTO real foi de 48 minutos, o tempo entre a falha e o retorno. Um mede o buraco no passado, o outro mede a duração da interrupção. Você precisa dos dois, porque otimizar só um deixa o outro descoberto.

Como definir cada número no seu negócio

Não existe RTO e RPO único para a empresa inteira. Cada sistema tem uma criticidade, e tentar dar o mesmo número para todos é desperdício de um lado e risco do outro. O caminho é classificar os sistemas por impacto e atribuir os objetivos a cada classe.

A tabela abaixo mostra uma forma comum de organizar isso. Os valores são ilustrativos e servem para você raciocinar sobre as suas próprias faixas, não como benchmark fixo.

Criticidade	Exemplos	RTO típico	RPO típico
Crítico	ERP, checkout de e-commerce, core transacional	Minutos a 1 hora	Segundos a minutos
Importante	CRM, BI, sistemas internos de apoio	2 a 8 horas	Até 1 hora
Secundário	Arquivos, ambientes de dev e teste, relatórios	24 horas ou mais	24 horas

A lógica é direta. Quanto mais a interrupção daquele sistema dói no faturamento, na operação ou na reputação, mais curto o RTO e o RPO precisam ser, e mais a empresa precisa investir em redundância para sustentá-los. Sistemas de apoio toleram tempos maiores, e gastar em failover instantâneo para eles é jogar dinheiro fora.

O custo de cada hora de RTO

Definir RTO sem conhecer o custo de cada hora parada é decidir no escuro. O número que justifica o investimento em recuperação é o custo de downtime, ou seja, quanto a sua empresa perde por hora de sistema indisponível.

A conta básica soma a receita perdida, o custo da equipe parada e o impacto de reputação e multas, dividido pelo tempo de operação. Um exemplo simples mostra a lógica: se a sua operação fatura, em média, vinte mil reais por hora e uma falha derruba o sistema por três horas, a interrupção custou sessenta mil reais só em receita, sem contar equipe parada e reputação. Com esse valor na mão, a decisão de RTO deixa de ser opinião. Se cada hora parada custa um valor alto, um RTO curto se paga; se o custo por hora é baixo, um RTO mais folgado é a escolha racional. Esse é o cálculo que transforma continuidade de “boa prática” em decisão de orçamento defensável.

Erros comuns ao prometer RTO e RPO

Quatro erros aparecem com frequência quando empresas definem esses números.

O primeiro é prometer um RTO que nunca foi testado. Um RTO de quatro horas no contrato não significa nada se a empresa nunca executou uma restauração de verdade para medir se consegue cumpri-lo. RTO no papel é hipótese; RTO testado é compromisso.

O segundo é confundir os dois objetivos e acabar protegendo só o tempo, esquecendo o dado, ou o contrário. Os dois precisam de atenção separada.

O terceiro é aplicar o mesmo número para tudo. Dar RTO de minutos para um sistema de relatórios secundário gasta dinheiro à toa; dar RTO de um dia para o core transacional é assumir um risco que a diretoria não aprovaria se entendesse.

O quarto é tratar RTO e RPO como números fixos para sempre. À medida que a operação cresce e a criticidade dos sistemas muda, os objetivos precisam ser revistos. Um número definido há três anos pode estar perigosamente desatualizado hoje.

Perguntas frequentes

O que é RTO? É o tempo máximo aceitável para restaurar um sistema após uma falha, ou seja, quanto tempo até voltar a operar.

O que é RPO? É a quantidade máxima de dados que você aceita perder em caso de falha, medida em tempo. Define a frequência de backup e replicação.

Qual a diferença entre RTO e RPO? RTO mede o tempo de sistema parado; RPO mede a quantidade de dado perdido. Um trata da duração da interrupção, o outro do quanto você volta no passado.

O que é um bom RTO? Não há valor universal. Um bom RTO é o que equilibra o custo de manter redundância contra o custo de cada hora parada para aquele sistema específico. Para o core crítico, costuma ser minutos a uma hora; para sistemas de apoio, horas.

RTO de 4 horas é realista? Pode ser, desde que a arquitetura suporte e a empresa tenha testado a restauração dentro desse prazo. Sem teste real, qualquer RTO é apenas uma promessa não verificada.

---

A Optidata projeta RTO e RPO com você e inclui DR em duas regiões. Fale com um especialista.