DRP (Disaster Recovery Plan): o que é, como elaborar e com que frequência testar

Um DRP, ou Disaster Recovery Plan, é o plano que define como a operação volta a funcionar depois de uma parada grave: o que sobe primeiro, em quanto tempo, com quanta perda de dados aceitável, quem executa e como se confirma que o ambiente está de pé outra vez. Sem esse plano, a recuperação depende de quem estiver disponível e do que essa pessoa lembrar no momento da crise.

Quase toda empresa de médio e grande porte tem backup. Ainda assim, poucas conseguem dizer, com número, em quanto tempo voltam a operar depois de um incidente sério. Essa distância entre ter cópia dos dados e conseguir retomar a operação é exatamente o que um DRP resolve.

Se a sua dúvida ainda está na camada anterior, a das cópias e da retenção, o artigo sobre as vantagens do backup em nuvem trata da regra 3-2-1 e do que diferencia backup de recuperação.

Por que a recuperação demora mais do que a empresa imagina

O cenário se repete. O incidente acontece, o backup está íntegro, e mesmo assim a operação leva dias para voltar. Não por falta de dados, mas por falta de sequência.

A equipe começa a restaurar pelo sistema que alguém lembrou primeiro, descobre no meio do caminho que ele depende de um serviço de autenticação que ainda não subiu, volta atrás, sobe o serviço de autenticação, e aí percebe que falta um certificado que estava guardado no ambiente que caiu. Cada uma dessas descobertas custa horas, e mapear as dependências antes revelaria todas elas.

É a mesma lógica de uma mudança de escritório. Na prática, ter todas as caixas é diferente de saber o que abrir primeiro para a empresa voltar a trabalhar amanhã de manhã. O DRP é a ordem das caixas.

RTO e RPO, os dois números que o negócio define

Todo plano se apoia em dois números, e eles não são decisão da TI.

O RTO, Recovery Time Objective, é o tempo máximo aceitável entre a parada e o retorno do serviço. A pergunta que ele responde é: quanto tempo a empresa aguenta sem esse sistema.

O RPO, Recovery Point Objective, é a perda máxima de dados aceitável, medida em tempo. A pergunta é: se perdermos as últimas transações, quantas horas de trabalho serão refeitas à mão.

Quem responde é o negócio. A TI dimensiona a arquitetura que atende a essas respostas, e o custo acompanha essa escolha de perto.

Na primeira conversa, é comum todos os sistemas serem classificados como críticos, com RTO de uma hora para tudo. A priorização real aparece quando o custo da arquitetura correspondente entra na mesa. Aí o ERP que sustenta o faturamento continua com RTO de horas, e o sistema interno de chamados aceita voltar no dia seguinte sem que ninguém perca dinheiro com isso.

O que entra em um DRP

Feito o levantamento, o plano se organiza basicamente em quatro frentes:

• Classificação e dependências. A lista de sistemas com criticidade definida pelo negócio, e o mapa do que cada um precisa para funcionar. É a parte mais barata do trabalho e a que mais reduz o tempo de retorno.
• Estratégia por carga. A decisão de como cada sistema é recuperado. Nem todo sistema justifica o mesmo investimento.
• Procedimento executável. O passo a passo real, com ordem de subida, comandos, credenciais acessíveis fora do ambiente que caiu e critério objetivo para dizer que o sistema voltou. Documento genérico não recupera ambiente.
• Papéis e comunicação. Quem declara o desastre, quem executa, quem fala com clientes e quem autoriza o retorno à operação normal, com contatos alternativos, porque a crise pode atingir o próprio e-mail da empresa.

Como escolher a estratégia de recuperação

Quatro modelos cobrem a maioria dos casos, e a diferença entre eles é sempre a mesma troca: quanto mais rápido o retorno, maior o custo de manter a estrutura esperando.

No backup e restauração, há cópias dos dados e o ambiente sobe de novo quando necessário. É o mais barato e o mais lento, com retorno em horas ou dias.

No pilot light, o essencial fica ativo em escala mínima, normalmente o banco de dados replicado, e o restante sobe no acionamento. Retorno em horas.

No warm standby, uma cópia reduzida do ambiente roda o tempo todo e assume a operação com escala ampliada. Retorno em minutos.

No ativo-ativo, dois ambientes operam em paralelo e o tráfego é redirecionado. Retorno quase imediato, e o modelo mais caro.

A escolha é feita por sistema, não para a empresa inteira. O desenho mais comum combina os extremos: ativo-ativo no que sustenta a receita, backup e restauração no que pode esperar.

