RTO e RPO: entenda esses indicadores antes de contratar um backup
RTO e RPO: entenda esses indicadores antes de contratar um backup
RTO e RPO são as duas métricas mais importantes — e mais frequentemente confundidas — quando o assunto é backup e continuidade de negócios. Elas definem, respectivamente, quanto tempo sua empresa pode ficar sem o sistema e quantos dados ela pode perder em um incidente.
Definir esses números antes de contratar uma solução de backup é o que separa um SLA realista de uma promessa vazia. Neste artigo, você vai entender o que cada indicador significa, como calcular os limites aceitáveis para seu negócio e como o DBGuard ajuda a medir e comprovar ambos.
Leia também: Teste de restauração automatizado no DBGuard — veja como a medição de RTO real é automatizada.
O que é RTO (Recovery Time Objective)
RTO é o tempo máximo aceitável que um sistema pode ficar indisponível após um incidente. É o relógio que começa a contar no momento da falha e para quando o sistema está novamente operacional para os usuários.
| Perfil de negócio | RTO típico | Impacto de cada hora parada |
|---|---|---|
| E-commerce | 15 a 30 minutos | Perda de receita direta + abandono de carrinho |
| ERP industrial | 1 a 4 horas | Linha de produção parada, faturamento atrasado |
| Escritório de contabilidade | 4 a 8 horas | Entrega de obrigações em risco, multas contratuais |
| Clínica / laboratório | 15 a 60 minutos | Pacientes sem atendimento, exames perdidos |
| Cartório | 30 a 60 minutos | Atos não registrados, prazo legal vencido |
O que é RPO (Recovery Point Objective)
RPO é a quantidade máxima de dados que pode ser perdida em um incidente, medida em tempo. Se o RPO é de 15 minutos, significa que o backup pode ter no máximo 15 minutos de defasagem — ou seja, dados gerados nos últimos 15 minutos podem ser perdidos.
| RPO | Estratégia de backup | Volume de perda aceitável |
|---|---|---|
| 5 minutos | Log shipping a cada 5 min | Mínimo — transações recentes perdidas |
| 15 minutos | Log shipping a cada 15 min | Baixo |
| 1 hora | Diff a cada hora | Moderado — até 1h de trabalho |
| 24 horas | Full diário | Alto — até um dia de dados perdidos |
RTO vs RPO: por que os dois precisam ser definidos juntos
RTO e RPO são independentes, mas complementares. É possível ter:
- RTO agressivo e RPO relaxado: sistema volta rápido, mas perde até 24h de dados
- RTO relaxado e RPO agressivo: dados preservados com perda mínima, mas restore demora
- Ambos agressivos: restore rápido com perda mínima — a combinação ideal (e mais cara)
O DBGuard permite configurar RTO e RPO de forma independente por política de backup, ajustando frequência, tipo de backup e prioridade de restore para cada banco.
Como o DBGuard mede RTO e RPO na prática
O painel do DBGuard monitora continuamente a defasagem entre o estado atual do banco e o último backup disponível:
Medição de RPO
Painel DBGuard — RPO Monitor
Banco: ERP_Producao
├── Último backup: 06:15 UTC (diff)
├── Último log ship: 06:14:37 UTC (há 23 segundos)
├── RPO configurado: 15 minutos
✅ RPO CONFORME (defasagem atual: 23 segundos)Medição de RTO
Cada restore executado pelo DBGuard é cronometrado automaticamente:
Relatório de RTO — ID: rst-20260701-020000
├── Banco: ERP_Producao (47,3 GB)
├── Origem: Restore Validator (sandbox)
├── Início: 02:15:00 UTC
├── Término: 02:38:14 UTC
├── RTO real: 23 minutos e 14 segundos
├── RTO SLA: 60 minutos
✅ CONFORME (47% do SLA)Série histórica e tendências
O DBGuard consolida os dados de RTO e RPO ao longo do tempo, permitindo identificar tendências de degradação antes que virem problema:
| Mês | RTO médio (ERP) | RTO médio (Contábil) | RPO atendido |
|---|---|---|---|
| Abril/2026 | 31 min | 18 min | 100% |
| Maio/2026 | 33 min | 19 min | 100% |
| Junho/2026 | 38 min | 21 min | 99,8% |
| Julho/2026 | 42 min (alerta) | 23 min | 99,5% |
O aumento gradual no RTO (de 31 para 42 min) disparou um alerta no painel do DBGuard, indicando que o banco cresceu sem adequação da infraestrutura de restore — um problema que, se não tratado, levaria à violação do SLA em 2 a 3 meses.
Como definir RTO e RPO ideais para seu negócio
O DBGuard auxilia na definição dos limites com uma calculadora integrada que considera:
- Custo de cada hora de indisponibilidade (receita, produtividade, multas)
- Volume de dados e janela de backup disponível
- Orçamento para infraestrutura local e em nuvem
- Exigências regulatórias (LGPD, Provimento 213, ISO 27001)
A calculadora gera uma recomendação com três cenários: mínimo, recomendado e avançado.
Conclusão
RTO e RPO não são números técnicos abstratos — são definições de negócio que impactam diretamente a continuidade operacional. Quanto mais crítico o sistema, mais agressivos os limites precisam ser.
O DBGuard não apenas armazena backups: ele mede, registra e alerta sobre RTO e RPO em tempo real, transformando promessas de SLA em dados mensuráveis e auditáveis. Cada restore é cronometrado, cada defasagem é monitorada, cada violação é notificada.
Se você ainda não definiu RTO e RPO para seus bancos SQL Server, o DBGuard pode ajudar a estabelecer esses limites e começar a medi-los em até 24 horas.
Links internos relacionados:
- Backup Imutável no DBGuard: proteção contra ransomware
- Teste de restauração automatizado no DBGuard
- DBGuard — Backup de bancos SQL Server com continuidade de verdade
Redação Dado Seguro — Iago Vetor Cloud