Disaster Recovery: RTO e RPO que sua empresa precisa definir

O que sao RTO e RPO e por que eles definem a sobrevivencia do seu negocio

Quando um desastre de TI atinge uma empresa — seja ransomware, falha de hardware, erro humano ou catastrofe fisica — duas metricas determinam se ela sobrevive ou fecha as portas: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Segundo estudo da Uptime Institute de 2025, 60% das empresas que sofrem uma interrupcao superior a 24 horas sem plano definido encerram atividades em ate dois anos. Nao e exagero: o custo medio de downtime em empresas brasileiras de medio porte chega a R$ 38 mil por hora, conforme levantamento da IDC Brasil.

O RTO responde a pergunta "quanto tempo podemos ficar fora do ar?" — e o tempo maximo tolerado entre o desastre e a restauracao completa dos servicos criticos. Ja o RPO responde "quanto dado podemos perder?" — e a janela maxima de dados que a empresa aceita perder entre o ultimo backup valido e o momento do incidente. Um RPO de 1 hora significa que, no pior cenario, sua empresa perde no maximo 60 minutos de transacoes, emails, documentos ou registros.

Essas duas metricas nao sao tecnicas abstratas — sao decisoes de negocio que precisam envolver diretoria, financeiro, juridico e operacoes. Definir um RTO de 4 horas para um ERP custa significativamente diferente de definir 15 minutos. E escolher errado pode significar tanto superinvestimento em infra desnecessaria quanto prejuizo irreparavel quando o desastre chega.

Como calcular o RTO ideal para cada sistema da sua empresa

O primeiro erro comum e aplicar o mesmo RTO para toda a infraestrutura. Um servidor de arquivos interno nao precisa do mesmo SLA de recuperacao que o sistema de faturamento ou o e-commerce. O calculo correto parte de uma analise de impacto no negocio (BIA — Business Impact Analysis), que mapeia cada sistema contra tres variaveis: perda financeira por hora parada, impacto regulatorio/contratual e impacto reputacional.

Considere um exemplo pratico de uma industria brasileira com faturamento anual de R$ 80 milhoes. O ERP processa em media R$ 220 mil por dia util. Se cair por 8 horas, a perda direta e de aproximadamente R$ 73 mil — mas o custo indireto (multas contratuais com fornecedores JIT, pedidos cancelados, horas extras de recuperacao manual) pode triplicar esse valor. Nesse cenario, um RTO de 2 horas com replicacao sincrona faz sentido economico. Ja o servidor de intranet pode tolerar RTO de 24 horas sem prejuizo relevante.

Para classificar seus sistemas, use esta matriz de tiers:

• Tier 0 — Critico absoluto (RTO < 15 min): sistemas que, parados, causam perda financeira imediata ou risco a vida. Exemplos: sistemas medicos, bolsa, trading, pagamentos em tempo real.
• Tier 1 — Alta criticidade (RTO 1-4 horas): ERP, CRM, e-commerce, sistemas de producao, bancos de dados transacionais principais.
• Tier 2 — Media criticidade (RTO 4-24 horas): servidores de arquivos, sistemas de BI, ambientes de homologacao com dependencia operacional.
• Tier 3 — Baixa criticidade (RTO 24-72 horas): intranet, wikis internos, ambientes de desenvolvimento, arquivos historicos.

Essa classificacao precisa ser revisada a cada 12 meses ou sempre que houver mudanca relevante no modelo de negocio — uma migracao para e-commerce, por exemplo, eleva o site institucional de Tier 3 para Tier 1 da noite para o dia.

RPO: quantos minutos de dados sua empresa realmente aceita perder

O RPO e o gemeo tecnico do RTO, mas costuma ser mais dificil de dimensionar porque envolve projecoes sobre volume transacional e capacidade de reconstrucao manual. Empresas que operam com backup diario as 23h possuem RPO efetivo de 24 horas — ou seja, se o ransomware encripta tudo as 22h59, perdem um dia inteiro de trabalho. Para muitas operacoes, isso e catastrofico.

"RPO nao e uma decisao de TI, e uma decisao de diretoria. Quando explico para o CEO que seu RPO atual e 24h e pergunto quantas vendas entram por dia, a conversa muda de tom rapidamente." — analise recorrente em projetos de consultoria em continuidade de negocios.

As tecnologias disponiveis hoje permitem RPOs muito mais agressivos do que ha dez anos. Snapshots incrementais a cada 15 minutos, replicacao assincrona continua entre data centers e CDP (Continuous Data Protection) com RPO de segundos sao realidade acessivel ate para empresas de medio porte. O que mudou nao foi apenas a tecnologia — foi o custo: replicacao para nuvem saiu de dezenas de milhares de reais/mes para faixas viaveis entre R$ 800 e R$ 4.500 para a maioria das PMEs brasileiras.

