RPO — Recovery Point Objective

1. Definição e fundamentação normativa

RPO (Recovery Point Objective) é a quantidade máxima de dados que uma organização aceita perder em caso de incidente, medida em tempo. Em outras palavras: se o pior acontecer agora, qual é o ponto no passado para o qual você precisa conseguir restaurar?

Assim como o RTO, o RPO é um conceito formal de continuidade de negócios, definido em frameworks como o NIST SP 800-34 e a ISO 22301. Ele é a base para determinar a frequência dos backups e o tipo de replicação necessário.

2. RPO não é frequência de backup — entenda a diferença

Um erro comum é confundir "eu faço backup a cada 1 hora" com "meu RPO é 1 hora". O RPO é o pior caso de perda de dados, não a média. Se o backup horário falhar às 10:00 e o próximo só rodar com sucesso às 12:00, o RPO real foi de 2 horas — o dobro do declarado.

Portanto, RPO efetivo = intervalo entre backups bem-sucedidos consecutivos. Para garantir um RPO de 1 hora, a frequência de backup deve ser menor que 1 hora (ex.: a cada 45 minutos) e cada execução deve ser validada quanto ao sucesso.

3. Exemplos reais por criticidade de sistema (ISP)

4. Como medir o RPO real

O RPO declarado só vale se for medido. O script abaixo verifica a "idade" do backup mais recente e compara com o RPO máximo aceitável. Pode ser integrado ao monitoramento (Zabbix/PRTG).

#!/bin/bash
# check_rpo.sh — verifica se o último backup está dentro do RPO
RPO_MINUTOS=15
ULTIMO_BACKUP=$(restic snapshots --latest 1 --json | jq -r '.[0].time')
SEGUNDOS_DESDE_BACKUP=$(( $(date +%s) - $(date -d "$ULTIMO_BACKUP" +%s) ))
MINUTOS_DESDE_BACKUP=$(( SEGUNDOS_DESDE_BACKUP / 60 ))

if [ $MINUTOS_DESDE_BACKUP -gt $RPO_MINUTOS ]; then
  echo "CRITICAL: último backup tem $MINUTOS_DESDE_BACKUP min (RPO: ${RPO_MINUTOS} min)"
  exit 2
else
  echo "OK: último backup tem $MINUTOS_DESDE_BACKUP min"
  exit 0
fi

Adapte restic snapshots para borg list --last 1 ou bconsole conforme sua ferramenta. O importante é que o script valide o tempo desde o último backup bem‑sucedido, não desde a última tentativa.

5. Impacto das ferramentas no RPO

A ferramenta de backup influencia o RPO de duas formas: velocidade de execução (backups mais rápidos permitem maior frequência) e eficiência de armazenamento (incrementais pequenos viabilizam RPOs baixos sem sobrecarregar disco/rede).

Para RPOs abaixo de 5 minutos, o backup tradicional (mesmo incremental) pode não ser suficiente — é necessário partir para replicação contínua (ex.: MySQL com binary log shipping, ou DRBD).

6. Simulação: RPO declarado × RPO real

O cenário abaixo mostra como um RPO declarado de 1 hora pode se tornar um RPO efetivo de 3 horas se as falhas não forem monitoradas.

RPO declarado: 1 hora (intervalo agendado).
RPO efetivo medido: 2,5 horas (das 08:00 às 10:30).

A diferença é que ninguém validava o sucesso do backup. O script da seção 4 teria detectado a falha às 09:00 e evitado o estouro do RPO.

7. RPO e ransomware — o problema do “último backup limpo”

Ransomware moderno frequentemente opera de forma silenciosa por dias ou semanas antes de se revelar, criptografando ou corrompendo dados aos poucos. Quando o ataque é finalmente detectado, o último backup "limpo" pode estar muito mais distante do que o último backup agendado.

Exemplo realista:

• Backups incrementais são feitos a cada 1 hora (RPO declarado = 1 hora).
• O invasor começa a corromper dados silenciosamente há 3 dias.
• Todos os backups dos últimos 3 dias contêm dados corrompidos ou backdoors.
• O último backup íntegro é de 4 dias atrás — o RPO efetivo, nesse cenário, é de 96 horas, não 1 hora.

