RTO e RPO: O Que São, Como Calcular e Tabela por Setor [2026]

RTO e RPO: As Duas Métricas que Definem Sua Estratégia de Recuperação

Pontos-Chave

• RTO responde "quanto tempo posso ficar parado?" — RPO responde "quanto dado posso perder?"
• O custo médio de inatividade em empresas varia de US$ 5.600 a US$ 9.000 por minuto, segundo estudos citados pela Gartner
• O custo médio global de uma violação atingiu US$ 4,88 milhões, segundo o IBM Cost of a Data Breach Report
• RTO/RPO de minutos exigem replicação ativa e DRaaS; de horas podem ser atendidos com backup incremental
• Sem testar restaurações, seu RTO é teórico — e teoria não salva empresas em crise

RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar um sistema após uma interrupção — responde à pergunta "quanto tempo posso ficar parado?". RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo — responde à pergunta "quanto dado posso perder?". Juntos, RTO e RPO são as métricas que determinam toda a arquitetura de backup corporativo e disaster recovery de uma organização.

RTO e RPO são as duas métricas mais importantes do planejamento de backup corporativo e disaster recovery. Elas definem quanto tempo sua empresa pode ficar parada e quanta informação pode perder antes que o impacto se torne inaceitável. Sem elas, qualquer investimento em backup é feito às cegas.

Mas como calcular essas métricas para o seu contexto? E qual a tecnologia certa para cada faixa? Vamos destrinchar cada conceito, mostrar exemplos práticos e entregar um método de cálculo replicável.

RTO — Recovery Time Objective

Definição

O RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar um sistema, aplicação ou serviço após uma interrupção. Em outras palavras: quanto tempo sua empresa pode ficar sem esse sistema funcionando?

Ele é medido do momento do incidente até o sistema totalmente operacional novamente — incluindo detecção, decisão, execução e validação.

Exemplos práticos de RTO

• E-commerce de alto volume: RTO de 15 minutos a 1 hora — cada minuto offline é venda perdida
• ERP financeiro: RTO de 2 a 4 horas — operações manuais cobrem parcialmente
• CRM de vendas B2B: RTO de 4 a 8 horas
• Servidor de arquivos departamental: RTO de 8 a 24 horas
• Sistemas de arquivamento e BI: RTO de 24 a 72 horas

O custo do RTO

Quanto menor o RTO desejado, maior o investimento. A Gartner estima que o custo de downtime em empresas médias varia de US$ 5.600 a US$ 9.000 por minuto. Para um banco, é ordem de grandeza maior. A equação é simples: quanto custa o downtime versus quanto custa a infraestrutura para evitá-lo?

RPO — Recovery Point Objective

Definição

O RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder em caso de incidente, medida em tempo. Se o backup roda a cada 6 horas, seu RPO máximo é 6 horas — no pior caso, você perde tudo produzido entre o último backup e o incidente.

Exemplos práticos de RPO

• Banco de dados transacional: RPO de segundos a minutos via CDP ou replicação síncrona
• ERP de média criticidade: RPO de 1 hora
• E-mail corporativo: RPO de 4 a 12 horas
• Servidor de arquivos geral: RPO de 24 horas
• Dados de arquivamento: RPO de 7 dias

Como o RPO define a frequência do backup

A regra é direta: frequência do backup ≤ RPO. Se o RPO é 1 hora, o backup deve rodar a cada hora ou menos. Confira os tipos de backup e como eles impactam a frequência possível, e o cronograma de backup ideal.

Como Calcular RTO e RPO na Prática

O cálculo de RTO e RPO segue um método estruturado baseado na Análise de Impacto ao Negócio (BIA). Para cada sistema crítico da empresa, avalie três variáveis: o custo financeiro por hora de inatividade, o impacto operacional da indisponibilidade e as obrigações regulatórias (como LGPD e PCI-DSS).

Fórmula para calcular o RPO

RPO = Custo aceitável de perda ÷ Valor dos dados gerados por hora

Exemplo: se uma empresa gera R$ 100.000 em transações por hora e aceita perder no máximo R$ 25.000, o RPO é de 15 minutos (R$ 25.000 ÷ R$ 100.000/h = 0,25h = 15 min). Esse RPO exige, no mínimo, backup incremental a cada 15 minutos ou CDP (Continuous Data Protection).

Fórmula para calcular o RTO

RTO = Tempo máximo de inatividade antes de impacto inaceitável

Considere: tempo de detecção do incidente + tempo de decisão + tempo de restauração + tempo de validação. Se o custo de downtime é R$ 50.000/hora e o investimento em infraestrutura de recuperação rápida custa R$ 10.000/mês, o break-even ocorre se a empresa sofrer mais de 2,4 horas de downtime por ano — o que é estatisticamente provável.

RTO vs RPO: A Diferença Visual

Uma forma simples de visualizar: RPO olha para trás, RTO olha para frente.

Como Calcular RTO e RPO para Sua Empresa

Passo 1: Análise de Impacto ao Negócio (BIA)

