Disaster recovery: o que é, RTO, RPO e como montar o plano

Um servidor que para no meio de uma operação de fechamento contábil. Um ataque de ransomware que cifra o storage primário às três da manhã. Uma região de cloud que sai do ar por falha de energia regional. Cada um desses cenários custa horas, dinheiro e reputação — e cada um deveria estar previsto em um plano de disaster recovery.

Disaster recovery é a disciplina que organiza a TI para sobreviver a esses momentos. Não se trata apenas de ter backup, embora o backup seja parte. Trata-se de definir, com antecedência, quanto tempo a operação aguenta ficar parada, quanto dado pode ser perdido, e quais procedimentos a equipe vai executar quando o pior acontecer.

Neste guia, vamos cobrir o que é disaster recovery, como ele se relaciona com backup, continuidade de negócios e alta disponibilidade, o que são RTO e RPO, quais estratégias técnicas existem hoje, e o passo a passo para construir e testar um plano que funcione na prática.

O que é disaster recovery (DR)?

Disaster recovery é o conjunto de políticas, ferramentas e procedimentos que garantem a recuperação da infraestrutura de TI e dos dados críticos após um evento disruptivo. Em outras palavras, é o que mantém o negócio funcionando depois de uma falha grave de hardware, um ataque cibernético, um erro humano sério ou um desastre natural.

O artefato central da disciplina é o disaster recovery plan (DRP). Trata-se de um documento operacional que descreve, em detalhe, as ações para retomar serviços críticos: quem aciona o quê, em qual ordem, com quais ferramentas, e dentro de quais janelas de tempo aceitáveis.

Um bom DRP combina três camadas. Antes de tudo, prevenção — reduzir a probabilidade do evento. Em seguida, antecipação — preparar recursos espelhados e procedimentos. Por fim, mitigação — agir rápido quando o evento ocorre, restabelecendo serviços com perda mínima.

Disaster recovery vs. backup, continuidade de negócios e alta disponibilidade

Quatro conceitos costumam ser confundidos no dia a dia da TI. Cada um resolve um problema diferente, e o plano completo de resiliência precisa de todos. A tabela abaixo separa o foco principal de cada um.

Em resumo, backup é uma cópia recuperável de dados e funciona como insumo do plano. O disaster recovery é o procedimento que usa esses backups (e outros recursos) para restabelecer sistemas. O business continuity plan (BCP) é mais amplo: cobre processos, comunicação, pessoas e fornecedores, com a TI como uma de suas peças. Já a alta disponibilidade busca evitar que a parada aconteça, com redundância arquitetural e failover automático.

Tipos de desastre que justificam um plano de disaster recovery

Nem todo incidente é um desastre, mas certos eventos disparam o DRP. Mapear esses cenários antecipa decisões e reduz o tempo de reação no momento da crise.

Os principais grupos de gatilhos incluem desastres naturais (enchentes, incêndios, terremotos), falhas de infraestrutura (perda de energia regional, queda de provedor cloud, falha de hardware crítico), ataques cibernéticos como ransomware, sequestro de credenciais e DDoS, erros humanos com impacto sistêmico (drop em produção, deploy quebrado em larga escala, exclusão acidental de bucket) e falhas de fornecedores estratégicos.

Cada tipo de evento exige uma combinação diferente de recursos. Um ataque de ransomware demanda restauração a partir de backups imutáveis. Já uma queda de região cloud exige replicação multi-região. Por isso, o plano deve mapear os cenários antes de definir as estratégias.

RTO e RPO: as duas métricas que definem o plano

Toda decisão técnica de disaster recovery passa por duas métricas. RTO e RPO traduzem expectativa de negócio em parâmetros de engenharia mensuráveis.

O que é RTO (Recovery Time Objective)

RTO é o tempo máximo que um sistema pode ficar indisponível antes de causar impacto inaceitável ao negócio. Mede para a frente, a partir do momento do desastre. Um e-commerce de varejo costuma trabalhar com RTO < 1 hora em horário de pico. Já um sistema interno de RH pode aceitar RTO de 24 horas.

O que é RPO (Recovery Point Objective)