Na hora de definir RPO, responda a estas perguntas objetivas para cada sistema: quanto custaria reconstruir manualmente 1 hora, 4 horas, 24 horas de operacao? Quantos funcionarios seriam necessarios? Existem dados que simplesmente nao podem ser reconstruidos (registros de sensores, logs de auditoria, transacoes de clientes externos)? A resposta define se seu RPO precisa ser de minutos, horas ou pode ser de um dia.

Arquitetura tecnica: como implementar RTO e RPO na pratica

Definir metricas no papel e facil. Entregar na pratica exige arquitetura apropriada. Para RTOs acima de 24 horas, backup tradicional em fita ou disco com retencao semanal ainda funciona. Abaixo disso, a estrategia precisa escalar em complexidade e custo. A regra 3-2-1-1-0 continua sendo o padrao minimo em 2026: 3 copias dos dados, em 2 midias diferentes, 1 copia offsite, 1 copia imutavel (air-gap ou object lock) e 0 erros de verificacao.

Para RTO de 1-4 horas com RPO de 15 minutos a 1 hora, a combinacao padrao hoje envolve:

1. Backup primario local com snapshots incrementais a cada 15 minutos (ex: Veeam, Rubrik, Commvault).
2. Replicacao assincrona para um site secundario ou nuvem, garantindo recuperacao mesmo em desastre fisico total.
3. Copia imutavel com retencao de 30-90 dias, protegida contra ransomware que tenta apagar backups.
4. Runbook automatizado de failover — scripts testados que restauram sistemas sem depender de memoria humana em situacao de crise.
5. Testes trimestrais de restauracao reais, nao apenas verificacao de checksums. Um backup que nunca foi restaurado nao e um backup, e uma esperanca.

Para Tier 0 com RTO de minutos, a arquitetura muda para replicacao sincrona (RPO zero) entre data centers geograficamente separados, com balanceadores de carga globais capazes de promover o site secundario automaticamente quando detectam falha do primario. Esse tipo de configuracao exige links dedicados de baixa latencia (<5ms) e compatibilidade com aplicacoes stateless ou bancos de dados com replicacao nativa como PostgreSQL streaming replication ou SQL Server Always On.

Testes de disaster recovery: o que ninguem te conta

A estatistica mais perturbadora do setor vem do Gartner: 65% das empresas que investem em disaster recovery nunca testaram o plano completo. Das que testaram, 40% descobriram falhas criticas que invalidariam a recuperacao em um desastre real. Ter RTO definido de 2 horas no contrato nao significa absolutamente nada se o processo nunca foi executado do inicio ao fim.

Os testes precisam ser estruturados em niveis progressivos. O tabletop exercise e a simulacao mais basica — equipe reunida discutindo "o que fariamos se". Util para alinhar processos, mas nao valida tecnologia. O teste parcial (partial failover) promove alguns sistemas ao ambiente de DR enquanto a producao principal continua ativa. Valida tecnologia mas nao exercita toda a cadeia. O teste completo (full failover) desliga o ambiente primario e opera por um periodo real sobre o site de DR — esse e o unico teste que valida RTO e RPO de verdade, e deve ser executado ao menos uma vez por ano.

Durante os testes, documente rigorosamente: tempo real de deteccao, tempo de decisao para acionar o plano, tempo de execucao do runbook, tempo de validacao com usuarios chave, tempo total ate producao estavel. Somados, esses tempos precisam caber dentro do RTO contratado. Na maioria dos primeiros testes, descobrimos RTO real 2-3x maior que o planejado — e bom descobrir isso em teste, nao em crise real.

Como a Duk estrutura estrategias de DR para empresas brasileiras

A Duk Informatica & Cloud atua ha mais de 18 anos desenhando e operando estrategias de continuidade de negocios para mais de 550 empresas brasileiras, com certificacao Microsoft Gold Partner e SLA medio de resposta de 3,7 minutos em incidentes criticos. Nossa metodologia de DR comeca sempre pelo BIA — entender o negocio antes de propor tecnologia — e evolui para uma arquitetura customizada que combina backup local, replicacao para nosso data center proprio em Alphaville e copias imutaveis em nuvem Azure.

Diferente de fornecedores que vendem apenas licencas e deixam o cliente sozinho com a implementacao, a Duk opera o ambiente de DR end-to-end: monitoramento 24/7, testes trimestrais com relatorio formal de conformidade de RTO/RPO, runbooks documentados e atualizados, e equipe de plantao treinada para executar failover em situacao real. Para setores regulados (saude, financeiro, juridico), fornecemos tambem documentacao compativel com LGPD, BACEN 4.893 e ISO 27001 necessaria em auditorias.

Se sua empresa ainda nao tem RTO e RPO formalmente definidos, ou se tem mas nunca testou, o risco e proporcional ao tamanho do negocio — e cresce todo dia. Ransomware, falhas fisicas e erros humanos nao avisam. Vamos conversar sobre como dimensionar sua estrategia de disaster recovery sob medida para a realidade do seu setor, sua operacao e seu orcamento.

Fale agora com um especialista da Duk: https://wa.me/5511957024493