A ISO 22301 (gestão de continuidade de negócios) define a BIA como ponto de partida. Para cada sistema, responda:

1. Qual o impacto financeiro por hora de indisponibilidade?
2. Quantos usuários/clientes dependem do sistema?
3. Existem obrigações regulatórias envolvendo esse dado?
4. Qual o impacto reputacional de sua indisponibilidade?
5. Quais sistemas upstream/downstream dependem dele?

Passo 2: Classificação de criticidade

Agrupe sistemas em tiers:

• Tier 0 — Missão crítica: RTO < 1h, RPO < 15 min
• Tier 1 — Crítico: RTO 1-4h, RPO 1h
• Tier 2 — Importante: RTO 4-24h, RPO 4-12h
• Tier 3 — Padrão: RTO 24-72h, RPO 24h
• Tier 4 — Arquivamento: RTO > 72h, RPO 7 dias+

Passo 3: Validação com stakeholders

Envolva finanças, operações e diretoria. É comum que a TI estabeleça RTO otimista e a operação, ao ser consultada, ajuste para valores mais realistas. Essa conversa precisa acontecer.

Passo 4: Teste

Um RTO sem teste é suposição. Execute simulações documentadas pelo menos duas vezes por ano — veja o plano de DR template para a metodologia completa.

Tecnologias por Faixa de RTO/RPO

Tabela de RTO e RPO Recomendados por Setor

Os valores abaixo são referências de mercado baseadas em boas práticas da NIST e ISO 22301, adaptadas para a realidade das empresas brasileiras. Cada empresa deve ajustar conforme sua BIA.

Importante: esses valores são referências de mercado. Cada empresa deve fazer sua própria Análise de Impacto ao Negócio (BIA) para definir valores personalizados. O que é aceitável para uma clínica pode ser catastrófico para um hospital.

Como Calcular o RPO: Fórmula Prática

O cálculo do RPO não precisa ser complexo. A fórmula básica relaciona o valor dos dados gerados ao custo aceitável de perda:

RPO = Perda financeira aceitável / Valor dos dados gerados por hora

Exemplo prático: distribuidora de auto-peças em Belo Horizonte

Uma distribuidora com 80 funcionários processa em média 150 pedidos por hora no ERP, com ticket médio de R$ 800. Dados necessários para o cálculo:

1. Valor gerado por hora: 150 pedidos x R$ 800 = R$ 120.000/hora
2. Custo de retrabalho por pedido perdido: R$ 50 (re-entrada manual + conferência)
3. Custo de retrabalho por hora de dados perdidos: 150 x R$ 50 = R$ 7.500
4. Custo indireto (atraso na entrega, insatisfação do cliente): estimado em R$ 15.000/hora
5. Custo total por hora de dados perdidos: R$ 7.500 + R$ 15.000 = R$ 22.500
6. Perda máxima aceitável definida pela diretoria: R$ 25.000

RPO = R$ 25.000 / R$ 22.500 por hora = 1,11 horas ≈ 1 hora

Portanto, o backup do banco de dados do ERP deve rodar, no mínimo, a cada 1 hora. Na prática, recomenda-se configurar o backup a cada 30 minutos para ter margem de segurança.

Para sistemas com RPO mais agressivo

Quando o cálculo resulta em RPO de minutos (comum em bancos de dados financeiros e e-commerce), o backup incremental tradicional não é suficiente. Nesses casos, utilize:

• CDP (Continuous Data Protection): captura cada transação em tempo real. RPO próximo de zero
• Log shipping: replica logs de transação a cada poucos minutos. RPO de 5-15 minutos
• Replicação assíncrona: envia alterações em blocos periódicos. RPO de 15-60 minutos
• Replicação síncrona: RPO zero, mas exige conexão de alta velocidade entre sites

A DataBackup oferece backup incremental com frequência a partir de 15 minutos para bancos de dados, e DRaaS com replicação para sistemas que exigem RPO de minutos. Fale conosco para dimensionar a solução ideal.

Cenário Real de Desastre: Linha do Tempo com RTO e RPO

Vamos simular um cenário completo de ataque de ransomware em uma empresa de logística com 200 funcionários em Campinas-SP, para demonstrar como RTO e RPO funcionam na prática.

Contexto

A empresa opera com:

• ERP (TOTVS): RTO definido = 4 horas, RPO definido = 1 hora
• WMS (gestão de armazém): RTO definido = 2 horas, RPO definido = 30 minutos
• E-mail (Microsoft 365): RTO definido = 8 horas, RPO definido = 4 horas
• Backup: incremental a cada hora para nuvem DataBackup + cópia imutável

Linha do Tempo do Incidente

Lições Aprendidas

