Como este tema funciona na sua empresa
Não há SLA definido para recuperação. Desafio: quando sistema cai, não há priorização de quem recupera primeiro. Abordagem: conversa com proprietário de cada sistema — "quanto tempo consegue ficar fora? Quanto de dado pode perder?" Resultado: 2-3 categorias (crítico, importante, backup). Documentar em planilha simples.
Alguns sistemas têm RTO/RPO informais. Desafio: inconsistência — cada time define diferente. Abordagem: processo formal de levantamento com proprietários, validado por comitê de TI. Documentar em repositório centralizado. Review anual ou quando negócio muda. Integração com SLA de suporte.
RTO/RPO definidos por aplicação crítica, integrados com continuidade de negócio. Desafio: balancear SLA com custo de infraestrutura. Abordagem: business continuity plan (BCP) formal com exercício anual. RTO/RPO validados por DR (disaster recovery) test. Integração com programa de segurança.
RTO (Recovery Time Objective) é tempo máximo aceitável para restaurar sistema/dados após falha, sem impacto crítico no negócio. RPO (Recovery Point Objective) é tempo máximo aceitável de perda de dados (quanto você está disposto a voltar no tempo). Juntos, RTO/RPO definem estratégia de backup, replicação e disaster recovery[1].
Entender RTO: tempo de parada aceitável
RTO é negócio, não técnico. Pergunta: "se sistema cai agora, qual é impacto à operação?" Exemplos: 1h: vendas online fora do ar = perdendo R$ 1000/min = R$ 60k/h = RTO muito curto. 4h: sistema interno de relatório fora = inconveniente mas operação continua = RTO aceitável. 24h: base de dados histórica down = ninguém nota = RTO longo.
Matriz de impacto: quanto tempo o negócio aguenta sem sistema? RTO é esse tempo.
Conversa informal com proprietário de sistema: "e se (sistema) cai? Quantas horas de trabalho perdemos?" RTO = resposta em horas. Resultado: "vendas = 2h, financeiro = 4h, backup = 24h".
Workshop com proprietários. Calcular impacto: pessoas afetadas, receita por hora, custo operacional. RTO = função de impacto. Resultado: P1 = 1-2h, P2 = 4-6h, P3 = 24h. Documentar, comunicar.
Business continuity team quantifica impacto de cada aplicação. RTO por aplicação. Agregado: "90% de aplicações tem RTO <= 4h". Disaster recovery test anual valida se RTO real = RTO promessa.
Entender RPO: tolerância de perda de dados
RPO é quanto de trabalho você perde se precisa restaurar de backup. Exemplos: RPO = 1h: base de transações financeiras. Perder 1h = problema. RPO = 15min: sistema crítico de produção. Perder 15min = aceitável. RPO = 24h: arquivo de email antigo. Perder 24h = ninguém reclama.
Relação com frequência de backup: RPO de 1h requer backup a cada 1h (ou replicação contínua). RPO de 24h = backup diário é suficiente.
Fórmula: RPO = frequência de backup. Se backup é horário, RPO máximo é 1h (você perde até 1h de transações desde ultimo backup).
Proprietário de sistema: "se database corrompeu, posso perder quantos dados? Um dia inteiro? Uma hora?" RPO = resposta. Implementar backup com frequência >= RPO.
Workshop de RPO: discussão de impacto, custo vs. frequência. Sistema financeiro: RPO = 4h, requer backup 6x/dia. Sistema menos crítico: RPO = 24h, requer backup diário. Trade-off: RPO curto = custo de storage/banda maior.
RPO por aplicação definido. Aplicações críticas: RPO <= 1h, requer replicação contínua ou backup Q1h. Ferramentas de backup calculam RPO automaticamente baseado em frequência e janela de retenção.
Processo de levantamento de RTO/RPO
Passo 1: Mapear sistemas/dados. Lista todos. Proprietário de cada um. Passo 2: Calcular impacto. Para cada sistema: "se cai, qual impacto?" Em horas de parada, quantidade de usuários afetados, receita perdida. Passo 3: Definir RTO. RTO = tempo que impacto se torna intolerável. Exemplo: "vendas cai = impacto é imediato = RTO 2h. Relatório = impacto é atrasar decisão = RTO 8h". Passo 4: Definir RPO. RPO = quanto de dado recente é crítico? "Transação bancária = crítica = RPO 15 min. Email = menos crítico = RPO 1 dia".
Passo 5: Validar com técnico. Tech valida: "para atingir RTO 2h e RPO 15min, preciso replicação contínua + failover automático = caro". Negócio decide: aceita custo ou estende RTO?
Passo 6: Documentar e comunicar. Publicar RTO/RPO para todos. Comunicar ao time de backup/infra: "aqui estão os SLAs, configure backup conforme".
Validar RTO/RPO: disaster recovery test
Documentar RTO/RPO é uma coisa. Validar na prática é outra. DR test: simular falha, recuperar, medir tempo real de recuperação. Compare com RTO promissado. Se real > RTO: aumentar frequência de backup ou investir em HA (High Availability).
Frequência: crítico = semestral. Alto = anual. Outros = quando possível. Resultado: document proving RTO real <= RTO promessa.
Sinais de que sua empresa precisa definir RTO/RPO
Se você se reconhece em três ou mais cenários abaixo, defina RTO/RPO imediatamente.
- Quando sistema cai, não há priorização clara sobre o que recuperar primeiro
- Não há SLA documentado de tempo de recuperação para sistemas críticos
- Backup e disaster recovery não são planejados conforme criticidade
- Teste de recuperação revelou que tempo real > tempo prometido a cliente
- Não há alinhamento entre negócio e TI sobre tolerância de parada/perda de dados
- Regulação (BACEN, LGPD) exige RTO/RPO documentado mas empresa não tem
- Custo de backup é alto mas não há visibilidade se está otimizado conforme necessidade
Caminhos para definir RTO/RPO
Duas abordagens para estabelecer objetivos de recuperação baseados em risco de negócio.
Viável quando proprietários de sistema estão disponíveis e TI tem experiência.
- Perfil necessário: gestor de TI, proprietários de negócio (vendas, financeiro, etc)
- Tempo estimado: 1-2 meses (workshop + levantamento + validação técnica)
- Faz sentido quando: empresa pequena/média, estrutura simples
- Risco principal: subestimar criticidade, falta de validação em DR test
Recomendado para quantificação rigorosa e compliance.
- Tipo de fornecedor: Consultoria de Continuidade de Negócio, Especialista em BCP/DR
- Vantagem: expertise em cálculo de impacto, validação técnica, compliance regulatório
- Faz sentido quando: empresa é regulada, sistemas críticos, necessidade de DR test formal
- Resultado típico: RTO/RPO definido por aplicação em 4-6 semanas, plano de DR validado
Precisa definir RTO/RPO para sua empresa?
Se recuperação de dados não tem SLA claro, o oHub conecta você gratuitamente a especialistas em continuidade de negócio e disaster recovery. Em menos de 3 minutos, descreva seu cenário e receba propostas personalizadas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
RTO e RPO são a mesma coisa?
Não. RTO (Recovery Time Objective) = tempo máximo de parada aceitável. RPO (Recovery Point Objective) = tempo máximo de perda de dados aceitável. Exemplo: RTO=4h e RPO=1h significa: recuperação em até 4 horas, perdendo no máximo 1 hora de dados.
Como calculo RTO se não sei o impacto?
Pergunta a proprietário: "se (sistema) cai, qual é impacto? Pessoas paradas? Receita perdida?" Quantifique: 10 pessoas paradas = pode esperar poucas horas; 1000 pessoas paradas = RTO muito curto. RTO é função de impacto observável.
RPO curto (15 min) é sempre melhor?
Não, é mais caro. RPO curto requer backup frequente (ou replicação contínua), o que aumenta custo de storage e banda. RPO deve ser compatível com importância de dados. Sistema crítico = RPO curto (justificável). Email histórico = RPO longo (não justifica custo).
Como validar que RTO está sendo cumprido?
Disaster recovery test: simular falha, recuperar, medir tempo real. Compare com RTO. Se real > RTO: aumentar investimento em HA/backup, ou renegociar RTO. Test regular (anual mínimo) comprova que RTO é viável.
RTO/RPO é obrigatório?
Não por lei, mas é requisito de compliance: ISO 27001 exige continuidade de negócio; BACEN exige para bancos; LGPD exige backup de dados pessoais. Se regulado: RTO/RPO é essencial para auditoria.
Preciso de RTO/RPO para todos os sistemas?
Não. Priorizar: sistemas críticos primeiro (vendas, financeiro, clientes). Depois, importantes (operação). Depois, secundários (email, documentos). Muito sistema = priorize top 20% que representam 80% do risco.