--- title: "RTO e RPO: o que são, qual a diferença e como definir cada um" description: "RTO é quanto tempo até voltar; RPO é quanto dado você aceita perder. Veja o significado, a diferença e como definir os dois números na sua infraestrutura." url: "https://www.optidata.com/br/contents/o-que-e-rto-e-rpo" lang: "pt-BR" published_at: "2026-06-25T00:00:00.000Z" updated_at: "2026-06-30T19:04:22.682Z" author: "Optidata" --- # RTO e RPO: o que são, qual a diferença e como definir cada um > RTO é quanto tempo até voltar; RPO é quanto dado você aceita perder. Veja o significado, a diferença e como definir os dois números na sua infraestrutura. > **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. ![RTO e RPO: significado, diferença e como definir cada um](https://drop.ip.odhserver.com/files/optidata-cloud/capa-rto-rpo.webp) 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](/br/contact).*