• O backup imutável na nuvem salvou a operação. O NAS local foi criptografado junto com os servidores — se fosse a única cópia, a empresa estaria refém dos criminosos
• RPO de 47 minutos resultou em perda tolerável: 47 minutos de pedidos (aproximadamente 50 pedidos) re-digitados em 2 horas pela equipe
• O WMS foi priorizado porque o armazém precisava abrir às 6h — a classificação por tiers de criticidade guiou a ordem de restauração
• Monitoramento proativo reduziu o tempo de detecção para 28 minutos — sem monitoramento, o incidente só seria descoberto às 8h quando os funcionários chegassem
• Após o incidente, a empresa ajustou o RPO do WMS para 15 minutos (backup a cada 15 min) para ter margem maior

Esse tipo de simulação documentada é o que a prática de teste de restauração busca validar. Sem testar, os valores de RTO e RPO definidos no papel são apenas suposições.

Checklist de Monitoramento de RTO e RPO

Definir RTO e RPO é apenas o primeiro passo. Para garantir que esses valores sejam realmente atingíveis quando necessário, monitore continuamente:

Monitoramento Diário (Automatizado)

1. Todos os jobs de backup completaram com sucesso nas últimas 24 horas?
2. O intervalo entre backups está respeitando o RPO definido para cada sistema?
3. O volume de dados transferidos está dentro do esperado (variações bruscas podem indicar problema)?
4. Os alertas de falha estão sendo recebidos pela equipe correta?
5. O espaço de armazenamento no destino de backup está dentro dos limites?

Monitoramento Semanal (Revisão Manual)

1. Houve alguma falha de backup não resolvida na semana?
2. O tempo de execução dos backups está aumentando (pode indicar crescimento de dados acima do planejado)?
3. Os logs de auditoria de acesso ao backup estão limpos (sem acessos não autorizados)?
4. As métricas de deduplicação e compressão estão estáveis?

Monitoramento Mensal (Teste de Restauração)

1. Teste de restauração executado e documentado para cada tier de criticidade?
2. O RTO real medido no teste está dentro do RTO definido?
3. O RPO real (ponto de restauração mais recente disponível) atende ao RPO definido?
4. As dependências entre sistemas foram validadas (ex: ERP depende do AD)?
5. Os procedimentos de restauração estão atualizados no plano de DR?

Monitoramento Trimestral (Revisão Estratégica)

1. Algum novo sistema foi implantado e precisa de classificação RTO/RPO?
2. O volume de dados cresceu a ponto de exigir ajuste na infraestrutura de backup?
3. Houve mudança regulatória que afeta os requisitos (ex: nova resolução BACEN, atualização LGPD)?
4. Os custos de downtime foram reavaliados (inflação, crescimento do faturamento)?
5. A política de backup reflete os RTO/RPO atuais?

A DataBackup fornece painel de monitoramento em tempo real com dashboards de conformidade de RPO e histórico de execuções. Se algum backup atrasa ou falha, o alerta é enviado automaticamente — e nossa equipe de suporte acompanha proativamente. Conheça os planos e garanta que seus RTO e RPO não sejam apenas números no papel.

Erros Comuns ao Definir RTO e RPO

Erro 1: Definir sem base em impacto financeiro

"Queremos RTO de 15 minutos para tudo" — sem validar custo. Geralmente o investimento necessário inviabiliza e ninguém executa.

Erro 2: Confundir RTO com tempo de backup

RTO inclui detecção, decisão, execução e validação. O tempo só de restauração é apenas uma parcela.

Erro 3: Ignorar dependências

De que adianta o ERP voltar em 1 hora se ele depende do AD, que demora 8 horas? A cadeia crítica define o RTO real.

Erro 4: Não testar

Sem testes, o RTO declarado é ficção. Teste trimestralmente.

Erro 5: Confundir RTO/RPO com SLA do fornecedor

O SLA do provedor cobre a disponibilidade da plataforma. Seu RTO inclui tudo do seu lado também.

RTO e RPO em Cenário de Ransomware

Em ataques de ransomware, os cálculos tradicionais ganham camadas extras. Você não pode restaurar simplesmente o último backup — o atacante pode estar na rede há semanas. O dwell time médio, segundo a Mandiant M-Trends, pode chegar a semanas. Isso significa que seu RPO efetivo pode ser muito maior que o nominal.

Por isso, soluções modernas combinam backup imutável com indexação e threat hunting retroativo, permitindo identificar o ponto de restauração verdadeiramente limpo. Veja como recuperar dados após ransomware.

RTO, RPO e PMEs

Pequenas e médias empresas frequentemente acreditam que RTO/RPO são temas "corporativos". Errado. Uma PME que fica uma semana parada pode fechar — ver disaster recovery para PMEs e backup corporativo para pequenas empresas para estratégias dimensionadas.

Próximos Passos

• Execute uma BIA simples com seus sistemas principais
• Classifique cada sistema em tiers de criticidade
• Compare o RTO/RPO necessários com sua infraestrutura atual
• Monte seu plano de DR com base nessas métricas
• Avalie DRaaS para sistemas Tier 0 e Tier 1
• Consulte o hub de disaster recovery para frameworks completos

Fale com um especialista da DataBackup via WhatsApp e receba uma análise gratuita de RTO/RPO para seus sistemas críticos.