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.

8. Técnicas para RPO baixo

• Binlog do MySQL / WAL do PostgreSQL — permite restaurar até um ponto exato no tempo (point-in-time recovery), não só até o último backup completo.
• Réplica em standby (streaming replication) — RPO praticamente zero, mas exige infraestrutura de banco redundante; é solução de alta disponibilidade, não substitui backup.
• Backup incremental frequente com ferramenta deduplicada (restic/Borg) — viável de rodar de hora em hora sem consumir espaço proporcional, já que só grava a diferença real.

Exemplo prático — habilitar binlog no MySQL do banco RADIUS:

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin.log
binlog_expire_logs_seconds = 604800   # retém 7 dias de binlog

# Restauração point-in-time (dump full + replay do binlog até o instante exato):
mysql < backup-full-2026-08-05.sql
mysqlbinlog --stop-datetime="2026-08-05 14:32:00" mysql-bin.000123 | mysql

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

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

10. 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.

11. Planilha de definição de RPO

12. 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. Custo de armazenamento off‑site (S3) para diferentes RPOs, com 30 dias de retenção:

Com deduplicação (90%+ em backups incrementais de bancos de dados), os volumes reais podem ser até 10× menores. O verdadeiro custo está na carga de I/O e rede, não no armazenamento.

13. 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, evitando RPO "fantasma".

14. RPO × RTO — não são a mesma coisa

15. Checklist operacional

16. Mitos comuns sobre RPO

17. Glossário

18. 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).
• Documentação oficial MySQL — Point-in-Time Recovery (binlog).
• Páginas relacionadas: RTO, Regra 3-2-1(-1-0), LGPD.

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