Plano disaster recovery é o conjunto de procedimentos que define como a empresa retoma a operação após um incidente de TI — falha de servidor, ataque de ransomware, queda de energia ou desastre físico. Por isso, empresas sem plano disaster recovery levam semanas para retomar a operação após um incidente grave. Contudo, empresas com plano testado retomam em horas.
A Crowdertech orienta empresas na criação e no teste de plano disaster recovery e atende emergências 24 horas: (11) 99630-0675 · (11) 4863-3636.
O que é RTO e RPO no plano disaster recovery
Plano disaster recovery começa com dois números: RTO e RPO. Por isso, sem definir esses valores, o plano não tem critérios objetivos para avaliar se funcionou.
RTO (Recovery Time Objective) é o tempo máximo aceitável para retomar a operação após o incidente. Por isso, um e-commerce que define RTO de 4 horas precisa de infraestrutura e procedimentos que garantam retomada em 4 horas — não 24 horas. Contudo, RTO menor exige investimento maior em redundância e automação.
RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo. Por isso, RPO de 1 hora significa que o backup mais recente nunca pode ter mais de 1 hora. Contudo, RPO zero — sem perda de dados — exige replicação síncrona em tempo real, o que tem custo significativo.
Segundo o NIST SP 800-34r1, RTO e RPO são os fundamentos de qualquer plano disaster recovery corporativo. Por isso, a primeira reunião de criação do plano deve definir esses números com a diretoria — não com a equipe de TI isoladamente.
Componentes obrigatórios do plano disaster recovery
Inventário de ativos críticos
Plano disaster recovery começa com inventário completo dos sistemas críticos — servidores, bancos de dados, aplicações e storages. Por isso, o plano precisa definir a ordem de recuperação: o que sobe primeiro, o que pode esperar e o que pode ficar fora permanentemente. Além disso, cada sistema crítico precisa ter responsável definido, procedimento documentado e dependências mapeadas.
Estratégia de backup testada
Plano de recuperação de desastres sem backup testado não é plano — é ilusão. Por isso, o backup precisa ser verificado regularmente com restaurações reais, não só com confirmações de conclusão bem-sucedida do job. Contudo, backup imutável com Object Lock é o único tipo que garante sobrevivência a ransomware. Além disso, a estratégia 3-2-1 — 3 cópias, 2 mídias diferentes, 1 offsite — é o mínimo recomendado pelo NIST.
Procedimentos documentados e testados
Plano disaster recovery que existe só na cabeça do analista de TI é inútil durante uma crise — especialmente se esse analista estiver de férias ou indisponível. Por isso, cada procedimento de recuperação precisa estar documentado com passos numerados, prints de tela e credenciais de acesso armazenadas de forma segura. Além disso, o plano precisa incluir lista de contatos: fornecedores, operadoras, laboratórios de recuperação como a Crowdertech.
Plano de comunicação
Plano de recuperação de desastres inclui comunicação interna e externa. Por isso, a empresa precisa definir quem comunica o incidente aos clientes, quando comunica e o que comunica. Além disso, incidentes com dados pessoais têm prazo legal de 72 horas para notificação à ANPD sob a LGPD. Contudo, comunicação sem coordenação durante uma crise agrava o dano reputacional.
Como testar o plano disaster recovery
Plano disaster recovery só tem valor quando testado. Por isso, o teste precisa simular condições reais — não condições ideais onde tudo funciona perfeitamente.
Teste de tabletop — a equipe discute o cenário sem executar nada. Por isso, é o teste mais simples e revela gaps no plano sem risco. Além disso, é o ponto de partida para equipes que nunca testaram o plano.
Teste de restauração parcial — restaura sistemas não críticos em ambiente de teste. Por isso, valida os backups e os procedimentos sem afetar a produção. Contudo, não substitui o teste completo.
Teste de failover completo — simula o incidente real e executa o plano de ponta a ponta. Por isso, é o único teste que valida o RTO de verdade. Além disso, revela dependências ocultas que o teste de tabletop não detecta.
O CERT.br recomenda testes de restauração periódicos como parte obrigatória de qualquer política de backup e recuperação. Por isso, o plano disaster recovery deve incluir cronograma de testes com frequência definida — mensal para sistemas críticos, trimestral para os demais.
Perguntas frequentes
Empresa pequena precisa de plano disaster recovery?
PME precisa de plano disaster recovery formal? Sim — mas proporcional ao tamanho. Por isso, uma PME não precisa do mesmo plano de um banco, mas precisa saber responder a três perguntas básicas: onde está o backup, quem sabe restaurar e quanto tempo leva para voltar a funcionar. Contudo, sem essas respostas documentadas, qualquer incidente vira crise. Plano disaster recovery básico pode ser criado em um dia de trabalho.
Qual o custo de implementar plano disaster recovery?
Implementar plano disaster recovery é caro? O custo varia muito conforme o RTO e RPO definidos. Por isso, um plano com RTO de 24 horas e RPO de 24 horas custa muito menos que RTO de 1 hora. Contudo, o custo do plano disaster recovery é sempre menor que o custo de não ter um — o prejuízo médio por ransomware no Brasil chegou a R$ 6 milhões em 2026. Além disso, a Crowdertech orienta empresas na criação do plano disaster recovery sem custo adicional para clientes de recuperação.
Com que frequência testar o plano disaster recovery?
Qual a frequência ideal de testes do plano disaster recovery? Sistemas críticos — ERP, banco de dados, e-commerce — devem ter restauração testada mensalmente. Por isso, o teste mensal garante que os backups são válidos e que os procedimentos estão atualizados. Além disso, o plano completo deve ser testado integralmente pelo menos uma vez por ano. Contudo, qualquer mudança significativa de infraestrutura exige novo teste imediato.
A Crowdertech orienta na criação de plano disaster recovery e atende emergências 24 horas — (11) 99630-0675 · (11) 4863-3636.
Fontes: NIST SP 800-34r1 · CERT.br — Backup · ANPD — LGPD.