Uma falha de infraestrutura não começa quando o servidor deixa de responder. Começa quando a empresa percebe que não sabe quanto tempo pode estar parada nem quantos dados pode perder. É nesse ponto que saber como calcular RTO e RPO deixa de ser uma questão técnica isolada e passa a ser uma decisão de continuidade de negócio, com impacto em faturação, serviço ao cliente, conformidade e reputação.

Na prática, muitas organizações definem estes indicadores por hábito: “recuperamos até ao dia seguinte” ou “temos backups diários”. São respostas insuficientes. Um backup diário pode significar perder quase 24 horas de transações. E recuperar um sistema no dia seguinte pode ser aceitável para numa plataforma interna, mas inaceitável para ERP, vendas, logística ou produção.

Como responsável pela operação de IT há mais de três décadas, vejo o mesmo erro repetido: comprar tecnologia antes de quantificar o impacto da indisponibilidade. Arquitetos antes de vendedores significa começar pelos serviços críticos, pelas dependências e pelos objetivos de recuperação. Só depois se escolhe a arquitetura.

O que significam RTO e RPO

RTO, ou Recovery Time Objective, é o tempo máximo aceitável para recuperar um serviço após uma interrupção. Mede o período entre a falha e o regresso do serviço a uma condição operacional definida. Se o RTO do ERP for quatro horas, a empresa deve conseguir recuperar a aplicação, os dados, os acessos e as integrações necessárias dentro desse prazo.

RPO, ou Recovery Point Objective, define a quantidade máxima aceitável de dados que pode ser perdida. É medido em tempo. Um RPO de uma hora significa que, no pior cenário, a recuperação pode repor dados com até uma hora de atraso face ao momento da falha.

Os dois conceitos estão ligados, mas não são a mesma coisa. É possível recuperar rapidamente uma máquina virtual com dados desatualizados. Também é possível recuperar dados quase sem perda, mas demorar muitas horas a colocar a aplicação novamente em serviço. Continuidade real exige controlar ambos.

Há ainda uma distinção que convém clarificar com a direção: RTO e RPO são objetivos de negócio, não promessas automáticas da ferramenta de backup. A tecnologia só cumpre estes objetivos quando a infraestrutura, os procedimentos, as pessoas e os testes foram desenhados para os suportar.

Como calcular RTO e RPO por serviço crítico

O cálculo deve ser feito por serviço de negócio, não por equipamento. Um servidor pode alojar vários componentes com níveis de criticidade diferentes. Por outro lado, uma aplicação crítica depende frequentemente de identidade, rede, DNS, bases de dados, armazenamento, licenças e ligações a terceiros. Recuperar apenas a máquina principal não equivale a recuperar o serviço.

Comece por identificar os processos que não podem parar ou que têm janelas de paragem muito reduzidas. Em muitas empresas portuguesas, isso inclui ERP, faturação, gestão de encomendas, email, acesso remoto, plataformas de produção, bases de dados de clientes e sistemas de segurança.

Para cada serviço, reúna os responsáveis de negócio e responda a questões concretas: quanto custa uma hora sem este serviço? Que operações ficam bloqueadas? Há processos manuais alternativos? Existem obrigações legais, contratuais ou de segurança? A informação perdida pode ser reconstruída? Quanto tempo os clientes aceitam esperar?

A resposta não deve ser genérica. “É crítico” não é uma métrica operacional. Um diretor financeiro pode aceitar perder quatro horas de alterações num repositório documental, mas não 15 minutos de movimentos de faturação no fecho mensal. Um responsável de operações pode tolerar oito horas sem um portal interno, mas não 30 minutos sem o sistema que coordena entregas.

Calcular o RTO a partir do impacto da paragem

Para definir o RTO, estime o impacto acumulado da indisponibilidade ao longo do tempo. Não se limite à perda direta de receitas. Considere salários improdutivos, penalizações contratuais, atrasos na cadeia de fornecimento, equipas paradas, custo de recuperação manual, risco de incumprimento e dano comercial.

Depois, identifique o ponto em que o impacto deixa de ser aceitável. Esse é o limite para o RTO. Por exemplo, se uma aplicação de logística permite operar manualmente durante duas horas, mas ao fim de quatro horas começa a comprometer entregas e penalizações, um RTO de quatro horas é o máximo admissível. Definir oito horas porque é mais barato não reduz o risco, apenas formaliza uma exposição que a operação pode não suportar.

