RPO x RTO: como definir antes de comprar backup (e por que a maioria das empresas erra essa conta)

Quase toda empresa que contrata backup faz a mesma pergunta errada: "quanto custa o backup?"

A pergunta certa é outra: "quanto tempo de dado eu posso perder, e quanto tempo eu posso ficar fora do ar até recuperar?"

Essas duas respostas têm nome técnico — RPO e RTO — e são elas que definem o desenho real de uma solução de backup, não o contrário. Comprar backup sem definir RPO e RTO antes é como comprar um seguro de carro sem saber se você quer cobertura contra roubo, contra colisão ou as duas — você só vai descobrir o que comprou no dia em que precisar usar.

Neste artigo

1. O que é RPO, em termos práticos

2. O que é RTO, em termos práticos

3. Por que as duas métricas juntas é que definem o custo

4. O erro mais comum: definir RPO/RTO depois de comprar a solução

5. Como calcular RPO e RTO para o seu negócio

6. Backup não é igual a Disaster Recovery

7. A política 3-2-1 (e por que ela ainda é a base de tudo)

8. Restore testado: o passo que todo mundo pula

9. Conclusão

O que é RPO, em termos práticos {#rpo}

RPO — Recovery Point Objective responde a uma pergunta: se algo der errado agora, qual é a idade máxima aceitável do dado que eu vou recuperar?

Se o seu backup roda uma vez por dia, à meia-noite, e o sistema falha às 17h do dia seguinte, o RPO real do seu ambiente é de até 24 horas — porque a última cópia válida tem essa idade. Tudo o que foi digitado, vendido, faturado ou cadastrado entre a meia-noite e as 17h não existe em nenhuma cópia. Não é que vai demorar para recuperar — é que aquele dado específico nunca mais vai existir.

RPO é, portanto, uma decisão sobre quanto trabalho a empresa está disposta a perder e refazer manualmente (quando é possível refazer) em caso de desastre.

• RPO de 24 horas: backup diário é suficiente.

• RPO de 4 horas: backup precisa rodar a cada 4 horas, ou usar tecnologia de réplica contínua.

• RPO de minutos ou próximo de zero: exige replicação síncrona ou quase síncrona entre ambientes — uma arquitetura bem mais cara e mais complexa, tipicamente reservada a sistemas onde cada transação tem valor financeiro direto (ERP financeiro, sistemas de pagamento, bancos de dados transacionais críticos).

O que é RTO, em termos práticos {#rto}

RTO — Recovery Time Objective responde a uma pergunta diferente: depois que o desastre acontece, quanto tempo a operação pode ficar parada até voltar a funcionar?

Se o RTO definido é de 4 horas, isso significa que, entre o momento da falha e o momento em que o sistema está de volta — restaurado, validado e em produção — não podem se passar mais que 4 horas. Esse número dirige decisões de arquitetura completamente diferentes das do RPO:

• RTO de dias: restaurar a partir de um backup frio (storage externo, fita, nuvem fria) é aceitável.

• RTO de horas: exige infraestrutura de restore rápida — storage de alta performance, automação de restauração, ambiente de contingência pré-configurado.

• RTO de minutos: exige um ambiente de failover automático, com uma réplica já rodando (ou pronta para ligar quase instantaneamente) em outro local — o que é, na prática, uma arquitetura de Disaster Recovery completa, não apenas backup.

Por que as duas métricas juntas é que definem o custo {#custo}

RPO e RTO não são números isolados — eles formam uma matriz, e cada combinação tem uma arquitetura (e um custo) diferente:

O erro mais caro que se vê no mercado é a empresa pedir, sem perceber, o canto inferior direito dessa tabela ("não podemos perder nada e não podemos parar nunca") pagando o preço do canto superior esquerdo ("um backup básico, mais barato possível"). Essas duas coisas são fisicamente incompatíveis — e é função de quem desenha a solução deixar isso claro antes de fechar contrato, não depois de um incidente.

O erro mais comum: definir RPO/RTO depois de comprar a solução {#erro-comum}

A ordem natural (e errada) com que a maioria das empresas trata backup é:

1. Pesquisa-se uma ferramenta ou um plano de backup.

2. Compra-se com base em preço e espaço de armazenamento.

3. Só durante um incidente real, descobre-se: "esperávamos recuperar em 1 hora, mas o processo está levando 2 dias" ou "achávamos que tínhamos os dados de ontem, mas o último backup íntegro tem uma semana".

A ordem correta inverte completamente essa lógica:

1. Define-se o RPO e o RTO por sistema — nem todo sistema da empresa tem o mesmo nível de criticidade. O ERP financeiro pode exigir RPO de 1 hora; um servidor de arquivos administrativos pode tolerar RPO de 24 horas sem problema real.

2. Desenha-se a arquitetura de backup e/ou DR que atende a esses números — frequência de backup, tipo de armazenamento, necessidade ou não de réplica em outro site.

3. Só então se escolhe a ferramenta (Veeam, por exemplo) e se dimensiona o repositório, a banda de rede e a infraestrutura de restore.

Fazer isso ao contrário é decidir o remédio antes de saber o diagnóstico.

Como calcular RPO e RTO para o seu negócio {#calculo}

Não existe RPO/RTO "certo" universal — existe o RPO/RTO certo para cada sistema, com base em uma pergunta financeira e operacional simples: quanto custa, por hora, ficar sem aquele sistema, e quanto custa perder X horas de dado daquele sistema?

Um exercício prático, sistema por sistema:

• Liste os sistemas críticos (ERP, e-mail, banco de dados, sistema de ponto de venda, CRM, arquivos compartilhados).

• Para cada um, pergunte: "se esse sistema some agora, o que para na empresa, e quanto isso custa por hora?" — isso te dá uma pista forte do RTO aceitável.

• Para cada um, pergunte: "se eu perder as últimas X horas de dados desse sistema, o que isso significa em retrabalho ou perda real?" — isso te dá o RPO aceitável.

• Classifique os sistemas em níveis (por exemplo: crítico, importante, baixa prioridade) — porque dimensionar tudo no nível "crítico" sem necessidade real é o jeito mais rápido de pagar caro por uma proteção que o negócio não precisa.

Esse exercício, formalizado, é o que se chama de BIA — Business Impact Analysis, e é o ponto de partida de qualquer plano de continuidade de negócio sério, não só de backup.

Backup não é igual a Disaster Recovery {#backup-vs-dr}

Essa é uma confusão extremamente comum, e que vale desfazer diretamente: backup protege o dado. Disaster Recovery protege a operação.

• Backup garante que existe uma cópia recuperável dos seus dados em algum lugar, com uma certa frequência (RPO) e que pode ser restaurada em um certo tempo (RTO), mas geralmente envolve recriar ou religar a infraestrutura primeiro.

• Disaster Recovery (DR) garante que, mesmo que o site primário inteiro seja perdido (incêndio, enchente, falha estrutural, ataque de ransomware que destrói o ambiente), existe uma infraestrutura alternativa — pronta ou quase pronta — para assumir a operação, com um RTO muito mais agressivo.

Uma empresa pode ter um backup excelente e, ainda assim, não ter Disaster Recovery: se o backup está guardado, mas não existe nenhum servidor, rede ou ambiente para restaurá-lo rapidamente, o RTO real pode ser de muitos dias — mesmo com o dado intacto. É por isso que um plano de continuidade de negócio sério trata BIA, RTO/RPO, arquitetura de DR e testes de simulação como peças do mesmo processo, não como produtos isolados.

A política 3-2-1 (e por que ela ainda é a base de tudo) {#3-2-1}

Independente do RPO e RTO definidos, existe uma regra estrutural de resiliência que deveria estar presente em qualquer estratégia de backup, conhecida como regra 3-2-1:

• 3 cópias dos dados (a cópia de produção + duas cópias de backup).

• 2 tipos diferentes de mídia ou armazenamento (por exemplo, um storage local e um storage em nuvem — para não depender de um único tipo de falha).

• 1 cópia fora do site principal (off-site ou em nuvem), para sobreviver a um desastre físico que destrua o local de produção.

Uma variação mais moderna, especialmente relevante depois do crescimento de ataques de ransomware direcionados a backups, é a 3-2-1-1, adicionando 1 cópia imutável — ou seja, uma cópia que não pode ser alterada ou apagada nem por um administrador comprometido, geralmente usando WORM (Write Once, Read Many) em storage de objeto. Isso é particularmente relevante porque ataques de ransomware modernos já miram especificamente os repositórios de backup antes de criptografar a produção — sabendo que, se destruírem o backup, a vítima fica sem alternativa além de pagar o resgate.

Restore testado: o passo que todo mundo pula {#restore-testado}

Esse é, possivelmente, o ponto mais negligenciado em toda a discussão de backup: um backup que nunca foi restaurado em teste é uma suposição, não uma garantia.

É extremamente comum — mais do que se imagina — uma empresa descobrir, no momento real de um incidente, que:

• O backup estava rodando, mas pulando arquivos específicos por permissão.

• O backup do banco de dados estava sendo feito em modo inconsistente (sem aplicação de log de transação), tornando a restauração corrompida.

• O processo de restore documentado estava desatualizado, referenciando um servidor que não existe mais.

• O tempo real de restauração é o triplo do RTO contratado, porque ninguém tinha medido isso na prática.

Um programa de Backup como Serviço (BaaS) maduro inclui, como rotina — não como exceção — testes periódicos de restauração, validando não só que o backup "existe", mas que ele efetivamente volta a funcionar dentro do RTO esperado. Isso deveria ser tão rotineiro quanto o próprio backup, com relatório formal de cada teste.

Conclusão {#conclusao}

A pergunta "quanto custa o backup" só pode ser respondida depois de responder duas outras: quanto dado eu posso perder, e quanto tempo eu posso ficar parado.

Esses dois números — RPO e RTO — não são jargão técnico decorativo. Eles são a especificação real do que está sendo comprado. Sem eles definidos antes da contratação, a empresa só vai descobrir o que comprou no piorr momento possível: durante o incidente, quando já é tarde para negociar.

A Nyverra estrutura políticas de backup e disaster recovery a partir do RPO/RTO real de cada sistema do seu negócio — com restore testado, retenção adequada e relatórios que comprovam, com dado, que a proteção contratada funciona. Conheça a solução de Backup Veeam empresarial em nyverra.com.br/pt-br/backup-veeam-empresarial.