O que é RPO e quanto dado a empresa pode perder?

Como o RPO funciona na prática?

Imagine um sistema de gestão (ERP) com backup diário às 23 horas. Se o armazenamento falhar às 18 horas do dia seguinte, tudo o que foi lançado nas últimas 19 horas não estará na cópia. Nesse desenho, o RPO real chega perto de 24 horas, porque o pior momento para falhar é logo antes do próximo backup.

Por isso, o RPO deve ser calculado pelo pior caso, não pela média. Se a área financeira aceita perder no máximo quatro horas de lançamentos, os pontos de recuperação precisam ser criados em intervalos menores que esse, considerando também o tempo que cada cópia leva para terminar e chegar ao local de armazenamento.

Um detalhe faz muita diferença: vale o último ponto concluído e utilizável, não o agendado. Se a cópia do meio-dia falhou e ninguém percebeu, o ponto disponível pode ser o das 8 horas. O RPO previsto no papel deixa de existir sem que a empresa saiba.

Quais tecnologias ajudam a reduzir o RPO?

Cada técnica permite uma faixa diferente de perda. A escolha depende do valor do dado e do orçamento disponível.

• Backup agendado: cria pontos em intervalos definidos, como a cada poucas horas ou uma vez por dia. Atende bem sistemas em que reconstruir algumas horas de trabalho é aceitável.
• Snapshots: registram o estado de um volume ou de uma máquina virtual em um instante. São rápidos, mas costumam ficar no mesmo armazenamento de produção e não substituem uma cópia separada.
• Backup de logs de transação: em bancos de dados, permite restaurar até um momento específico, com intervalos bem menores que os do backup completo.
• Replicação: mantém uma cópia atualizada em outro equipamento ou local. Na forma assíncrona, o atraso fica, em geral, na casa dos segundos ou minutos. A replicação síncrona chega perto de perda zero, mas exige conexão de baixa latência e custa mais.
• Proteção contínua de dados (CDP): registra as alterações de forma contínua e permite escolher pontos de recuperação muito próximos entre si.

Replicação reduz o RPO, mas também copia o erro. Uma exclusão acidental ou arquivos criptografados por ransomware chegam à réplica quase no mesmo instante. Por isso, ela costuma ser combinada com backup versionado e, de preferência, com backup imutável.

Quais erros são comuns ao definir o RPO?

• Um único RPO para a empresa toda. Uma hora de dados perdidos no comércio eletrônico não tem o mesmo peso que uma hora no arquivo de contratos antigos. Classificar os sistemas por criticidade evita gastar demais onde não precisa e economizar onde não deveria.
• Esquecer os serviços em nuvem. Dados em aplicações SaaS, como e-mail e arquivos colaborativos, também precisam de um RPO definido, mesmo quando o fornecedor cuida da infraestrutura.
• Ignorar o cenário de ransomware. Em um ataque, o último ponto limpo pode ser bem mais antigo que o último backup, porque o invasor pode ter agido dias antes da criptografia. Manter versões por tempo suficiente faz parte do planejamento.
• Definir o RPO sem ouvir quem usa o sistema. Só a área de negócio sabe se duas horas de pedidos podem ser redigitadas a partir de documentos, e-mails ou outro sistema.

Como acompanhar se o RPO está sendo cumprido?

O indicador mais direto é a idade do último ponto recuperável válido de cada sistema. Se o RPO do ERP é de quatro horas e o último backup bem-sucedido tem cinco, a meta já foi descumprida, mesmo sem nenhum incidente.

Na prática, isso exige alertas para falhas de backup e de replicação, relatórios periódicos por sistema e testes de restauração que confirmem a integridade dos dados. Um painel que mostra apenas tarefas concluídas pode esconder cópias corrompidas ou incompletas.

Os resultados devem ser revistos junto com o RTO e com o plano de continuidade de negócios. Quando o objetivo é descumprido com frequência, a empresa precisa escolher entre investir na proteção ou formalizar um RPO menos exigente para aquele sistema.