O RTO deve incluir todo o tempo necessário para detetar o incidente, tomar a decisão de recuperação, ativar o procedimento, restaurar ou fazer failover, validar dados, testar integrações e devolver o serviço aos utilizadores. É comum medir apenas o tempo de restauro técnico e esquecer a validação. Esse erro cria SLAs que falham no momento em que mais importam.

Calcular o RPO a partir da tolerância à perda de dados

Para calcular o RPO, analise a frequência e o valor das alterações. Pergunte: quantas transações, registos, desenhos, propostas ou movimentos podem desaparecer sem criar um problema operacional ou financeiro grave?

Se uma empresa emite centenas de faturas por hora, um RPO de 24 horas é impraticável, mesmo que exista backup diário. Se uma base de dados é atualizada de poucos em poucos dias e os dados podem ser reintroduzidos com controlo, um RPO de 12 ou 24 horas pode ser razoável.

A escolha tem consequências técnicas e financeiras. Um RPO menor exige cópias mais frequentes, replicação, snapshots consistentes com a aplicação ou mecanismos de journaling. Isto aumenta consumo de armazenamento, largura de banda, licenciamento e complexidade de operação. Não há um valor universalmente correto. Há um valor alinhado com o risco que a empresa decide aceitar.

Transformar objetivos numa arquitetura recuperável

Depois de definidos RTO e RPO, é necessário validar se a arquitetura os consegue cumprir. Um backup imutável é essencial para reduzir o risco de ransomware, mas não garante por si só uma recuperação em duas horas. Uma cópia na cloud melhora a resiliência geográfica, mas pode não cumprir um RTO reduzido se a largura de banda, a capacidade de computação ou a sequência de recuperação não estiverem preparadas.

Uma abordagem pragmática passa por classificar os serviços em níveis de recuperação. Os serviços de nível 1, como ERP, bases de dados centrais ou sistemas de produção, podem exigir replicação, recuperação orquestrada e infraestrutura alternativa pronta a receber cargas. Os de nível 2 podem funcionar com backups frequentes e restauro prioritário. Os de nível 3, menos críticos, podem ser recuperados em dias a partir de cópias de segurança convencionais.

Esta classificação evita dois extremos: investir como se todos os sistemas fossem críticos ou aceitar que sistemas essenciais tenham o mesmo tratamento que um servidor de ficheiros. A arquitetura deve também respeitar dependências. Um RTO de duas horas para uma aplicação não é credível se o Active Directory, a firewall, o acesso à Internet ou a base de dados associada tiverem RTOs de oito horas.

Em ambientes híbridos, a decisão entre recuperação local, cloud ou site alternativo depende do volume de dados, da latência, das integrações e do custo total de propriedade. Para algumas cargas, a cloud é a opção indicada. Para outras, manter capacidade local ou num datacenter alternativo dá mais previsibilidade. O desenho correto resulta do diagnóstico, não de uma preferência comercial.

O teste é onde o RTO deixa de ser teórico

Um plano de disaster recovery sem testes regulares é uma intenção, não uma capacidade operacional. O teste confirma tempos reais, revela dependências esquecidas e mostra se as equipas sabem quem decide, quem executa e quem comunica.

Recomendo testar cenários distintos: eliminação acidental de dados, falha de armazenamento, indisponibilidade do site principal, comprometimento por ransomware e falha de um fornecedor crítico. Cada cenário pode expor limitações diferentes. Um restauro de ficheiros não valida a recuperação coordenada de uma aplicação empresarial completa.

Em cada teste, registe o tempo de deteção, o momento de decisão, o início da recuperação, a disponibilidade técnica e a validação pelo dono do processo. Compare o resultado com o RTO contratado ou definido internamente. Se o objetivo for quatro horas e o teste demorar seis, o valor correto não é “quatro horas em teoria”. É seis horas, até que a arquitetura ou o procedimento seja corrigido.

A ITPOINT trabalha este tema como um ciclo contínuo: diagnóstico dos serviços e riscos, arquitetura alinhada com RTO/RPO, implementação controlada e operação com monitorização, suporte e testes. Não vendemos tecnologia. Operamos infraestrutura com responsabilidades claras, porque o momento de recuperar não é a altura para descobrir lacunas entre fornecedores.

O passo útil agora é simples: escolha os cinco serviços sem os quais a empresa não consegue operar e peça aos respetivos responsáveis que indiquem quanto tempo podem parar e que dados podem perder. Essas respostas podem não ser confortáveis, mas são a base de uma recuperação que funciona quando a operação está realmente sob pressão.