Esperar pelo desastre não é estratégia

Ainda existe quem acredite que, em caso de problema, “depois logo se vê”. No entanto, quando praticamente todos os processos dependem de sistemas digitais, aplicações, acessos remotos, ERP, plataformas cloud ou sistemas de faturação, parar significa perder produtividade, faturação e, muitas vezes, confiança dos clientes.

O cenário mudou também na natureza da ameaça. Já não falamos apenas de falhas de hardware ou cortes de energia. Por exemplo, Falamos, também, de ataques de ransomware que, em horas, podem cifrar todo o ambiente produtivo, incluindo os próprios backups se estes não estiverem corretamente isolados.

Além disso, continua a existir alguma confusão entre backup, DR e business continuity. Ter backups não significa garantir continuidade de operação. O DR define como e em quanto tempo os sistemas voltam a funcionar, enquanto a business continuity assegura que o negócio continua operacional mesmo perante um incidente grave.

Este enquadramento obriga as organizações a responder a duas perguntas essenciais, que, em termos técnicos, se chamam RTO (Recovery Time Objective) e RPO (Recovery Point Objective): quanto tempo podem estar paradas e quanta informação podem perder? E, naturalmente, quais são os sistemas verdadeiramente críticos.

Com a entrada em vigor da diretiva NIS2, este tema ganhou ainda mais relevância. O DR deixou de ser apenas uma boa prática tecnológica para passar também a ser uma questão de compliance e gestão de risco. Já não basta assumir que “as equipas resolvem”. É necessário existir estratégia, documentação, responsabilidades definidas e testes regulares.

A maturidade da cloud e das infraestruturas híbridas alterou esta equação. Hoje é possível replicar ambientes inteiros para um site secundário, sem duplicar toda a infraestrutura física, algo que, há cinco anos, só estava ao alcance de grandes empresas. Em muitos casos, tornou-se mais eficiente proteger globalmente a infraestrutura do que tentar definir manualmente o que é ou não crítico. Contudo, é importante não confundir disponibilidade tecnológica com simplicidade: uma boa estratégia de DR em cloud continua a exigir decisões cuidadas sobre custos, dependências e jurisdição dos dados.

A cloud permite ainda às empresas terem capacidade de recuperação sem necessidade de duplicar toda a infraestrutura física. Isto torna o DR mais acessível, mais flexível e mais ajustado à realidade de cada organização, independentemente da sua dimensão.

Mas existe um ponto frequentemente negligenciado: os testes. Não há nada pior do que investir numa solução de  DR e descobrir, no momento crítico, que ela não funciona como esperado. Testar regularmente permite validar processos, identificar dependências esquecidas e garantir confiança quando realmente for necessário ativar o plano.

No fim, a conversa sobre disaster recovery não é apenas tecnológica. É uma conversa sobre negócio. Porque os mercados não esperam, porque os clientes não esperam e porque os prejuízos de uma paragem podem ser muito superiores ao investimento necessário para prevenir o problema.

A pergunta certa não é "quanto custa ter disaster recovery". É "quanto custa não o ter no dia em que precisarmos". E quem responde a essa segunda pergunta com honestidade percebe rapidamente onde está o verdadeiro investimento.

Esperar pelo desastre não é estratégia. É apenas adiar um risco que, mais cedo ou mais tarde, acaba por chegar.