Plano de recuperação de desastres (DRP): guia prático

O que é um DRP e o que ele precisa ter

Um DRP é o plano que responde a uma pergunta concreta: se um sistema crítico cair agora, como, em quanto tempo e com qual perda de dados ele volta. Não é um documento de prateleira; é um conjunto de decisões já tomadas e testadas, para que ninguém precise improvisar no meio da crise.

Os quatro componentes mínimos de um DRP

Todo DRP que funciona se sustenta em quatro blocos, nesta ordem:

1. Análise de impacto no negócio (BIA): identifica os sistemas críticos, o impacto de cada um ficar indisponível e a ordem de recuperação.
2. Objetivos de recuperação (RTO e RPO): para cada sistema, quanto tempo de indisponibilidade e quanta perda de dados são toleráveis.
3. Estratégia técnica: como cada RTO/RPO será atingido — backup, replicação, failover, site ou região de recuperação.
4. Runbook e comunicação: o passo a passo executável, a lista de contatos, a ordem de ativação e o plano de comunicação com stakeholders.

Falta qualquer um desses blocos e o plano falha onde mais dói. Sem BIA, recupera-se o sistema errado primeiro. Sem RTO/RPO, não há critério para investir. Sem runbook, o conhecimento mora na cabeça de uma pessoa que pode estar indisponível justamente no dia do desastre.

O que conta como desastre

Desastre é o evento incomum, grande e duradouro que a operação normal não consegue absorver. A Microsoft, na documentação de confiabilidade do Azure, agrupa os desastres em três famílias: desastres naturais (incêndio, alagamento, terremoto), erros humanos de grande impacto (exclusão acidental de dados de produção, firewall mal configurado) e incidentes graves de segurança (ransomware, negação de serviço que leva a perda ou corrupção de dados)^[4]. A distinção importa: uma falha pontual de um servidor é resolvida pela alta disponibilidade do dia a dia; o desastre é o que aciona o DRP.

DRP, plano de resposta a incidentes e plano de contingência

São documentos diferentes e complementares. O NIST SP 800-34 trata o DRP como um dos planos de contingência de TI, ao lado do plano de resposta a incidentes (foco em ataques e violações) e do plano de contingência do sistema de informação^[1]. Na prática para a maioria das empresas brasileiras, o DRP é o plano central de recuperação técnica — mas vale saber que ele não substitui o plano de resposta a incidentes de segurança.

DRP e Business Continuity Plan: qual é a diferença

O DRP é o componente técnico de TI; o Business Continuity Plan (BCP) é o plano geral da empresa para continuar operando durante e após uma interrupção. O DRP recupera servidores, dados e sistemas; o BCP cuida de pessoas, processos manuais, instalações e comunicação. Um é parte do outro.

Como os dois se encaixam na prática

Imagine uma indisponibilidade de seis horas no data center. O DRP entra em ação para ativar a redundância, recuperar os dados e trazer os sistemas de volta. O BCP, em paralelo, redireciona o atendimento ao cliente, aciona equipes alternativas e mantém a comunicação externa. Sem DRP, o BCP não tem infraestrutura para retomar. Sem BCP, a TI recupera as máquinas, mas a empresa não consegue operar com efetividade.

Continuidade, alta disponibilidade e recuperação

A documentação do Azure separa três conceitos que costumam ser confundidos: continuidade de negócios é o estado de seguir operando; alta disponibilidade trata dos riscos comuns e cotidianos (reboot, falha de hardware, picos de tráfego); e recuperação de desastres trata dos riscos raros e catastróficos^[4]. Investir em alta disponibilidade reduz a frequência com que o DRP precisa ser acionado, mas não elimina a necessidade do plano.

A norma que organiza tudo: ISO 22301

A ISO 22301:2019 é a norma internacional para sistemas de gestão de continuidade de negócios (BCMS) e serve de referência para estruturar o BCP que envolve o DRP. Publicada em sua segunda edição em 2019 e aplicável a organizações de qualquer porte, ela fornece o arcabouço para planejar, implementar, operar, revisar e melhorar continuamente a continuidade^[2]. Você não precisa certificar a empresa para se beneficiar: usar a norma como mapa de processos já estrutura a preparação.

RTO e RPO: os dois números que definem o plano