A nuvem mudou essa conta para melhor. Manter um segundo ambiente deixou de exigir um data center ocioso, porque a nuvem provisiona os recursos quando necessários e a replicação entre regiões resolve boa parte do desenho. O que não mudou é a necessidade do plano: replicação sem procedimento, sem RTO acordado e sem teste é infraestrutura, não continuidade.

Por que o plano falha na hora H

Mesmo com um bom desenho inicial, os planos falham por motivos conhecidos.

O primeiro é o plano escrito para auditoria. Ele atende ao questionário, fica bem no relatório e não serve na madrugada do incidente, porque não tem o detalhe de execução.

O segundo é a documentação guardada dentro do ambiente que deveria ser recuperado. Quando o ambiente cai, o plano cai junto.

O terceiro é o acesso concentrado em uma pessoa. Se a recuperação depende de quem está de férias ou fora do ar, o RTO combinado vira estimativa otimista.

E o quarto é o plano desatualizado. O ambiente muda todo mês, o plano foi escrito uma vez, e a recuperação é tentada com um mapa antigo.

O teste, que é a parte que quase ninguém faz

Um plano que nunca foi executado é uma hipótese. O teste é o que transforma o RTO de intenção em número medido, e ele tem três níveis.

A simulação de mesa percorre o plano verbalmente diante de um cenário, sem interromper nada. Parece pouco, e é onde aparecem as lacunas de responsabilidade e os contatos errados.

O teste parcial recupera um sistema no ambiente alternativo, em janela programada. Valida o procedimento e mede o tempo real.

O failover completo transfere a operação para o ambiente secundário. É o único que comprova o RTO na prática, e o que exige mais preparação.

A cadência que funciona é revisão anual do plano e teste parcial semestral nos sistemas críticos, com um registro que anote o tempo medido, e não o tempo estimado. A diferença entre esses dois números costuma ser a informação mais útil do exercício.

Como a Integrity-UX conduz esse trabalho

Começamos pela classificação dos sistemas junto das áreas de negócio, porque RTO e RPO são decisões do negócio, e mapeamos as dependências entre as aplicações, que é onde se perde tempo na hora da recuperação. A partir daí, definimos a estratégia de cada carga, escrevemos o procedimento em formato executável e atribuímos os papéis.

Depois vêm os testes, com registro do tempo real de retorno, e a revisão periódica que mantém o plano alinhado a um ambiente que não para de mudar.

Conheça o serviço de DRP da Integrity-UX ou fale com um especialista.

Próximos passos

Se a sua empresa tem backup mas não sabe dizer em quanto tempo volta a operar, o primeiro passo não é comprar tecnologia. É responder, com o negócio, quanto tempo cada sistema pode ficar parado e quanta informação pode ser perdida. Esses dois números definem todo o resto, inclusive o investimento.

Perguntas frequentes

O que é DRP?

DRP, ou Disaster Recovery Plan, é o plano de recuperação de desastres: o documento que define como a operação de TI volta a funcionar depois de uma parada grave, com prioridades, prazos, procedimentos e responsáveis.

Qual a diferença entre DRP e backup?

Backup é a cópia dos dados. DRP é o plano que coloca a operação de volta no ar, com ordem de recuperação, ambiente alternativo, responsáveis e critério de validação. O backup é insumo do plano, não o plano.

O que são RTO e RPO?

RTO é o tempo máximo aceitável até o serviço voltar. RPO é a perda máxima de dados aceitável, medida em tempo. Os dois são definidos pelo negócio e determinam o custo da solução.

Com que frequência o DRP deve ser testado?

Revisão do plano ao menos uma vez por ano e teste parcial semestral nos sistemas críticos. Toda mudança relevante de arquitetura pede nova validação.

DRP é obrigatório?

Não existe lei brasileira que exija um plano com esse nome. A LGPD obriga a adoção de medidas de segurança que preservem a disponibilidade dos dados, e a norma ISO 22301 trata de continuidade de negócios. Setores regulados, como o financeiro, têm exigências próprias.

Quanto tempo leva para elaborar um DRP?

Depende do número de sistemas e da maturidade do ambiente. O que define o prazo é o levantamento de dependências e a definição de RTO e RPO com as áreas de negócio, não a parte técnica.

Este conteúdo foi produzido pela equipe da Integrity-UX, consultoria de TI especializada em infraestrutura, continuidade e nuvem para médias e grandes empresas.

Fonte: ABNT NBR ISO 22301, sistemas de gestão de continuidade de negócios.