Mitigação: a regra 3‑2‑1‑1‑0 resolve isso com o “+1” imutável e o “0” de testes de restauração. Manter snapshots imutáveis de longo prazo (ex.: 1 snapshot semanal retido por 3 meses) garante que sempre exista um ponto de recuperação anterior ao início do ataque. Além disso, testes periódicos de restauração (não só de integridade) ajudam a identificar corrupção antes que ela se propague por toda a cadeia de backups.

8. Trade‑offs: quanto menor o RPO, maior o custo

Reduzir o RPO não é gratuito. Cada redução implica em mais recursos:

• Mais I/O no servidor de produção — backups frequentes competem com a carga normal.
• Mais tráfego de rede — se o backup é off‑site, cada incremental consome banda.
• Mais armazenamento — snapshots mais frequentes ocupam mais espaço (mesmo com dedup).
• Maior complexidade operacional — replicação contínua exige monitoramento mais fino.

A decisão de RPO deve equilibrar o custo da perda de dados (financeiro, reputacional, jurídico) com o custo da infraestrutura para atingir aquele RPO. Um banco RADIUS que processa 100 autenticações/minuto justifica RPO de 5 min? Provavelmente sim. Um servidor de logs internos justifica RPO de 24h? Também.

9. RPO, LGPD e Marco Civil — a implicação legal

O Art. 46 da LGPD exige medidas de proteção contra perda de dados pessoais. Um RPO mal dimensionado que resulte em perda de dados de clientes pode ser interpretado como falha nessa obrigação. Além disso, o Marco Civil da Internet (Lei 12.965/2014, Art. 13) obriga provedores a manter registros de conexão por 1 ano. Isso significa que:

• Não basta ter backup — o backup precisa garantir que você não perca registros dentro do período obrigatório.
• Se o RPO do sistema de logs é 24h, mas ocorre um incidente que destrói 48h de dados, você perdeu 2 dias de registros obrigatórios — dupla infração (LGPD + Marco Civil).
• A retenção mínima de 1 ano impacta diretamente a política de forget/prune das ferramentas: não se pode descartar snapshots que contenham logs de conexão antes de 365 dias.

10. Planilha de definição de RPO

Preencha para cada sistema crítico. O RPO declarado deve ser validado com medição (seção 4).

11. Exemplo de dimensionamento — custo do RPO para um ISP

Suponha o banco RADIUS de um ISP com 5.000 clientes, gerando ~50 MB de dados incrementais por hora. Vamos calcular o custo de armazenamento off‑site (S3) para diferentes cenários de RPO, mantendo 30 dias de retenção:

Com deduplicação (90%+ em backups incrementais de bancos de dados), os volumes reais podem ser até 10× menores. Ainda assim, o custo de armazenamento para RPOs baixos é irrisório comparado ao risco de perda de dados de bilhetagem. O verdadeiro custo está na carga de I/O e rede para executar backups a cada 15 minutos.

12. Como reduzir o RPO na prática

• Aumentar a frequência de backups incrementais — restic e Borg fazem incrementais em segundos; agende a cada 15 min se necessário.
• Replicar o banco de dados em tempo real — MySQL com binary log ou PostgreSQL com streaming replication para RPO próximo de zero.
• Usar storage local rápido (SSD/NVMe) — reduz o tempo do backup e permite executá‑lo mais vezes sem impactar a produção.
• Automatizar a validação de sucesso — scripts que confirmam que o backup realmente foi concluído (seção 4), evitando RPO "fantasma".

13. Checklist operacional

14. Mitos comuns sobre RPO

15. Glossário

16. Referências

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (definições de RPO/RTO).
• ISO 22301:2019 — Business continuity management systems — Requirements.
• Lei nº 12.965/2014 (Marco Civil da Internet) — Art. 13 (obrigação de guarda de registros).
• CISA — #StopRansomware Guide (justificativa para backups imutáveis e testes periódicos).
• Páginas relacionadas: RTO, Regra 3-2-1(-1-0), LGPD, restic, Borg, Bacula.

Conteúdo técnico independente. Nenhum trecho é cópia literal das fontes citadas.