RPO e RTO: defina antes do próximo ransomware

No dia em que o ransomware criptografa seus servidores, ninguém quer descobrir, ao vivo, quanto da operação dá para recuperar e em quanto tempo. Essas duas respostas têm nome: RPO e RTO. São números que você define antes — com calma, sobre a mesa — ou números que o incidente define por você, no pior momento possível.

Este texto explica os dois conceitos sem rodeio, mostra a regra de backup que ainda vale (a 3-2-1), e por que uma transportadora — que não pode ficar um dia sem emitir CT-e nem rastrear carga — precisa pensar nisso de um jeito específico. Definições limpas, do jeito que você vai querer ter lido antes.

RPO (Recovery Point Objective) é a quantidade máxima de dados que sua operação aceita perder, medida em tempo. Se o seu RPO é de 1 hora, significa que, depois de restaurar, você pode ter perdido até a última hora de trabalho — e isso é aceitável. Se o RPO é de 24 horas, você pode voltar para a foto de ontem de manhã.

Na prática, o RPO define de quanto em quanto tempo você faz backup. Não dá para ter RPO de 15 minutos com backup uma vez por dia — a matemática não fecha. Quanto menor o RPO, mais frequente (e mais caro) o backup.

A pergunta que destrava a definição é direta: se eu perdesse tudo que entrou no sistema desde o último backup, quanto isso me custaria? Para um CT-e emitido e não salvo, o custo é refazer a digitação e arriscar inconsistência fiscal. Para um romaneio de carga, é não saber o que entrou no caminhão.

RTO (Recovery Time Objective) é o tempo máximo que sua operação aguenta ficar parada antes de a restauração estar concluída e o sistema voltar a funcionar. Se o RTO é de 4 horas, você tem 4 horas, do incidente até a operação rodando de novo — não um minuto a mais.

RTO não é só o tempo de copiar arquivos de volta. É o relógio inteiro: detectar o problema, isolar o que foi comprometido, achar um backup limpo, restaurar, validar que está íntegro e religar. Quem só cronometra a cópia descobre tarde demais que validar e religar levam mais tempo que o esperado.

A pergunta aqui é de dinheiro: quanto custa cada hora parada? Para uma transportadora, hora parada é entrega atrasada, multa de SLA, caminhão na fila sem nota e cliente ligando. Esse custo por hora é o que justifica — ou não — investir em recuperação mais rápida.

É comum confundir. A forma simples de separar:

• RPO olha para trás — quanto de dado, no passado, você aceita perder.
• RTO olha para a frente — quanto tempo, a partir de agora, você aceita ficar parado.

Um sistema pode ter RPO ótimo e RTO péssimo: você não perde quase nada, mas leva três dias para religar. Ou o contrário: religa em 20 minutos, mas voltou para a foto da semana passada. Os dois precisam fazer sentido juntos, para cada sistema. O ERP fiscal pede RPO e RTO apertados. Um data warehouse de BI, que se reconstrói a partir das fontes, aguenta números mais folgados.

RPO e RTO só existem se houver backup de verdade para restaurar. A regra que ainda organiza isso é a 3-2-1:

• 3 cópias dos seus dados (a original mais duas).
• 2 mídias ou tecnologias diferentes (não as duas no mesmo disco, no mesmo servidor).
• 1 cópia fora do site — offline ou imutável, que o ransomware não consegue alcançar nem apagar.

O detalhe que mais cai por terra é o "1". Backup que fica no mesmo servidor, ou num NAS montado na rede, é criptografado junto com o resto no dia do ataque. Ransomware moderno procura e destrói backups primeiro, justamente para forçar o resgate. Por isso a cópia externa precisa ser imutável (write-once, que ninguém regrava) ou genuinamente desconectada. Sem esse "1", a regra inteira não te salva.

Esta é a frase que mais dói depois de um incidente. Uma rotina de backup que roda todo dia, gera arquivo, marca verde no painel — e nunca foi restaurada — é uma suposição, não uma garantia. No dia do ataque é que muita gente descobre que o arquivo estava corrompido, que faltava a base de dados certa, ou que a restauração leva o triplo do tempo planejado.

Backup só vira backup quando você testa a restauração de verdade, num ambiente separado, e cronometra. Esse teste responde, com fato e não com fé, se o seu RTO é real e se o RPO bate com a frequência configurada. Recomendação concreta: um teste de restauração documentado a cada trimestre, e sempre que mudar algo grande no sistema.

Uma transportadora não tem o luxo de um RTO de "alguns dias". Sem ERP, não há emissão de CT-e nem MDF-e — caminhão não sai do pátio sem documento fiscal. Sem rastreamento, você perde a posição da frota e a visibilidade da carga em trânsito. Cada hora parada vira multa de SLA, entrega atrasada e telefone tocando.

Como pensar isso na prática:

• Separe os sistemas por criticidade. Emissão fiscal e rastreamento (SASCAR, Autotrac, Omnilink) pedem RTO de horas e RPO baixo. Relatórios de BI aguentam mais.
• Frequência de backup que case com o RPO. Se você aceita perder no máximo 1 hora de notas, o backup do banco fiscal não pode ser diário.
• Uma cópia imutável e fora do site — o ransomware que pega o ERP não pode alcançar o backup dele.
• Teste de restauração cronometrado, para saber se em 4 horas você realmente volta a emitir documento.

O objetivo é simples: que o sequestro de dados seja um transtorno de horas, não uma parada de dias — e que pagar resgate nunca seja a única saída na mesa. É privacidade e continuidade por design, não por remendo.