RPO é a quantidade máxima de dados que o negócio aceita perder, medida em tempo. Olha para trás: do momento do desastre até o último ponto de recuperação válido. Um banco com transações financeiras opera com RPO próximo de zero, exigindo replicação síncrona. Sistemas de relatórios analíticos toleram RPO de horas com snapshots periódicos.

Como definir os valores na prática

A definição parte de uma análise de impacto no negócio (BIA). Para cada sistema, levante o custo financeiro por hora parado, o impacto regulatório de perda de dados, a dependência de outras áreas e o impacto reputacional. Em seguida, traduza esses números em RTO e RPO específicos por aplicação. Quanto mais crítica, menores os valores — e mais cara a estratégia.

Estratégias de disaster recovery, do backup-and-restore ao multi-site active/active

Existem quatro grandes estratégias para implementar disaster recovery em infraestrutura moderna. Elas formam uma escala progressiva: quanto menor o RTO/RPO, maior o custo de manter recursos espelhados. Por isso, a escolha sempre balanceia criticidade vs. orçamento.

A estratégia mais simples mantém apenas backups em segundo site (cloud ou on-premises) e exige reconstrução completa do ambiente em caso de desastre. Já a estratégia pilot light mantém o núcleo da aplicação rodando minimamente no site secundário; em caso de evento, a infra escala para suportar produção. O warm standby vai além e mantém uma réplica dimensionada (ainda que reduzida) que pode ser promovida rapidamente, enquanto o multi-site active/active distribui carga real entre dois ou mais sites simultaneamente, com failover automático orquestrado em caso de queda. Para uma referência detalhada sobre essas categorias, consulte o framework de confiabilidade publicado pela AWS.

DRaaS, quando faz sentido contratar disaster recovery as a service

Disaster recovery as a service é o modelo no qual um provedor especializado opera a infraestrutura de recuperação como serviço gerenciado. O cliente assina o serviço e o provedor mantém os ambientes secundários, executa a replicação e orquestra o failover quando acionado.

DRaaS faz sentido em três cenários típicos. Primeiro, quando a empresa não tem expertise interna para projetar e operar arquiteturas de DR avançadas. Segundo, quando o custo de manter um segundo data center não se justifica frente ao volume de cargas críticas. Terceiro, quando a equipe precisa de previsibilidade de gasto, trocando capex por opex mensal contratado.

A trade-off envolve dependência do provedor, complexidade contratual sobre RTO/RPO comprometidos e necessidade de testes regulares para validar que o serviço entrega o prometido. Vale destacar que muitos modelos de DRaaS hoje rodam sobre infraestrutura de cloud computing, com replicação cross-region e orquestração via API.

Como montar um plano de disaster recovery (passo a passo)

Um DRP útil é executável sob estresse. Para chegar nesse nível, ele precisa ser construído com método. As sete etapas a seguir cobrem o ciclo do início ao fim.

1. Inventário e mapeamento de dependências

Liste todos os sistemas, aplicações, serviços externos, bancos de dados, storages e equipamentos de rede. Em seguida, mapeie as dependências entre eles. Um sistema de pedidos depende do banco e do payment gateway; sem entender a topologia, o plano falha quando um ativo crítico não considerado fica offline.

2. Análise de impacto no negócio (BIA)

Para cada sistema, calcule custo de parada por hora, requisitos regulatórios, impacto operacional e impacto reputacional. A BIA é o que justifica gastar mais em DR para um sistema A do que para um sistema B. Sem ela, decisões de orçamento ficam reféns de opinião.

3. Definição de RTO e RPO por sistema

A partir da BIA, atribua RTO e RPO a cada aplicação. Documente os valores como contratos internos: o time de TI compromete-se a recuperar sistema X em até Y minutos com até Z minutos de perda de dados. Isso elimina ambiguidade no momento da crise.

4. Escolha das estratégias técnicas

Para cada combinação de RTO/RPO, selecione a estratégia da seção anterior. Sistemas críticos pedem warm standby ou multi-site, enquanto sistemas tolerantes podem operar com backup-and-restore. Documente as justificativas — auditoria e renovação de contrato vão pedir.

5. Procedimentos operacionais (runbooks)

Cada cenário de desastre precisa de runbook próprio: pré-requisitos, comandos exatos, ordem de execução, pontos de verificação e critério de “recuperado”. Evite runbooks genéricos demais — em produção sob pressão, ambiguidade vira erro humano.

