Plano de recuperação de desastres (DR) para PMEs

Imagine que um ransomware criptografou seus servidores nesta madrugada. Você tem backup — ótimo. Mas quem restaura? Em que ordem? Quanto tempo até a empresa voltar a faturar? Onde está a documentação? Se você não sabe responder, tem backup, mas não tem um plano de recuperação de desastres. E é o plano que salva o negócio.

O plano de recuperação de desastres (DR, de disaster recovery) é o conjunto de procedimentos para colocar a operação de volta no ar depois de um incidente grave. Backup é uma peça dele — não o todo.

Backup x plano de recuperação de desastres

A confusão é comum, mas a diferença é decisiva:

• Backup é ter a cópia dos dados. Responde: "os dados existem em algum lugar seguro?"
• Recuperação de desastres é o plano para usar essa cópia e retomar a operação. Responde: "como, em quanto tempo e em que ordem voltamos a funcionar?"

Ter backup sem plano de recuperação é como ter extintor sem ninguém treinado para usá-lo no incêndio.

Se você ainda não estruturou o backup, comece pelo nosso guia da regra 3-2-1 — ele é a fundação sobre a qual o plano de DR é construído.

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

Todo plano de DR gira em torno de duas metas:

• RTO (Recovery Time Objective): quanto tempo a empresa aguenta parada. É a meta de tempo para retomar a operação após o desastre.
• RPO (Recovery Point Objective): quanto de dados a empresa aceita perder. Se o backup roda a cada 24h, o RPO é de até um dia de trabalho.

Esses dois números definem quanto investir: um RTO de minutos e RPO de segundos exige infraestrutura redundante e cara; um RTO de horas e RPO de um dia é mais econômico. O certo é o que o seu negócio realmente precisa — não mais, não menos.

O que compõe um plano de DR

1. Inventário dos sistemas críticos: o que precisa voltar primeiro? ERP, e-mail, telefonia, site? Nem tudo tem a mesma prioridade.
2. RTO e RPO por sistema: cada sistema crítico recebe suas metas de tempo e perda aceitável.
3. Procedimentos documentados: o passo a passo da restauração, escrito de forma que outra pessoa consiga executar — não só "quem fez".
4. Responsáveis definidos: quem aciona o quê, com contatos atualizados.
5. Infraestrutura alternativa: servidores em nuvem ou secundários para subir a operação enquanto o ambiente principal é recuperado.
6. Plano de comunicação: como avisar equipe, clientes e fornecedores durante a indisponibilidade.
7. Testes periódicos: simulações que provam que o plano funciona antes que o desastre real chegue.

Os erros mais comuns

• Nunca testar o plano: o teste é a única prova de que ele funciona. Plano não testado é só um documento.
• O plano está "na cabeça" de alguém: se essa pessoa estiver de férias ou tiver saído, a empresa fica refém.
• Ignorar dependências: sistemas dependem uns dos outros; restaurar na ordem errada trava tudo.
• Esquecer a comunicação: no meio da crise, ninguém sabe o que dizer aos clientes.
• Plano desatualizado: a empresa muda, os sistemas mudam — o plano precisa acompanhar.

Como começar

Não é preciso um projeto gigante para dar o primeiro passo:

1. Liste os 3 a 5 sistemas sem os quais a empresa não opera.
2. Defina, para cada um, quanto tempo de parada e de perda de dados é tolerável.
3. Documente como restaurar cada um — e quem é o responsável.
4. Faça um teste de restauração real e cronometre. O resultado vira sua linha de base.

Conclusão

Desastres de TI não avisam — incêndio, falha de hardware, erro humano ou ransomware podem parar a empresa a qualquer momento. A diferença entre um susto e uma catástrofe é ter, ou não, um plano testado para voltar a operar. Backup guarda seus dados; o plano de DR garante que eles voltem a gerar receita rápido.

O backup gerenciado e a continuidade fazem parte da TI Gerenciada da Hexan. Veja os planos ou fale com um especialista para estruturar o seu plano.