Disaster Recovery na prática: RTO, RPO e continuidade do negócio

Disaster Recovery (DR), ou recuperação de desastres, é a capacidade de retomar a operação rapidamente após um incidente grave — uma falha de hardware catastrófica, um ataque, um desastre físico que derruba o site principal. Diferente do backup, que protege os dados, o DR protege a continuidade do negócio: mantém um ambiente réplica pronto para assumir, em minutos, no lugar do ambiente que caiu.

A diferença entre uma empresa que volta ao ar em minutos e outra que fica dias paralisada quase sempre está em dois números: RTO e RPO. Neste artigo, explicamos esses conceitos e como montar um plano de DR que funciona quando você mais precisa.

RTO e RPO: os dois números que importam

Todo plano de DR se organiza em torno de duas métricas:

RTO (Recovery Time Objective) — o tempo máximo aceitável para a operação voltar a funcionar após o incidente. “Quanto tempo posso ficar parado?”
RPO (Recovery Point Objective) — a perda máxima de dados aceitável, medida em tempo. “Quanto de dado recente posso perder?”

Um exemplo torna claro: se o seu RPO é de 1 hora, você aceita perder, no máximo, a última hora de transações. Se o RTO é de 30 minutos, o ambiente precisa estar de volta em meia hora. Quanto menores esses números, mais robusta — e mais custosa — precisa ser a arquitetura.

RTO e RPO não são detalhes técnicos: são decisões de negócio. Eles traduzem, em minutos, quanto a sua empresa perde a cada hora parada e a cada transação perdida.

Backup não é Disaster Recovery

Um erro comum é achar que “ter backup” é o mesmo que ter DR. Não é:

Backup garante que os dados existem em outro lugar. Mas restaurar um backup, reinstalar sistemas e reconfigurar tudo pode levar horas ou dias.
Disaster Recovery mantém um ambiente réplica já provisionado, pronto para assumir — reduzindo o RTO de dias para minutos.

Backup é necessário, mas insuficiente quando a operação não pode esperar uma restauração completa. Por isso os dois serviços se complementam: aprofundamos o lado da proteção de dados no artigo sobre backup como serviço.

Como o DR funciona na prática

O serviço de recuperação de desastres da Saiph TI mantém uma réplica viva do seu ambiente, pronta para assumir:

Replicação contínua — os dados são copiados em tempo real ou near-real para o site secundário, mantendo o RPO baixo.
Failover automático — ativação do ambiente réplica em minutos diante de uma falha.
RTO e RPO garantidos em contrato — definidos conforme a criticidade do seu negócio.
Testes periódicos documentados — simulações de recuperação que comprovam que o plano funciona.
Redundância geográfica — sites independentes em Belo Horizonte e Recife.

Essa separação entre os dois datacenters é fundamental: o ambiente réplica precisa estar em um site que não cairá pelo mesmo motivo que o principal — o conceito de redundância geográfica.

O teste é o que separa plano de promessa

Um plano de DR que nunca foi testado é apenas uma suposição. A maioria das falhas de recuperação aparece justamente nos detalhes que só um teste revela: uma dependência esquecida, uma configuração de rede divergente, um procedimento que ninguém documentou.

Por isso, o DR sério inclui testes de restauração periódicos e documentados. Eles validam o RTO e o RPO na prática e, em setores regulados, servem como evidência de conformidade — caso, por exemplo, dos cartórios sob o Provimento 213, que exige comprovação de testes.

Dimensionando o seu DR

Nem todo sistema precisa do mesmo nível de DR. Um bom plano classifica os sistemas por criticidade:

Crítico — não pode parar (faturamento, atendimento, sistemas de produção). RTO e RPO baixíssimos, com failover automático.
Importante — tolera algumas horas de indisponibilidade. RTO moderado.
Secundário — pode esperar uma restauração de backup comum.

Essa priorização concentra o investimento onde ele realmente importa, evitando pagar por failover instantâneo em sistemas que toleram esperar.

Quanto a sua empresa perde por hora de parada

Definir o investimento certo em DR começa por uma conta que poucas empresas fazem: quanto custa cada hora de indisponibilidade?. Esse número — o custo do downtime — é o que justifica (ou não) um RTO agressivo.

Para estimá-lo, some os componentes:

Receita direta perdida — vendas, transações ou serviços que não acontecem enquanto o sistema está fora.
Custo de mão de obra ociosa — equipes paradas, multiplicadas pelo custo/hora.
Penalidades contratuais ou regulatórias — SLAs com clientes e exigências do setor.
Recuperação e horas extras — o esforço para voltar ao normal.
Impacto de reputação — mais difícil de medir, mas real, especialmente em quedas longas e públicas.

Quando você coloca esse valor por hora ao lado do custo do DR, a decisão fica clara: se cada hora parada custa muito mais do que a mensalidade do failover, o DR se paga no primeiro incidente. Esse cálculo também ajuda a priorizar — concentrando o investimento nos sistemas cujo downtime é mais caro.

Os componentes de um plano de DR completo

Disaster Recovery não é só tecnologia; é um plano. Um plano de DR maduro inclui:

Inventário e priorização — quais sistemas são críticos, importantes ou secundários, com RTO e RPO para cada um.
Arquitetura de replicação — como e com que frequência os dados vão para o site secundário.
Procedimento de failover — passos claros e documentados para ativar o ambiente réplica, e quem é responsável por cada etapa.
Procedimento de failback — como voltar à operação normal depois que o site principal é restabelecido.
Plano de comunicação — quem avisa clientes, equipe e fornecedores durante o incidente.
Cronograma de testes — simulações periódicas e documentadas que validam o plano.

A parte técnica — replicação e failover — é necessária, mas o que separa um plano que funciona de um que falha são a documentação e os testes. É por isso que, em setores regulados, a evidência de testes virou exigência: ela prova que o plano sai do papel.

Perguntas frequentes

Qual a diferença entre RTO e RPO?

RTO é o tempo máximo para voltar a operar; RPO é a perda máxima de dados aceitável, medida em tempo. RTO responde “quanto tempo parado?” e RPO responde “quanto de dado posso perder?”.

Preciso de DR se já tenho backup?

Depende da sua tolerância a parada. Se a operação não pode esperar horas por uma restauração completa, sim — o DR reduz o tempo de retomada de dias para minutos. Backup e DR são camadas complementares.

Como sei se o meu plano de DR funciona?

Testando. Um plano de DR confiável inclui testes de restauração periódicos e documentados, que validam RTO e RPO na prática — em vez de descobrir falhas só no dia do incidente real.

Quer definir RTO e RPO adequados e montar um plano de DR que sobreviva ao teste real? Fale com a nossa equipe pelo formulário de contato e estruturamos a sua continuidade entre os datacenters de BH e Recife.