A maioria das empresas tem algum documento chamado “Plano de DR”. Pouquíssimas têm um DRP que funciona quando precisam de verdade. A diferença está nos detalhes: runbook testado, responsáveis definidos, critérios de ativação claros, e uma cadência de testes que garante que o plano ainda funciona 18 meses depois de escrito.
DRP vs BCP: o que é o quê
DRP (Disaster Recovery Plan): foca na recuperação de infraestrutura de TI após um evento disruptivo. Define como restaurar sistemas, dados e conectividade ao estado operacional.
BCP (Business Continuity Plan): plano mais amplo que abrange a continuidade do negócio como um todo — não só TI. Inclui onde os colaboradores trabalharão, como os processos de negócio continuarão sem os sistemas, comunicação com clientes e fornecedores.
Eles se complementam: o BCP é o plano maior, e o DRP é a seção de TI dentro dele. Para a maioria das PMEs, o DRP é o que existe. O BCP deveria existir também — mas raramente existe de forma completa.
Este guia foca no DRP — e em como construir um que seja executável, não apenas arquivável.
Definindo RPO e RTO por sistema
O primeiro passo do DRP é definir, para cada sistema crítico, o quanto de perda de dados é aceitável (RPO) e em quanto tempo precisa estar operando (RTO). Esses números determinam tudo — a estratégia de DR, o custo, a infraestrutura necessária.
Como definir com a área de negócio (não com TI):
Leve cada sistema para o responsável de negócio e faça duas perguntas:
- “Se esse sistema ficar indisponível, quando começa o impacto real para o negócio?” (Resposta → RTO)
- “Se esse sistema voltar agora mas com os dados de 4 horas atrás, o que você perde? E de ontem? E da semana passada?” (Resposta → RPO)
As respostas definem os objetivos. TI então determina se é tecnicamente viável e a que custo.
Exemplo de matriz RTO/RPO:
| Sistema | RTO | RPO | Estratégia |
|---|---|---|---|
| ERP (produção) | 4 horas | 1 hora | Warm standby com replicação |
| E-mail (Exchange) | 8 horas | 4 horas | Pilot light |
| File server | 24 horas | 24 horas | Backup & Restore |
| Sistema de ponto | 48 horas | 24 horas | Backup & Restore |
| Intranet / Wiki | 72 horas | 48 horas | Backup & Restore |
As 4 estratégias de DR: quando usar cada uma
1. Backup & Restore (RTO: 4–24h, RPO: horas)
O backup é copiado para um local seguro. Em caso de desastre, você provisiona novo ambiente e restaura o backup. Mais lento, mas mais barato.
Quando usar: sistemas de suporte ao negócio, dados históricos, sistemas que não são críticos para operação diária. Inadequado para sistemas com RTO < 4h.
Custo relativo: 1x (referência)
2. Pilot Light (RTO: 1–4h, RPO: 15min–1h)
A infraestrutura mínima fica em standby no site de DR: banco de dados com replicação ativa, dados sincronizados. Os servidores de aplicação ficam desligados (ou em tamanho muito reduzido). Em um desastre, você “acende” o ambiente — provisiona os servidores de aplicação rapidamente, aponta o DNS para o site de DR.
Quando usar: sistemas importantes que têm tolerância de algumas horas, mas não de um dia inteiro.
Custo relativo: 3–5x o custo do Backup & Restore.
3. Warm Standby (RTO: 15min–1h, RPO: minutos)
Um ambiente menor mas funcional roda continuamente no site de DR. Dados são replicados em tempo real ou quase real. Em caso de desastre, você redireciona o tráfego para o site de DR e escala o ambiente (adiciona capacidade).
Quando usar: sistemas críticos onde horas de downtime têm impacto financeiro significativo. ERP de empresas que não podem parar.
Custo relativo: 5–10x o Backup & Restore.
4. Active-Active (RTO: segundos, RPO: zero ou quase)
Dois sites operam simultaneamente, compartilhando a carga. Um balanceador de carga distribui requisições. Se um site falha, o outro absorve todo o tráfego automaticamente. Sem interrupção perceptível.
Quando usar: sistemas mission-critical onde downtime é literalmente inaceitável — trading, sistemas de pagamento, plataformas de e-commerce de alta escala.
Custo relativo: 10–20x o Backup & Restore. O site de DR precisa ter capacidade para absorver 100% da carga, então você paga por capacidade dobrada permanentemente.
Montando o runbook de DR
O runbook é o manual de instruções do DR. É o que sua equipe vai seguir às 3h da manhã quando um desastre acontecer. Precisa ser tão claro que alguém que nunca executou o DR consiga seguir — porque a pessoa que sempre fez isso pode estar de férias ou ser exatamente ela que está doente.
Estrutura do runbook:
Seção 1: Critérios de ativação
- O que constitui um “desastre” que justifica ativar o DRP? (Não confundir com incidente de TI normal)
- Exemplos: datacenter principal inacessível por mais de X horas; perda total de link de comunicação; falha de storage principal sem ETA de recuperação
- Quem tem autoridade para declarar o desastre e ativar o DRP?
Seção 2: Contatos e responsabilidades
- Árvore de comunicação: quem liga para quem, em que ordem
- Contatos do provedor cloud (suporte 24/7, número de emergência, dados do contrato)
- Contatos de fornecedores críticos (fabricante do ERP, suporte do banco de dados)
- Responsável técnico por cada sistema crítico (com backup — o substituto se o principal não estiver disponível)
Seção 3: Procedimentos passo a passo por sistema
Para cada sistema crítico, uma sequência numerada de ações:
ERP — Procedimento de failover para DR
1. Verificar que o site principal está realmente indisponível (ping, acesso ao portal)
2. Contatar provedor cloud do site principal para confirmar causa e ETA [Contato: 0800-xxx-xxxx]
3. Se ETA > 4 horas ou causa desconhecida: ativar DRP (obter aprovação do Gerente de TI)
4. Acionar equipe: [lista de pessoas e contatos]
5. Acessar portal cloud do site de DR [URL: xxx, credencial: vault/DR-credentials]
6. Iniciar VMs do ERP no site de DR em ordem: DB → APP → WEB
7. Aguardar 10 minutos e verificar status das VMs
8. Testar acesso ao ERP no site de DR [URL de DR: xxx]
9. Validar integridade dos dados: executar relatório de últimas transações e comparar com backup
10. Atualizar DNS para apontar para site de DR [Registrador: xxx, TTL: 60s]
11. Aguardar propagação do DNS (5–15 minutos)
12. Comunicar usuários via [canal: e-mail/Teams/WhatsApp] que sistema está operando no DR
13. Monitorar sistema nas próximas 4 horas
14. Documentar hora de ativação e eventos no log de incidenteSeção 4: Procedimento de retorno ao site principal
Tão importante quanto o failover é o failback — quando o site principal volta, como você retorna sem perder os dados criados durante o DR?
Como testar o DR — três níveis de teste
Nível 1: Tabletop (Simulação em mesa)
Periodicidade: semestral no mínimo
O quê: reunião de 2–3 horas com todos os responsáveis. Um moderador apresenta um cenário de desastre e a equipe percorre verbalmente o runbook. Não há ativação real do DR.
Objetivo: identificar lacunas no runbook, responsáveis que não sabem o que fazer, dependências não documentadas.
Nível 2: Restore parcial
Periodicidade: trimestral
O quê: restaurar um sistema específico (preferencialmente não o mais crítico primeiro) a partir do backup para um ambiente isolado. Verificar integridade dos dados, tempo de restore real vs. RTO documentado.
Objetivo: validar que o backup funciona e que o processo de restore é exequível no tempo definido.
Nível 3: Failover real
Periodicidade: anual no mínimo para sistemas críticos; semestral para sistemas mission-critical
O quê: ativar o ambiente de DR real — redirecionar DNS, testar que usuários conseguem trabalhar no ambiente de DR, validar todas as integrações externas.
Objetivo: o único teste que prova que o DR funciona de verdade.
Regra de ouro: se você não testou o failover nos últimos 12 meses, você não tem DR. Você tem esperança.
Frequência de teste por criticidade
| Tipo de sistema | Tabletop | Restore parcial | Failover real |
|---|---|---|---|
| Mission-critical (RTO < 1h) | Trimestral | Mensal | Semestral |
| Crítico (RTO 1–4h) | Semestral | Trimestral | Anual |
| Importante (RTO 4–24h) | Anual | Semestral | Bienal |
| Suporte (RTO > 24h) | Anual | Anual | A cada 3 anos |
Mantendo o plano atualizado
Um DRP que foi escrito há 2 anos e nunca atualizado é quase tão perigoso quanto não ter DRP — você pensa que está protegido mas o plano descreve um ambiente que já não existe.
Gatilhos obrigatórios de atualização:
- Qualquer novo sistema crítico adicionado ao ambiente
- Mudança de provedor cloud ou de datacenter de DR
- Mudança de responsáveis técnicos (pessoas que saíram da empresa)
- Resultado de teste de DR que revelou lacunas
- Mudança na estrutura da empresa (M&A, nova unidade, novo processo de negócio crítico)
Revisão periódica: independente de gatilhos, revise o DRP completo anualmente. Agende como projeto — com data marcada no início do ano e responsável nomeado.
Precisa de ajuda para estruturar seu DRP ou implementar a infraestrutura de DR? A Adentro oferece DR como serviço com RTO e RPO contratuais para empresas brasileiras.