Todo escritório contábil que já passou por um susto sério de TI conhece a diferença entre “ter backup” e “conseguir voltar a operar rápido”. Afinal, um arquivo de backup guardado em algum lugar não garante, por si só, que o escritório volta a funcionar em horas em vez de dias. Essa diferença tem nome: plano de recuperação de desastres, ou DRP (Disaster Recovery Plan). E é um documento que a maioria dos escritórios contábeis simplesmente não tem.

Ter backup não garante uma recuperação de servidor rápida. Essa garantia só vem de um plano de recuperação de desastres testado, como este artigo explica.

Recuperação de servidor não é o mesmo que backup — entenda a diferença

Backup é a matéria-prima. Já o DRP é o processo. Além disso, ter os dados salvos não define quanto tempo leva para restaurar um servidor inteiro, reconfigurar acessos, reinstalar sistemas e voltar a atender clientes. Escritórios que só têm backup, sem plano, costumam descobrir na hora do desastre que “restaurar” significa dias de trabalho manual — exatamente quando menos podem parar.

O que é RTO e RPO e por que eles definem o prejuízo de uma parada

Dois conceitos resumem o que realmente importa num plano de recuperação:

• RTO (Recovery Time Objective): quanto tempo o escritório pode ficar parado até voltar a operar. Para um escritório contábil em época de fechamento, um RTO de 3 dias pode significar multa e cliente perdido. Já um RTO de 4 horas muda completamente esse cenário.
• RPO (Recovery Point Objective): quantos dados o escritório pode se dar ao luxo de perder, medido em tempo. Assim, backup diário significa que, no pior caso, você perde até 24 horas de lançamentos. Para alguns escritórios isso é aceitável, para outros não.

Ou seja, definir esses dois números, antes de precisar deles, é o que transforma backup em plano de verdade.

Os pilares de um DRP para escritório contábil

Um plano de recuperação de desastres para contabilidade cobre quatro frentes. A primeira é o servidor: como e onde reconstruir o ambiente, seja em nuvem ou em hardware reserva. A segunda são os dados: onde estão as cópias e qual a garantia de integridade, como no protocolo 3-2-1. A terceira é o acesso remoto, ou como a equipe continua trabalhando enquanto o ambiente principal está sendo restaurado. A quarta é a comunicação: como avisar clientes e órgãos que existe uma contingência em andamento, sem gerar pânico.

Cenários reais: servidor corrompido, ransomware, falha de energia, sinistro físico

Um DRP bem feito cobre cenários distintos, porque a resposta certa muda conforme a causa. Um servidor corrompido por falha de hardware tem solução diferente de um ataque de ransomware, que pode ter contaminado os backups mais recentes. Isso, por sua vez, é diferente de uma falha de energia prolongada ou um sinistro físico no escritório, como incêndio, alagamento ou furto de equipamento. Por isso, testar apenas um cenário — geralmente o mais fácil — dá uma falsa sensação de segurança.

Como testar seu plano de recuperação antes que ele seja necessário

Ou seja, um plano de recuperação que nunca foi testado é uma suposição, não um plano. Aliás, o teste não precisa ser um simulacro completo todo mês. Pode começar por restaurar um backup isolado em um ambiente de teste e cronometrar quanto tempo o processo leva de verdade, comparando com o RTO definido. Se o tempo real for muito maior que o esperado, é sinal de que o plano existe só no papel.

Quanto custa não ter um DRP

O custo de uma parada de TI não é só a hora não trabalhada. Na verdade, é multa por atraso em obrigação fiscal, é cliente que perde confiança, é retrabalho de reconstruir informação que não foi recuperada a tempo. Comparado a esse custo, montar um DRP com manutenção preventiva de servidor e testes periódicos de restauração é um investimento pequeno. A diferença é que, sem ele, o escritório só descobre o tamanho do problema depois que ele já aconteceu.

A Microsoft documenta em detalhe a arquitetura de planos de recuperação de desastres em nuvem em seu guia de disaster recovery do Azure.