6. Comunicação e governança

Defina o time de resposta, canais de comunicação interna e externa, gatilhos formais de declaração de desastre e quem assina cada decisão. Inclua comunicação com clientes, reguladores e imprensa quando aplicável. Como resultado, a equipe entra em modo “executar” em vez de “decidir” durante a crise.

7. Testes regulares e revisão

Plano não testado é plano que não existe. Defina calendário formal de testes, registre desvios, atualize o documento e re-treine a equipe a cada mudança relevante de arquitetura. A próxima seção entra no detalhe de tipos de teste.

Como testar o plano de disaster recovery

Existem quatro tipos principais de teste de DRP, com profundidade e frequência distintas. Combiná-los ao longo do ano dá maior cobertura sem comprometer a operação.

Cada teste deve produzir um relatório com tempo medido (vs. RTO/RPO comprometido), desvios encontrados e ações corretivas. Ainda assim, é nos testes mais profundos que aparecem os problemas reais — chave de SSH expirada, DNS apontando para o site primário, certificado vencido no balancer secundário. Por isso, encarar o teste como aprendizado vale mais do que tratar como auditoria.

O papel do monitoramento e da observabilidade no disaster recovery

Um DRP só funciona se a equipe souber, em tempo real, que precisa acioná-lo. É aí que entra o monitoramento contínuo. Sem ele, o tempo de detecção do desastre se soma ao RTO e estoura o compromisso.

A camada de observabilidade contribui em três frentes. Primeiro, alertas que disparam em sinais precoces (uso anômalo de CPU, latência fora do baseline, queda de health checks regionais) reduzem o tempo entre o evento e o acionamento do DRP. Em seguida, dashboards de runbook permitem que a equipe acompanhe a execução do plano e detecte desvios cedo. Por fim, métricas pós-failover validam que o ambiente secundário está saudável antes da equipe declarar o ambiente recuperado.

Plataformas de monitoramento real-time integrado à operação 24×7 conseguem, inclusive, rodar verificações sintéticas no site secundário continuamente. Isso garante que, no dia do desastre, o ambiente de DR não esteja silenciosamente quebrado há semanas. Para um aprofundamento conceitual, vale consultar o guia oficial do NIST sobre planejamento de contingência.

Disaster recovery e LGPD

A Lei Geral de Proteção de Dados muda o peso jurídico do disaster recovery. Dados pessoais armazenados em backups, replicados em sites secundários ou processados em ambientes de DRaaS continuam sob a responsabilidade do controlador de dados, mesmo durante a recuperação.

Três pontos exigem atenção. Primeiro, retenção: backups com dados pessoais devem respeitar o ciclo de vida definido pelo controlador, mesmo no site secundário. Segundo, sub-operadores: provedores de DRaaS são operadores e precisam constar na cadeia formal de tratamento. Terceiro, incidentes: um ataque que dispara o DRP costuma também acionar a obrigação de notificar a ANPD em até dois dias úteis. Por isso, o plano de comunicação do DRP deve estar alinhado com o plano de resposta a incidentes do DPO.

Adicionalmente, a norma internacional ISO 22301 orienta como integrar continuidade, segurança e proteção de dados em um framework auditável.

Conclusão

Disaster recovery deixou de ser apólice de seguro guardada na gaveta. Hoje, com cloud, ransomware e exigências regulatórias somando pressão, o plano precisa ser vivo, testado e integrado à operação diária de TI. RTO e RPO traduzem expectativa de negócio em parâmetros de engenharia, as estratégias técnicas (do backup-and-restore ao multi-site active/active) materializam essas metas, e o monitoramento contínuo garante que a equipe saiba quando agir.

A lição prática é simples: um DRP só vale o quanto foi testado pela última vez. Inventário atualizado, BIA refeita anualmente, runbooks específicos por cenário, calendário formal de testes e pós-mortem de cada exercício são o que separa um documento decorativo de um plano operacional.

Se sua operação ainda depende de backup como única linha de defesa, ou se o último teste de failover foi há mais de doze meses, é hora de revisar. Fale com um especialista da OpServices e estruture uma camada de monitoramento e disponibilidade alinhada ao tamanho do seu risco.