RTO e RPO são as duas métricas que traduzem "quão crítico é este sistema" em requisitos de engenharia. RTO (Recovery Time Objective) é o tempo máximo aceitável de indisponibilidade. RPO (Recovery Point Objective) é o volume máximo aceitável de perda de dados, medido em tempo. Tudo no DRP — estratégia, custo, arquitetura — decorre desses dois números.

A diferença entre RTO e RPO, com exemplo

RTO é sobre tempo de retorno; RPO é sobre perda de dados — e os dois são independentes. Segundo o NIST SP 800-34, o RTO é o tempo máximo que um recurso pode ficar indisponível antes que o impacto se torne inaceitável, e o RPO é o ponto no tempo, anterior à interrupção, até o qual os dados precisam ser recuperados^[1]. Exemplo concreto: um sistema de e-mail pode ter RTO de 4 horas (a empresa tolera 4 horas sem e-mail) mas RPO de 5 minutos (não pode perder mais que 5 minutos de mensagens — exige replicação quase em tempo real). Já um data warehouse pode ter RTO de 24 horas e RPO de 24 horas, porque é recarregado de fontes a cada dia.

MTD: o limite que o RTO não pode estourar

Além de RTO e RPO, o NIST define o MTD (Maximum Tolerable Downtime): o tempo total de interrupção que o dono do processo de negócio está disposto a aceitar, incluindo todos os impactos^[1]. O RTO precisa ser menor que o MTD, com folga, porque depois de recuperar o sistema ainda há tempo de validação e retomada da operação. Pensar no MTD evita o erro comum de fixar um RTO igual ao limite absoluto de tolerância, sem margem.

Quem define RTO e RPO

RTO e RPO são decisões do negócio, não da TI. O papel da TI é apresentar as opções, os custos e o que é tecnicamente viável; a definição do número aceitável é de quem é dono do processo. A documentação do Azure reforça esse ponto: mirar RTO e RPO iguais a zero é tentador, mas difícil e caro, e o número realista deve sair de uma conversa entre as partes técnica e de negócio^[4]. Em PMEs brasileiras, a maioria opera, por razões de custo, com RTO de horas e RPO de até um dia — e um alvo realista e testado vale mais que um plano ambicioso e intestável.

Análise de impacto (BIA): o que recuperar e em que ordem

A BIA (Business Impact Analysis) é a etapa que identifica os sistemas críticos, mede o impacto de cada interrupção ao longo do tempo e estabelece as prioridades de recuperação. É a partir dela que saem os valores de RTO, RPO e MTD que vão dirigir toda a estratégia^[1]. Sem BIA, o DRP recupera por intuição — e intuição erra a ordem.

As três perguntas da BIA por sistema

Para cada sistema relevante, a BIA responde a três perguntas objetivas:

1. Qual o impacto se este sistema ficar indisponível? Em receita perdida, clientes afetados, operação travada e risco regulatório.
2. Por quanto tempo a empresa sobrevive sem ele? Minutos, horas, dias — esse é o insumo do RTO e do MTD.
3. Quanta perda de dados é tolerável? As transações dos últimos minutos, da última hora, do último dia — esse é o insumo do RPO.

O NIST disponibiliza inclusive um template de BIA junto ao SP 800-34, útil como ponto de partida estruturado para empresas que estão começando^[1].

Classificar sistemas por criticidade (tiers)

Nem todo sistema merece o mesmo investimento de recuperação, e classificar por criticidade é o que evita gastar demais com o que é secundário e de menos com o que é vital. Sistemas críticos típicos: e-mail, ERP (vendas, estoque, financeiro), banco de dados de clientes e o site, quando a empresa vende online. Sistemas de criticidade menor: intranets, portais internos e ferramentas de colaboração com alternativas rápidas. A documentação do Azure organiza essa lógica em tiers de criticidade — missão crítica, crítico para o negócio e geral —, cada um com faixas próprias de RTO e RPO^[3].

Mapear dependências entre sistemas

Recuperar um sistema sem o que ele depende não adianta — e é aqui que muitas BIAs falham. O ERP pode depender do banco de dados, que depende da autenticação, que depende da rede; a ordem de recuperação tem de respeitar essa cadeia. Em ambientes maiores, vale uma matriz de dependências; em ambientes pequenos, basta listar, para cada sistema crítico, de quais outros ele precisa para subir.

