Pergunte a qualquer gestor se a empresa tem backup e a resposta será sim. Agora mude a pergunta: “se o servidor principal queimar hoje às 9h, a que horas a empresa volta a operar — e quanto trabalho se perde?” O silêncio que costuma seguir essa pergunta é o tamanho do risco.
Backup é uma cópia de dados. Continuidade de negócio é a capacidade de continuar operando. São coisas muito diferentes.
As duas métricas que definem tudo
Todo plano de continuidade se resume a duas siglas:
- RPO (Recovery Point Objective): quanto de dados você aceita perder. Se o backup roda à meia-noite e o desastre acontece às 18h, perderam-se 18 horas de trabalho. Esse é seu RPO real — ele está aceitável?
- RTO (Recovery Time Objective): em quanto tempo a operação precisa voltar. Restaurar terabytes de um backup em nuvem pode levar dias. Sua empresa aguenta dias parada?
A maioria das empresas nunca definiu esses números formalmente — e descobre os valores reais da pior forma possível.
Onde os planos falham na prática
- Backup que nunca foi restaurado: a cópia existe, mas ninguém jamais testou uma restauração completa. No dia do desastre, descobre-se que estava corrompida ou incompleta
- Backup no mesmo lugar que o original: um ransomware (ou um incêndio) leva os dois de uma vez
- Só os dados, não o ambiente: restaurar arquivos é fácil; reconstruir servidores, sistemas, integrações e permissões leva semanas se não houver documentação
- Dependência de uma pessoa: o plano inteiro mora na cabeça de um analista — que pode estar de férias
- Nuvem como sinônimo de garantia: estar no Microsoft 365 ou Google Workspace não cobre exclusão acidental, contas comprometidas ou retenção além do padrão
Plano de continuidade que nunca foi testado não é plano — é hipótese.
O que um plano de continuidade contém
- Inventário e criticidade: quais sistemas existem e quais param a empresa se caírem
- RPO e RTO definidos por sistema, validados com o negócio — não com a TI
- Estratégia 3-2-1 de backup: três cópias, duas mídias diferentes, uma imutável e fora do ambiente
- Documentação de reconstrução: passo a passo para reerguer cada sistema crítico
- Responsáveis e cadeia de decisão: quem declara o desastre, quem comunica, quem executa
- Testes periódicos: restauração completa simulada ao menos uma vez por ano — com cronômetro
O papel da Scurra
Na gestão e sustentação de TI da Scurra, continuidade é entregável, não promessa: definimos RPO/RTO com o negócio, implantamos a estratégia de backup imutável, documentamos a reconstrução e testamos a restauração periodicamente. Porque no dia em que tudo der errado, o que vale é o que foi ensaiado.
