Um plano de recuperação de desastre informático não é um documento para guardar numa pasta e esquecer. É a resposta prática à pergunta que nenhum gestor quer ter de responder sob pressão: se o servidor parar, se um ransomware bloquear os ficheiros ou se o escritório ficar inacessível amanhã, quanto tempo demora a empresa a voltar a trabalhar?
Numa PME, uma falha tecnológica depressa deixa de ser um problema técnico. Pode impedir a emissão de facturas, atrasar encomendas, bloquear o acesso ao email, travar o atendimento ao cliente ou deixar colaboradores remotos sem aplicações essenciais. O custo não está apenas na reparação do equipamento. Está nas horas paradas, na confiança perdida e nas decisões apressadas que tendem a criar novos riscos.
O que deve garantir um plano de recuperação de desastre informático
Recuperar não significa apenas repor ficheiros. Um plano eficaz define como recuperar serviços, dados, acessos e comunicações dentro de um prazo aceitável para o negócio. Para isso, é preciso saber o que é prioritário.
Uma empresa pode continuar temporariamente sem a impressora da receção, mas talvez não consiga operar sem o software de facturação, o servidor de ficheiros, o email ou o acesso ao sistema de gestão. É esta diferença que deve orientar o plano. Sem prioridades claras, a equipa técnica pode recuperar primeiro o que é mais fácil, quando a empresa precisava de outra coisa para voltar a faturar.
Dois conceitos ajudam a tomar estas decisões. O RTO, ou objetivo de tempo de recuperação, define quanto tempo um serviço pode estar indisponível. O RPO, ou objetivo de ponto de recuperação, define quanta informação a empresa aceita perder. Se o RPO do sistema de facturação for quatro horas, um backup diário pode ser insuficiente. Se o RTO for de um dia, depender de encomendar um equipamento novo depois da avaria também não é uma opção realista.
Não existe um número universal. Uma empresa de serviços com equipas remotas pode precisar de restaurar acessos VPN e email em poucas horas. Uma oficina pode dar prioridade ao programa de gestão, aos dados de clientes e à ligação à Internet. O plano deve refletir a operação real, não uma lista genérica copiada da Internet.
Comece pelos cenários que podem parar a empresa
Muitas organizações pensam em desastre e imaginam um incêndio ou uma inundação. Estes riscos existem, mas as interrupções mais frequentes têm causas menos dramáticas: um disco que falha, uma atualização mal sucedida, um erro humano, uma palavra-passe comprometida ou um ataque de ransomware.
Vale a pena mapear cenários concretos. O que acontece se um colaborador abrir um anexo malicioso? E se o router fornecido pelo operador avariar? Se houver uma falha elétrica prolongada? Se o computador onde estão documentos importantes for roubado? Se a ligação principal à Internet ficar indisponível durante um dia?
Este exercício não serve para criar alarme. Serve para identificar dependências. É comum descobrir que o backup está ligado ao mesmo servidor que protege, que todos os acessos dependem de uma única conta de administrador ou que não existe uma alternativa para a ligação à Internet. Quando a falha ocorre, estas dependências tornam-se evidentes – mas demasiado tarde para as resolver sem impacto.
Dados, aplicações e pessoas
Um bom levantamento separa três dimensões. A primeira são os dados: ficheiros partilhados, bases de dados, documentos contabilísticos, emails e configurações. A segunda são as aplicações e infraestruturas: servidores físicos ou virtuais, firewall, VPN, postos de trabalho, licenças e ligações. A terceira são as pessoas: quem decide, quem comunica com os clientes, quem tem permissões para restaurar e quem contacta os fornecedores.
Não basta indicar que existe um backup. É necessário saber de que dados existe cópia, com que frequência, onde é guardada e quem consegue recuperá-la. Também é essencial registar as configurações críticas. Uma firewall empresarial pfSense, por exemplo, pode ter regras de acesso, VPN e políticas de segurança afinadas ao longo do tempo. Perder essa configuração pode atrasar muito mais a recuperação do que substituir o equipamento.
Backup não é sinónimo de recuperação
Ter cópias de segurança é indispensável, mas não garante, por si só, continuidade. Um backup que nunca foi testado é uma promessa, não uma solução.
A regra 3-2-1 continua a ser uma referência sensata: manter três cópias dos dados, em dois suportes diferentes, com uma cópia fora das instalações. Para muitas PME, isto traduz-se em dados de produção, uma cópia local para recuperação rápida e um backup na nuvem protegido, isolado do ambiente principal.
A cópia externa é decisiva em situações como roubo, incêndio, inundação ou ransomware. Se o servidor, o NAS e os discos de backup estiverem no mesmo escritório, uma única ocorrência pode afetar tudo. Também convém proteger os backups contra eliminação ou alteração indevida. Um atacante que obtenha credenciais administrativas procura frequentemente destruir as cópias antes de exigir pagamento.
O equilíbrio depende do volume de dados e do ritmo da operação. Uma cópia contínua pode ser indicada para informação muito crítica, mas implica maior custo e gestão. Para outras áreas, backups diários bem monitorizados são adequados. O erro está em escolher apenas pelo preço, sem calcular o custo de perder um dia inteiro de trabalho.
Defina uma ordem de recuperação simples
Quando há pressão, instruções vagas falham. O plano deve dizer o que fazer primeiro, quem valida cada passo e como comunicar internamente. Não precisa de ser um manual técnico com cem páginas, mas deve permitir que alguém responsável perceba a situação e ative a resposta.
Em muitas empresas, a sequência começa por conter o incidente. Perante suspeita de ransomware, desligar o equipamento ou isolá-lo da rede pode evitar a propagação. Depois, é preciso avaliar o alcance, preservar evidências quando necessário e impedir que contas comprometidas continuem a dar acesso.
A fase seguinte é recuperar os serviços essenciais num ambiente limpo e validado. Pode envolver restaurar uma máquina virtual, repor dados a partir do backup na nuvem, configurar acessos VPN para equipas remotas ou encaminhar temporariamente comunicações por outro canal. Só depois faz sentido recuperar sistemas menos críticos.
A comunicação também deve constar do plano. Quem informa os colaboradores? Que mensagem recebe um cliente se o email estiver indisponível? Quem fala com o operador de telecomunicações, o fornecedor de software ou o apoio técnico? Uma mensagem curta e correta reduz ruído e evita que cada pessoa tente resolver o problema por conta própria.
A continuidade da Internet merece um plano próprio
A ligação à Internet é muitas vezes tratada como um serviço adquirido e, por isso, dado como garantido. Mas sem Internet podem falhar o email, os pagamentos, o acesso à cloud, a VPN, o atendimento por voz e até aplicações instaladas no escritório que dependem de validações externas.
Para operações dependentes de conectividade, uma segunda ligação ou uma solução móvel de contingência pode fazer sentido. Não é necessário duplicar tudo em todos os casos. Uma pequena empresa pode precisar apenas de manter disponíveis o email, a facturação e os acessos remotos. Outra pode exigir capacidade suficiente para toda a equipa continuar a trabalhar.
A firewall deve estar preparada para esta mudança. Uma ligação alternativa que exige configurações manuais complexas no momento da falha não cumpre verdadeiramente o papel de contingência. Convém testar a passagem para o circuito secundário, confirmar que a VPN funciona e verificar quais os serviços que permanecem acessíveis.
Testar é o ponto que separa um plano útil de uma falsa segurança
O teste não tem de interromper a empresa. Pode começar por restaurar uma pasta para uma localização isolada, recuperar uma máquina virtual de teste ou simular a indisponibilidade da ligação principal. O objetivo é confirmar tempos, permissões, integridade dos dados e instruções.
Ao testar, surgem falhas valiosas: credenciais que já não funcionam, espaço insuficiente para restaurar, backups incompletos, documentação antiga ou dependências de pessoas que estão de férias. Corrigir estes problemas numa terça-feira normal custa muito menos do que descobri-los durante um incidente.
Uma revisão semestral é uma boa base para muitas PME, com revisões adicionais após mudanças relevantes: novo software de gestão, migração para a nuvem, alteração da rede, entrada de uma equipa remota ou substituição de servidores. O plano tem de acompanhar a empresa. Caso contrário, descreve uma infraestrutura que já não existe.
O que uma PME deve fazer esta semana
Comece por identificar os três a cinco serviços sem os quais a empresa não consegue operar. Para cada um, defina quanto tempo pode ficar parado e quanto dado pode perder. Depois, confirme se há backups com cópia externa e peça uma prova de restauro, não apenas um relatório a dizer que a cópia foi executada.
Em seguida, verifique quem tem acesso administrativo, onde estão guardadas as palavras-passe de emergência e se existe um contacto técnico que conheça a rede. Reveja também a dependência do router do operador e a possibilidade de manter conectividade quando a ligação principal falha.
A IMPULSYS trabalha este planeamento a partir da realidade de cada negócio: serviços críticos, orçamento disponível, acessos remotos, proteção de dados e capacidade de recuperação. Não se trata de instalar tecnologia a mais. Trata-se de garantir que a tecnologia existente não deixa a empresa sem resposta no dia em que mais precisa dela.
A pergunta certa não é se a sua empresa pode sofrer uma falha. É se, quando ela acontecer, vai recuperar com método ou começar por procurar, sob pressão, onde ficou o último backup.
No responses yet