Como este tema funciona na sua empresa
DRP em pequenas empresas é simples: backup de dados críticos, lista de contactos de suporte, e plano manual de reconstrução de sistemas essenciais. O desafio é que frequentemente não existe — TI sabe o que fazer se algo cair, mas não há documentação. Prioridade: proteger dados de clientes, backup funcionando, lista impressa de contactos e passos básicos de recuperação.
DRP começa a ser estruturado por sistema crítico — e-mail, ERP, banco de dados — com RTO e RPO definidos por cada um. Backup automatizado e testado regularmente. Documentação de procedimentos por sistema. Desafio: manter documentação atualizada conforme sistemas mudam. Prioridade: definir quais sistemas são críticos, estabelecer targets de RTO/RPO, automatizar backup, testar semestral.
DRP sofisticado com site de disaster recovery, failover automático, equipes dedicadas, e testes regulares contínuos. Integrado com Business Continuity Plan corporativo. Documentação detalhada e revisão formal anual. Desafio: manter eficácia em contexto de transformação contínua — novos sistemas, mudanças de arquitetura. Prioridade: governance formal, arquitetura de DR robusta, testes validados, comunicação entre TI e negócio.
Plano de Recuperação de Desastres (DRP) é o conjunto de procedimentos, tecnologias e recursos documentados para recuperar sistemas de TI críticos e seus dados após uma interrupção ou desastre. DRP diferencia-se de Business Continuity Plan: DRP foca especificamente em recuperação de infraestrutura e dados de TI, enquanto BC é mais amplo e inclui processos operacionais inteiros[1].
DRP e Business Continuity Plan: qual é a diferença?
A confusão entre DRP e BC é comum. Ambos tratam de recuperação após desastre, mas de ângulos diferentes.
Business Continuity Plan (BCP) é o plano geral da empresa para manter a operação funcionando após uma perturbação — cobre processos, pessoas e comunicação. Plano de Recuperação de Desastres (DRP) é o componente técnico de BC: como a TI faz sua parte na recuperação.
Exemplo: uma empresa sofre outage de 6 horas em seu data center. O DRP ativa redundância em outro site, recupera dados, traz sistemas online. O BCP ativa equipes alternativas, redireciona clientes, mantém comunicação. Sem DRP, o BCP não funciona. Sem BCP, o DRP recupera infraestrutura mas a empresa não consegue operar com efetividade.
Identificar sistemas e dados críticos
O primeiro passo de um DRP efetivo é saber o que precisa ser recuperado e em qual ordem. Nem tudo é igualmente crítico.
A análise começa com Business Impact Analysis (BIA): para cada sistema principal, responder a três perguntas:
- Qual é o impacto se este sistema ficar down? — em receita perdida, clientes afetados, operação travada, risco regulatório?
- Por quanto tempo podemos viver sem ele? — minutos, horas, dias? Isso é o RTO (tempo máximo aceitável de indisponibilidade).
- Qual é a quantidade máxima de dados que podemos perder? — transações dos últimos 10 minutos, 1 hora, 1 dia? Isso é o RPO (ponto máximo aceitável de perda de dados).
Sistemas críticos típicos: e-mail (muitas empresas não funcionam sem), ERP (controla vendas, estoque, financeiro), banco de dados de clientes, website (se a empresa vende online). Sistemas não-críticos: intranets, portais internos, ferramentas de colaboração — já têm alternativas rápidas ou podem ficar indisponíveis por horas.
Criticidade por porte de empresa
Normalmente 2-3 sistemas críticos: e-mail, um sistema de gestão (ERP light ou planilhas), dados de clientes/vendas. RTO realista: 4-8 horas. RPO: até 1 dia de dados perdidos é aceitável se houver backup diário.
5-10 sistemas críticos por criticidade: Tier 1 (e-mail, ERP, banco de clientes — RTO máximo 2 horas); Tier 2 (sistemas de suporte — RTO máximo 6 horas); Tier 3 (ferramentas internas — RTO máximo 24 horas).
Dezenas de sistemas com criticalidade definida e matriz de dependências (sistema A depende de B, que depende de C). RTO pode ser minutos para sistemas de missão crítica. RPO: zero-data-loss para alguns sistemas (banco de dados transacionais).
Definir RTO e RPO para cada sistema
RTO (Recovery Time Objective) é quanto tempo máximo o sistema pode estar fora de operação. RPO (Recovery Point Objective) é quanto tempo de dados pode ser perdido.
A confusão é comum: RTO é sobre tempo de disponibilidade, RPO é sobre perda de dados. Um e-mail pode ter RTO de 2 horas (a empresa consegue esperar 2 horas para e-mail voltar) mas RPO de 0 (não pode perder nenhum e-mail — deve estar replicado em tempo real).
RTO e RPO devem ser decididos pelo negócio, não por TI. O papel de TI é informar as opções, os custos e o que é tecnicamente viável:
- RTO de minutos (failover automático): requer infraestrutura cara, redundância em múltiplos sites, monitoramento 24/7. Custa muito.
- RTO de horas (recuperação semi-automatizada): backup replicado ou em cloud, scripts de recuperação prontos, equipe treinada. Custo moderado.
- RTO de 1+ dia (recuperação manual): backup local ou em fita, procedimentos documentados, suporte disponível. Custo baixo, mas risco operacional.
A realidade das PMEs brasileiras: a maioria opera com RTO de 4-8 horas e RPO de 24 horas por razões de custo. Escolher um alvo realista é melhor que ter DRP ambicioso e intestável.
Estratégias de recuperação: backup, replicação, redundância
Existem várias estratégias para recuperar sistemas. Cada uma tem custo e complexidade diferentes.
Backup
Cópia dos dados em local separado — disk, fita ou cloud. A estratégia mais comum em PMEs. Deve ser testada regularmente (restaurar, verificar integridade). Backup diário é padrão, backup mais frequente para dados críticos. Desvantagem: não recupera instantaneamente, demanda tempo para restaurar dados. Vantagem: barato, simples, efetivo para a maioria dos casos.
Replicação
Sincronização de dados em tempo real para outro servidor ou local. O sistema principal falha, a cópia em tempo real está pronta. Mais rápido que backup, mas exige link de rede confiável entre sites. Usado para sistemas críticos (e-mail, banco de dados). Mais caro que backup.
Failover automático
A infraestrutura detecta a falha e muda automaticamente para o servidor/site de backup. Zero downtime percebido pelos usuários. Exige arquitetura sofisticada, monitoramento contínuo, site de recuperação sempre operacional. Muito caro, usado em operações que não podem parar (fintech, saúde).
Site de Disaster Recovery
Segundo data center ou site em outra região geográfica, com cópia de sistemas críticos. Se o data center principal sofrer desastre (incêndio, alagamento), a empresa ativa o site de DR. Desafio: manter site de DR atualizado (custa dinheiro estar parado esperando desastre). Solução: usar site híbrido (site de DR roda testes, carga de desenvolvimento, enquanto fica pronto para failover).
Documentação de DRP
DRP documentado é DRP que funciona. DRP só na cabeça de um gerente é risco.
Documentação essencial:
- Inventário de sistemas críticos: lista com nome, função, RTO, RPO, proprietário, contacto de emergência.
- Procedimento de recuperação por sistema: passo a passo de como ativar backup, restaurar dados, trazer sistema online. Deve ser executável por um técnico diferente do que escreveu — linguagem clara, sem jargão.
- Contactos de emergência: quem ligar se desastre acontecer (CIO, gerente de TI, vendor suporte 24/7, fornecedor de cloud). Lista impressa em local seguro.
- Cronograma de ativação: qual sistema recuperar primeiro, qual segundo, etc. Ordem importa: recuperar o ERP antes do e-mail muitas vezes faz sentido.
- Plano de comunicação: quem avisa clientes, quando, por qual canal. Comunicação é tão importante quanto recuperação técnica.
- Ambiente de backup: onde estão cópias de dados, qual é a senha de acesso, como se conecta. Documentação clara economiza horas em crise.
Documentação deve ser revisada anualmente e atualizada sempre que sistemas mudarem — nova aplicação, mudança de provider, alteração de infraestrutura.
Testar o DRP
DRP não testado é DRP que não funciona. Teste revela cenários que ninguém previu — senha expirada, backup corrompido, procedimento desatualizado.
Frequência de teste por porte
Teste anual completo (restaurar backup de verdade, verificar que dados ficaram íntegros). Teste de backup mensal (fazer backup, verificar que arquivo existe e é recuperável, sem restaurar em produção).
Teste trimestral de cada sistema crítico (rodar procedimento, registrar tempo de recuperação, documentar problemas). Teste anual completo (simular desastre de verdade, envolve negócio também, 1-2 dias).
Testes contínuos por sistema (sempre que há mudança, faz teste de DR do sistema). Teste completo semestral (todos os sistemas, todas as áreas envolvidas, com simulação de desastre real).
Teste deve documentar: tempo de recuperação real (vs. target), problemas encontrados, correções necessárias, e assinatura de quem executou. Teste sem documentação não vale — não se aprende com experiência não registrada.
Respostas a desastres
Quando desastre acontece, TI precisa saber quem toma decisão e em que ordem ativar recuperação.
Estrutura típica: CIO (ou gerente de TI) ativa plano, notifica business owners, ativa procedure de recuperação, comunica com stakeholders. Em empresas muito grandes, há comitê de crise — CIO, CFO, diretor operacional. Primeira decisão: é desastre mesmo ou falha pontual? Se for desastre, ativa DRP completo. Se for falha de um servidor, pode tentar recuperação rápida antes de ativar plano inteiro.
Manutenção de DRP
DRP não é projeto único — é processo contínuo. Sempre que sistema muda, DRP deve mudar também.
Triggers para revisar DRP:
- Nova aplicação implementada
- Mudança de provider (email moveu para cloud, por exemplo)
- Saída ou entrada de pessoa-chave no time de TI
- Teste encontrou problema
- Revisão anual programada
Manutenção eficaz: alguém tem como responsabilidade manter DRP atualizado. Pode ser o gerente de TI ou o especialista de infraestrutura. Importante: ter dono claro.
Sinais de que sua empresa precisa de um DRP robusto
Se você se reconhece em três ou mais cenários abaixo, é tempo de estruturar ou fortalecer o plano de recuperação de desastres.
- Você não consegue descrever o que aconteceria se o servidor principal caísse amanhã
- Backup acontece, mas ninguém sabe se recuperação funciona — nunca foi testado
- Dados críticos de clientes ou operação estão em um único lugar (servidor local, sem cópia)
- O tempo para recuperar um sistema crítico é desconhecido ou seria de dias
- Pessoas-chave de TI saem e ninguém mais consegue recuperar os sistemas
- Empresa sofreu perda de dados ou indisponibilidade no passado sem ter aprendido o que fazer próxima vez
- Regulação setorial (saúde, financeiro, educação) exige plano documentado e testado, e a empresa não tem
Caminhos para implementar ou fortalecer DRP
O grau de sofisticação de um DRP depende dos recursos disponíveis e do risco aceitável. Abordagem interna é viável em muitos casos; apoio especializado acelera e reduz riscos de gaps.
Viável quando há uma ou mais pessoas de TI com experiência em infraestrutura e tempo disponível.
- Perfil necessário: arquiteto de TI ou especialista de infraestrutura com visão de continuidade
- Tempo estimado: 2 a 4 meses para DRP básico (backup estruturado, documentação, primeiro teste)
- Faz sentido quando: empresa é pequena/média, sistemas não são ultra-complexos, equipe tem experiência
- Risco principal: gaps na cobertura, procedimentos não realistas, manutenção negligenciada depois
Recomendado quando empresa precisa de DRP robusto ou quando expertise interna é limitada.
- Tipo de fornecedor: Consultoria de Infraestrutura/DR, Provedor de Disaster Recovery as a Service (DRaaS), Vendor de backup especializado
- Vantagem: avaliação completa (BIA estruturada), arquitetura de DR apropriada ao porte, testes validados, documentação profissional
- Faz sentido quando: empresa tem dados críticos, risco de perda é alto, regulação exige conformidade documentada
- Resultado típico: em 3 a 6 meses, DRP estruturado, site de recuperação ativo, primeiro teste executado
Precisa estruturar um plano de recuperação de desastres para sua TI?
Se recuperação de desastres é uma prioridade, o oHub conecta você gratuitamente a consultores e vendors especializados em DRP e infraestrutura. Em menos de 3 minutos, você descreve sua necessidade e recebe propostas personalizadas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é DRP?
DRP (Plano de Recuperação de Desastres) é o conjunto de procedimentos, tecnologias e recursos para recuperar sistemas de TI críticos após uma interrupção. Diferencia-se de Business Continuity Plan: DRP foca em recuperação de infraestrutura e dados de TI, enquanto BC inclui processos operacionais inteiros.
Qual é a diferença entre DRP e Business Continuity Plan?
DRP é o componente técnico de continuidade de negócio — como TI recupera sistemas. BCP é o plano geral da empresa — como manter operação funcionando. Sem DRP, BCP não funciona. Sem BCP, TI recupera infraestrutura mas empresa não consegue operar com efetividade.
O que é RTO e RPO em DRP?
RTO (Recovery Time Objective) é o tempo máximo que um sistema pode estar indisponível. RPO (Recovery Point Objective) é a quantidade máxima de dados que pode ser perdida. Exemplo: RTO de 2 horas (máximo 2h indisponibilidade), RPO de 0 (não pode perder nenhum dado — sincronizado em tempo real).
Como fazer teste de DRP?
Teste de DRP restaura backup de verdade em ambiente separado, verifica que dados ficaram íntegros, e cronometra tempo de recuperação. Frequência: anual para pequenas empresas, trimestral para médias, contínuo para grandes. Teste deve ser documentado — registrar tempo, problemas encontrados, correções necessárias.
Qual é o custo de ter um bom DRP?
Custo depende de RTO desejado. Backup simples (RTO de dias): baixo custo. Replicação em tempo real (RTO de horas): custo moderado. Site de DR com failover automático (RTO de minutos): custo alto. Balancear risco vs. orçamento é decisão do negócio, não de TI.
Teste de DRP precisa colocar sistemas em risco?
Não. Teste deve usar ambiente separado — restaurar backup em servidor de teste, não em produção. Teste de backup mensal (rápido, sem risco). Teste anual completo (pode custar tempo, 1-2 dias, mas sem risco de falha em produção se bem planejado).
Fontes e referências
- NIST. Special Publication 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. National Institute of Standards and Technology.
- ISO/IEC. ISO/IEC 22301:2019 — Business Continuity Management Systems. International Organization for Standardization.
- Axelos. ITIL 4 Foundation: Service Continuity Management. PeopleCert/Axelos.