RTO x RPO por criticidade: tabela e passo a passo de elaboração

A forma mais útil de transformar a BIA em plano é uma tabela que cruza criticidade do sistema com RTO, RPO e a estratégia técnica correspondente. Ela mostra, de relance, quanto cada nível de proteção custa em esforço e por que nem tudo deve mirar zero downtime. A tabela abaixo usa, como referência de mercado, as faixas de RTO/RPO por tier de criticidade descritas na documentação de confiabilidade do Azure^[3] e as estratégias de recuperação do whitepaper de DR da AWS^[5].

Tabela de referência: criticidade x RTO x RPO x estratégia

As faixas são referência de mercado, não regra fixa: o RTO e o RPO de cada sistema saem da BIA da sua empresa. A leitura central da tabela é que RTO/RPO menores exigem estratégias mais caras e complexas — tanto a AWS quanto o Azure descrevem essa relação direta entre objetivos de recuperação agressivos e custo^[5][3].

Passo a passo para elaborar o seu DRP

Com a tabela como bússola, a elaboração do plano segue uma sequência clara:

1. Inventarie os sistemas e os dados, incluindo SaaS e nuvem — não se recupera o que não se sabe que existe.
2. Rode a BIA: para cada sistema, defina impacto, MTD e a criticidade (tier).
3. Defina RTO e RPO por sistema, com o negócio decidindo e a TI informando viabilidade e custo.
4. Mapeie as dependências e estabeleça a ordem de recuperação respeitando a cadeia.
5. Escolha a estratégia de cada sistema na tabela, equilibrando RTO/RPO desejado com orçamento.
6. Escreva o runbook: passo a passo executável, contatos, plano de comunicação e ambiente de backup.
7. Teste a recuperação de verdade, em ambiente separado, e registre tempo real contra o alvo.
8. Revise e mantenha o plano a cada mudança relevante e em ciclo periódico.

Por que mirar zero em tudo é um erro

Buscar RTO e RPO próximos de zero em todos os sistemas estoura o orçamento sem ganho proporcional. O multi-site ativo/ativo da AWS, que aproxima o RTO de zero, é a abordagem mais complexa e cara entre as quatro estratégias^[5]; o Azure recomenda não superdimensionar a solução além do que os requisitos de negócio justificam^[4]. O dinheiro de DR deve concentrar-se nos sistemas de maior criticidade — é para isso que a tabela existe.

Estratégias de recuperação: do backup ao failover

As estratégias de recuperação formam um espectro de custo e velocidade: quanto menor o RTO/RPO, mais cara e complexa a abordagem. O whitepaper de DR da AWS organiza esse espectro em quatro níveis bem definidos, que servem de modelo mental mesmo para ambientes locais^[5].

Backup e restauração

É a estratégia mais simples e barata, e a mais comum em PMEs: cópia dos dados em local separado — disco, nuvem ou fita — restaurada quando necessário. A AWS a descreve como a abordagem de menor complexidade, ao custo de RTO e RPO mais altos, já que é preciso reprovisionar infraestrutura além de restaurar dados^[5]. A regra de ouro é testar a restauração: backup que nunca foi restaurado é uma suposição, não uma garantia.

Pilot light e warm standby

São os níveis intermediários, que reduzem o RTO ao manter parte do ambiente já pronta na localidade de recuperação. No pilot light, os elementos centrais (bancos de dados, replicação) ficam sempre ligados, enquanto os servidores de aplicação ficam provisionados mas "desligados", prontos para subir^[5]. No warm standby, há uma cópia reduzida porém totalmente funcional do ambiente sempre rodando, que só precisa escalar para assumir a carga^[5]. A diferença prática: o pilot light exige "ligar" e escalar antes de atender; o warm standby já atende, em capacidade reduzida, imediatamente.

Failover automático e multi-site

É o nível de RTO mais baixo e de custo mais alto. No multi-site ativo/ativo, a carga roda simultaneamente em mais de uma região, sem failover no sentido tradicional, aproximando o RTO de zero para a maioria dos desastres^[5]. É a opção de quem não pode parar — instituições financeiras, saúde, operações de receita contínua. Exige arquitetura redundante, monitoramento permanente e disciplina de testes.

Site de recuperação próprio ou em nuvem

