RPO (Recovery Point Objective) e RTO (Recovery Time Objective) são os dois indicadores fundamentais que determinam quanto a sua empresa pode perder em caso de pane ou desastre tecnológico. O RPO mede a quantidade máxima de dados que o negócio tolera perder medida em tempo (por exemplo: perder as últimas 2 horas de vendas), enquanto o RTO define quanto tempo os sistemas podem ficar fora do ar até serem restabelecidos (por exemplo: voltar a operar em até 4 horas). Definir esses dois parâmetros com clareza é o primeiro passo para dimensionar a infraestrutura de TI sem desperdiçar orçamento nem expor a operação a riscos fatais.
RPO: Quanto de dados a empresa suporta perder?
O Recovery Point Objective (Objetivo de Ponto de Recuperação) olha para o passado a partir do momento em que a falha aconteceu. Ele responde à seguinte pergunta: "Até qual momento no tempo precisamos restaurar as informações para que o negócio continue funcionando?"
Imagine que o servidor de banco de dados da sua empresa sofre uma quebra irreversível às 16h00 de uma terça-feira:
- Se a sua rotina de backup é executada apenas uma vez por dia, à meia-noite, a restauração trará os dados exatamente como estavam às 00h00.
- Todas as notas fiscais emitidas, pedidos cadastrados, baixas de estoque e e-mails recebidos entre 00h00 e 16h00 serão simplesmente perdidos.
- Nesse caso, o RPO real da sua empresa foi de 16 horas de perda de dados.
Se a sua operação é um escritório de consultoria, talvez perder algumas horas de digitação seja tolerável refazendo o trabalho. Porém, em uma distribuidora ou e-commerce, perder 16 horas de transações significa prejuízo financeiro direto, retrabalho fiscal e quebra de contratos com clientes.
RTO: Quanto tempo a empresa aguenta ficar parada?
O Recovery Time Objective (Objetivo de Tempo de Recuperação) olha para o futuro a partir do instante da queda. Ele responde à pergunta: "Quanto tempo a equipe de tecnologia tem para colocar os sistemas operacionais de novo antes que o prejuízo se torne inaceitável?"
Continuando o exemplo da quebra às 16h00:
- O backup das 00h00 está salvo com segurança em um disco remoto.
- No entanto, a equipe precisa comprar peças novas, reinstalar o sistema operacional, baixar 2 Terabytes de dados pela internet e reindexar o banco de dados.
- Se esse processo levar 24 horas para ser concluído, os funcionários e clientes ficarão sem sistema até as 16h00 do dia seguinte.
- O RTO da empresa foi de 24 horas de paralisação total.
A relação direta entre exigência e investimento
Não existe um valor único de RPO e RTO que sirva para todas as empresas. A definição é uma decisão estritamente de negócio, e não apenas técnica, baseada no custo da inatividade versus o custo da proteção:
| Perfil de RPO / RTO | Cenário Típico de Tolerância | Tecnologia de TI Necessária | Custo de Implementação |
|---|---|---|---|
| RPO: 24h / RTO: 24-48h | Arquivos administrativos, projetos sem urgência | Backup diário agendado, com cópia fora do local | Baixo |
| RPO: 1h / RTO: 2-4h | Sistemas de ERP, CRM, faturamento comercial | Snapshots por hora, replicação de VMs | Médio |
| RPO: < 15 min / RTO: < 30 min | E-commerce, logística crítica, call centers | Replicação contínua de storage em nuvem | Médio-Alto |
| RPO: Zero / RTO: Zero | Setor financeiro, hospitais, bolsas | Cluster de alta disponibilidade ativo-ativo | Alto |
Como estabelecer suas metas na prática
Para definir o RPO e RTO da sua organização sem sobrecarregar o orçamento:
- Classifique os sistemas por criticidade: separe o servidor do ERP de emissão de notas (crítico) do servidor de arquivos antigos ou intranet (secundário).
- Calcule o custo da hora parada: some o faturamento que deixa de entrar por hora, o custo de salário por hora dos colaboradores ociosos e as penalidades contratuais.
- Alinhe a tecnologia às metas: se a diretoria determina que o ERP não pode parar por mais de 2 horas (RTO = 2h), a TI não pode depender de restaurações lentas de fitas ou downloads lentos de nuvem pública sem um servidor reserva pré-configurado.
- Realize simulados de recuperação: meça no cronômetro quanto tempo a equipe leva para restaurar um backup real em ambiente de teste para validar se o RTO contratado é viável.
Precisa de ajuda?
Para auditar o tempo de recuperação e a política de continuidade de sistemas da sua empresa, conheça nossas arquiteturas de resiliência na página de arquiteturas.
Fontes
- https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final — NIST Special Publication 800-34 Rev. 1, Guia de Planejamento de Contingência para Sistemas de Informação. (consultado em 2026-10-05)
- https://www.iso.org/standard/75106.html — Norma internacional ISO 22301 sobre Sistemas de Gestão de Continuidade de Negócios. (consultado em 2026-10-05)