O que é RPO (Recovery Point Objective)?
RPO (Recovery Point Objective, ou ponto de recuperação) é a quantidade máxima de dados que uma empresa aceita perder, medida em tempo. Se o RPO é de uma hora, o backup precisa ser recente o bastante para que, no pior caso, só se percam os dados da última hora. É a resposta para a pergunta “quanto de trabalho podemos refazer se tudo cair agora?”.
Como o RPO funciona na prática
O RPO liga uma decisão de negócio (quanto dado dá para perder) a uma decisão técnica (de quanto em quanto tempo o backup roda). Um define o outro.
Definir a tolerância do negócio
Cada tipo de dado tem um limite: um sistema de vendas não pode perder uma hora; um arquivo de referência talvez aceite um dia. Esse limite é o RPO.
Traduzir em frequência de backup
O RPO define de quanto em quanto tempo a cópia precisa acontecer. RPO de 15 minutos exige backup a cada 15 minutos, não uma vez por dia.
Medir a distância até a última cópia
No momento da falha, o dado perdido é tudo o que mudou desde o último ponto de backup. Quanto maior o intervalo, maior a perda.
Ajustar por criticidade
Nem tudo precisa do mesmo RPO. Definir por sistema evita pagar por proteção contínua onde ela não é necessária, e evita perder dados onde ela é.
Fontes: NIST SP 800-34 Rev. 1 e ISO 22301 (continuidade de negócio).
RPO por tipo de dado
- Transacional, quase zero Vendas, pedidos, financeiro e banco de dados de produção: cada minuto é dinheiro e obrigação. Pedem RPO de minutos, com cópia contínua ou quase.
- Operacional, algumas horas Arquivos de trabalho, e-mail e sistemas internos: refazer meia manhã dói, mas não para a empresa. RPO de poucas horas costuma servir.
- De referência, um dia Documentos que mudam pouco, históricos e materiais estáveis: um RPO diário é suficiente e mais barato de manter.
- Regulatório, sem lacuna Dados sob exigência legal de guarda podem precisar de RPO curto e retenção longa ao mesmo tempo, por obrigação, não só por conveniência.
Por que o RPO decide quanto você perde
O RPO não é jargão técnico, é a medida do dano invisível de uma parada. Uma empresa que faz backup uma vez por dia tem, na prática, um RPO de 24 horas: se o sistema cai às 17h, todo o trabalho desde a cópia da madrugada pode sumir. É por isso que a maioria das organizações admite uma lacuna entre a recuperação que tem e a que o negócio precisa (Veeam, 2024), e por que só parte delas consegue restaurar seguindo o plano que estava no papel. Definir o RPO por sistema, e sustentá-lo com backup na frequência certa, é o que transforma “perdemos o dia inteiro” em “perdemos alguns minutos”. Ao lado dele anda o RTO, que mede o tempo até voltar.
Como definir o RPO da sua empresa
Definir o RPO é uma conversa de negócio antes de ser técnica. Quatro passos deixam isso concreto:
- Liste os sistemas por criticidadeSepare o que para a empresa se sumir uma hora do que só incomoda. O RPO nasce dessa classificação.
- Pergunte quanto trabalho dá para refazerPara cada sistema, quanto tempo de dado a equipe conseguiria reconstruir na mão? Esse é o teto do RPO.
- Case a frequência do backup ao RPOA cópia precisa rodar dentro da janela do RPO. RPO de uma hora com backup diário é uma promessa que não se cumpre.
- Revise quando o negócio mudaMais volume, mais clientes ou uma nova obrigação legal encurtam o RPO. Ele não é definido uma vez e esquecido.
Na prática
RPO olha para trás (quanto dado se perde); RTO olha para frente (quanto tempo até voltar). Definir os dois por sistema é o que torna a continuidade um número, não uma esperança.
Como a Zamak trata o RPO
A Zamak Technologies define o RPO junto com o cliente, por sistema e por criticidade, e sustenta cada meta com backup na frequência certa e teste de recuperação. Para dimensionar o que uma parada custa e qual RPO se justifica, um bom ponto de partida é a calculadora de custo de inatividade. Faz parte da Continuidade do Método Zamak.