O DR clássico usa um segundo data center em outra região geográfica; a nuvem oferece o equivalente sob demanda. Serviços como o Azure Site Recovery replicam máquinas físicas e virtuais de um site primário para uma localidade secundária e orquestram o failover e o posterior failback^[4]. A nuvem mudou a economia do DR: em vez de manter um site parado esperando o desastre, paga-se pela capacidade plena apenas quando ela é acionada — o que viabiliza estratégias de DR antes restritas a grandes empresas.

Runbook, teste e manutenção: o que mantém o plano vivo

Um DRP só vale o que vale quando é executado sob pressão — e isso depende de três disciplinas: um runbook claro, testes regulares e manutenção contínua. A documentação do Azure resume que um bom plano de DR deve conter um runbook claro, um plano de comunicação bem definido e um caminho de escalonamento estruturado^[4].

O que o runbook precisa conter

O runbook é o documento operacional da recuperação, escrito para ser executado por um técnico que não o escreveu. Ele reúne:

1. Inventário de sistemas críticos com nome, função, RTO, RPO, dono e contato de emergência.
2. Procedimento de recuperação por sistema: passo a passo para ativar backup, restaurar dados e subir o sistema, em linguagem clara.
3. Ordem de ativação respeitando as dependências mapeadas na BIA.
4. Contatos de emergência: quem aciona o plano, fornecedores com suporte 24/7, provedor de nuvem — em lista impressa e acessível offline.
5. Plano de comunicação e caminho de escalonamento: quem avisa clientes e stakeholders, quando e por qual canal.
6. Ambiente de backup: onde estão as cópias, como acessá-las e como se conectar.

Como testar sem colocar a produção em risco

O teste de DRP usa ambiente separado — restaura o backup em um servidor de teste, nunca em produção. A documentação do Azure recomenda dois formatos complementares: ensaiar o runbook em cadência regular, simulando cenários para esclarecer os papéis da equipe, e agendar simulados de failover (totais ou parciais) para validar os passos e os tempos reais de recuperação^[3]. A AWS é igualmente enfática: a estratégia de backup precisa incluir o teste da própria restauração, porque é o teste que revela backup corrompido, senha expirada ou procedimento desatualizado^[5]. Todo teste deve documentar tempo de recuperação real contra o alvo, problemas encontrados e correções.

Quando revisar o plano

O DRP é processo contínuo, não projeto único: sempre que o ambiente muda, o plano muda junto. Tanto a ISO 22301 quanto o Azure tratam a continuidade como ciclo de melhoria, revisado e atualizado regularmente para seguir relevante^[2][4]. Gatilhos típicos de revisão: nova aplicação implantada, mudança de provedor, saída ou entrada de pessoa-chave no time, problema encontrado em teste e a revisão periódica programada. O essencial é ter um dono claro responsável por manter o plano atualizado.

Quem decide e atua no momento do desastre

Quando o desastre acontece, alguém precisa ter autoridade definida para acionar o plano. A estrutura típica: o gestor de TI (ou CIO) avalia se é desastre ou falha pontual, ativa o procedimento, notifica os donos de negócio e dispara o plano de comunicação. Em empresas maiores, há comitê de crise. A primeira decisão é sempre a mesma — é desastre que justifica acionar o DRP completo, ou uma falha que a recuperação rápida resolve? Decidir isso rápido e bem evita tanto a paralisia quanto o acionamento desnecessário, que o próprio Azure aponta como custoso quando feito por alarme falso^[5].

Erros comuns que comprometem um DRP

A maioria dos DRPs que falham na hora H falha pelos mesmos motivos — e são falhas de processo, não de tecnologia.

Backup que nunca foi restaurado

O erro mais frequente e mais perigoso é confiar em um backup que ninguém testou restaurar — ele pode estar corrompido, incompleto ou com um procedimento que já não funciona. Tanto AWS quanto Azure insistem que testar a restauração é parte obrigatória da estratégia de backup, justamente por isso^[5][4].

Esquecer o failback e a comunicação

Dois pontos cegos recorrentes. O failback — voltar à operação no site primário depois que ele se recupera — é complexo e costuma ser esquecido no plano; os dados escritos durante o failover precisam de uma decisão consciente sobre como reconciliar^[4]. E a comunicação com clientes e stakeholders é tão crítica quanto a recuperação técnica: um sistema que volta sem que ninguém tenha avisado os clientes ainda gera dano de confiança.