Uma fábrica têxtil do Vale do Ave com 120 colaboradores perdeu 14 horas de produção porque o servidor de backups estava desligado há três meses — ninguém tinha testado se o plano de recuperação funcionava de verdade. O problema não é raro: em 2024, o CERT.PT registou 2.758 incidentes de cibersegurança em Portugal, um aumento de 36% face a 2023, e cerca de 78% ocorreram em entidades privadas. Disaster recovery não é um documento que se guarda numa pasta. É um conjunto de procedimentos que só valem se forem ensaiados antes da crise. Este guia oferece um checklist de 16 controlos práticos para auditar o seu plano de recuperação em 4 horas, identificar falhas e documentar o que testar cada trimestre.
O que precisa antes de começar
Antes de auditar o plano, confirme que tem estes cinco elementos no lugar: inventário completo de sistemas críticos (ERP, WMS, POS, BI, email, ficheiros partilhados, máquinas IoT ligadas à rede); documentação de dependências — qual é o sistema que, se cair, paralisa a operação em menos de 2 horas; contactos de emergência atualizados (fornecedor de infraestrutura, gestor de backups, responsável de TI, diretor operacional, diretor financeiro); definição de RTO (tempo máximo de inatividade tolerado) e RPO (quantidade máxima de dados que pode perder) para cada sistema; acesso a um ambiente de teste isolado onde possa simular uma recuperação sem afetar a produção.
Passo 1: Auditar a infraestrutura de backups
Comece aqui. Sem backups válidos, não há recuperação possível. Verifique se os backups estão a ser executados todos os dias. Aceda ao histórico de logs da ferramenta de backup — procure falhas silenciosas: tarefas marcadas como "sucesso" mas com 0 bytes copiados. Isto acontece frequentemente quando a unidade de armazenamento está cheia ou desligada, e o software não gera alerta porque o agendador não falhou tecnicamente — apenas não copiou nada.
Confirme que existe pelo menos uma cópia offline (disco externo, fita, ou nuvem desligada do sistema principal). Uma cópia online apenas protege contra falhas de software, não contra ransomware ou sabotagem. Se um atacante conseguir acesso ao seu datacenter, pode eliminar todos os backups online em minutos — uma cópia física num cofre ou numa nuvem com retenção imutável é a única defesa.
Teste o acesso aos backups: consegue restaurar um ficheiro de 30 dias atrás? Consegue listar o conteúdo de um backup de 6 meses atrás sem restaurar tudo? Valide a integridade — a ferramenta de backup faz verificação de checksum ou CRC? Se não, um backup pode estar corrompido e só descobrir quando precisar dele. Finalmente, documente o tempo de restauração: quanto tempo demora a restaurar uma base de dados de 50 GB? E uma máquina virtual inteira? Escreva os números — não estime.
Um backup que nunca foi restaurado é apenas um ficheiro que ocupa espaço em disco.
Passo 2: Validar o RTO e RPO de cada sistema crítico
RTO e RPO definem o que pode falhar e por quanto tempo. Se não os tiver definidos, o plano de recuperação é especulação. Preencha esta tabela com os seus sistemas — se não conseguir definir um RTO realista, significa que o sistema é mais crítico do que pensava e deve considerar redundância ativa.
| Sistema | RTO (tempo máximo inativo) | RPO (dados máximos a perder) | Estratégia de recuperação | Testado em (data) |
|---|---|---|---|---|
| ERP (MULTI, QAD) | 4 horas | 1 hora | Restauro de backup + replicação de BD | — |
| WMS / KORA Inventory | 2 horas | 30 minutos | Failover para servidor secundário | — |
| POS / MAXIRETAIL | 1 hora | 15 minutos | Modo offline local + sincronização posterior | — |
| Email corporativo | 8 horas | 4 horas | Restauro de backup de email | — |
| Ficheiros partilhados | 6 horas | 1 hora | Restauro de snapshot ou backup incremental | — |
Passo 3: Testar a restauração de dados em ambiente isolado
Isto é o coração do teste. Não o salte. Escolha um backup de 2-3 semanas atrás e restaure-o num servidor de teste — nunca na produção. Documente o tempo exato de início e fim. Valide a integridade dos dados: a base de dados restaurada passa nos testes de consistência (DBCC CHECKDB no SQL Server, CHECK TABLE no MySQL)? Os índices estão intactos?
Teste a aplicação sobre os dados restaurados. Consegue fazer login? Consegue consultar um pedido de venda de há 2 meses? Consegue gerar uma fatura? Simule uma falha de disco: retire o disco de backup (ou simule uma queda de rede) e tente restaurar. Quanto tempo demora a detetar a falha? Quanto tempo demora a mudar para o backup secundário? Registe tudo — hora de início, hora de fim, erros encontrados, tempo de cada fase (cópia de ficheiros, inicialização de BD, validação de dados, testes de aplicação). Este registo é a sua prova de que o procedimento funciona.
Passo 4: Auditar a documentação de procedimentos
Procedimentos escritos só valem se forem claros o suficiente para um técnico novo os seguir sem ajuda. Abra o seu manual de recuperação de desastres. Consegue um técnico novo restaurar o ERP em 3 horas seguindo apenas o documento? Teste: peça a alguém que não trabalha em TI que leia o procedimento e diga se consegue seguir. Verifique se o procedimento inclui pré-requisitos (software, credenciais, acesso), passos numerados e sequenciais, comandos exatos (não "execute o script de restauro" — indique o caminho completo do ficheiro), tempo estimado para cada fase, contactos de suporte se algo falhar.
Confirme que o procedimento está atualizado. Se o seu ERP foi atualizado há 6 meses, o procedimento de recuperação também foi revisto? Se não, é obsoleto. Documente as dependências: "Antes de restaurar o ERP, certifique-se de que a base de dados SQL foi restaurada e está acessível em [IP/hostname]". Um erro comum é deixar o procedimento nas mãos de um único técnico — se esse técnico sair da empresa ou ficar doente no dia da crise, ninguém consegue recuperar nada.
Passo 5: Testar o failover de rede e comunicações
Uma recuperação de dados é inútil se a equipa não conseguir comunicar ou aceder aos sistemas. Simule uma queda de internet: desligue o router principal e confirme que o acesso à rede interna ainda funciona. Conseguem os utilizadores aceder ao ERP via VPN de emergência? Teste a comunicação de emergência — conseguem os colaboradores receber uma mensagem de SMS ou WhatsApp se o email cair? Tem um plano de comunicação escrito (quem avisa quem, em que ordem)?
Valide o acesso remoto: se a fábrica ficar sem acesso físico (incêndio, inundação), consegue o gestor de TI aceder aos servidores remotamente? Tem credenciais de acesso de emergência (não dependentes do AD que pode estar offline)? Teste a conectividade com fornecedores críticos — se o seu ERP integra com o sistema de um cliente ou fornecedor via API ou EDI, consegue a integração recuperar automaticamente após uma queda?
Passo 6: Simular um cenário de crise completo (teste anual obrigatório)
Uma vez por ano, faça um teste de ponta a ponta. Reserve um sábado ou domingo. Simule uma falha real: o servidor principal de produção falhou completamente. Objetivo: recuperar o ERP, WMS e email em menos de 6 horas. Tempo de início: 09:00. Hora-limite: 15:00.
Reúna a equipa (TI, operações, financeira). Cada um tem um papel definido no procedimento de recuperação. Ninguém improvisa. Documente cada decisão: "Às 09:15 decidimos restaurar a partir do backup de ontem porque o backup de hoje estava corrompido. Impacto: perdemos 8 horas de dados de vendas." Após o teste, reúna a equipa e identifique o que falhou: procedimentos incompletos, contactos desatualizados, software de recuperação que não funcionou, falta de credenciais, dependências não documentadas. Atualize o plano com as lições aprendidas. Marque a data do próximo teste no calendário.
Passo 7: Conformidade regulatória e auditoria
A NIS2 obriga as médias e grandes empresas de setores críticos (incluindo indústria) a ter um plano de continuidade de negócio testado. O Decreto-Lei n.º 65/2025, que transpõe a Diretiva (UE) 2022/2555, exige evidência de teste — isto não é opcional. Confirme que o seu plano de recuperação está documentado e que foi testado pelo menos uma vez nos últimos 12 meses.
Se tem certificação ISO 27001, o seu auditor vai pedir: "Quando foi o último teste de recuperação de desastres? Qual foi o resultado?" Se não tem registo, falha a auditoria. Documente quem aprovou o plano: CEO, CFO, diretor de operações. Assinaturas digitais via Chave Móvel Digital ou assinatura qualificada contam para conformidade. Mantenha um registo de testes: data, cenário, duração, falhas encontradas, ações corretivas, quem testou. Este registo é a sua prova de diligência perante um auditor ou uma autoridade regulatória.
Checklist de 16 controlos — use isto na reunião de amanhã
| Controlo | Sim | Não | Parcial | Ação corretiva |
|---|---|---|---|---|
| Backups executados diariamente (verificado em logs) | ☐ | ☐ | ☐ | |
| Existe cópia offline (disco, fita ou nuvem desligada) | ☐ | ☐ | ☐ | |
| Backup foi restaurado com sucesso nos últimos 3 meses | ☐ | ☐ | ☐ | |
| RTO e RPO definidos para cada sistema crítico | ☐ | ☐ | ☐ | |
| Procedimento de recuperação documentado e atualizado | ☐ | ☐ | ☐ | |
| Contactos de emergência atualizados (TI, fornecedor, direção) | ☐ | ☐ | ☐ | |
| Credenciais de acesso de emergência guardadas de forma segura (cofre, não email) | ☐ | ☐ | ☐ | |
| Teste de restauração de dados em ambiente isolado realizado | ☐ | ☐ | ☐ | |
| Tempo de restauração medido e documentado | ☐ | ☐ | ☐ | |
| Integridade de backups validada (checksum, verificação de BD) | ☐ | ☐ | ☐ | |
| Teste de failover de rede realizado | ☐ | ☐ | ☐ | |
| Acesso remoto de emergência testado (VPN, credenciais) | ☐ | ☐ | ☐ | |
| Plano de comunicação de crise documentado | ☐ | ☐ | ☐ | |
| Teste completo de recuperação realizado nos últimos 12 meses | ☐ | ☐ | ☐ | |
| Plano aprovado por CEO, CFO e diretor de operações (assinado) | ☐ | ☐ | ☐ | |
| Registo de testes mantido e acessível a auditores | ☐ | ☐ | ☐ |
Preencha esta tabela numa reunião com TI, operações e direção. Se mais de três controlos estão marcados como "Não" ou "Parcial", o seu plano de recuperação não está pronto — reserve dois sprints de 2 semanas para corrigir o essencial. Comece pelos controlos de backup (linhas 1-3), depois pelos testes (linhas 8-9), depois pela documentação (linhas 5-6). O resto segue.
Perguntas frequentes
O que é disaster recovery e por que é importante testar?
Disaster recovery é um conjunto de procedimentos para recuperar sistemas e dados após uma falha crítica. Não é um documento guardado numa pasta — só funciona se for testado regularmente. O artigo exemplifica com uma fábrica têxtil que perdeu 14 horas de produção porque o servidor de backups estava desligado há três meses e ninguém tinha validado o plano.
Quais são os cinco elementos essenciais antes de auditar o plano?
Inventário completo de sistemas críticos (ERP, WMS, POS, BI, email, ficheiros partilhados); documentação de dependências entre sistemas; contactos de emergência atualizados (fornecedor de infraestrutura, gestor de backups, responsável de TI, diretores operacional e financeiro); definição de RTO e RPO para cada sistema; e acesso a um ambiente de teste isolado para simular recuperações sem afetar a produção.
O que significa RTO e RPO e como defini-los?
RTO é o tempo máximo de inatividade tolerado; RPO é a quantidade máxima de dados que pode perder. O artigo recomenda preencher uma tabela com cada sistema crítico. Por exemplo, um ERP pode ter RTO de 4 horas e RPO de 1 hora. Se não conseguir definir um RTO realista, significa que o sistema é mais crítico e deve considerar redundância ativa.
Por que é importante ter uma cópia de backup offline?
Uma cópia online apenas protege contra falhas de software. Se um atacante conseguir acesso ao datacenter, pode eliminar todos os backups online em minutos. Uma cópia física num cofre ou numa nuvem com retenção imutável é a única defesa contra ransomware ou sabotagem.
Como testar se um backup realmente funciona?
Escolha um backup de 2-3 semanas atrás e restaure-o num servidor de teste isolado. Documente o tempo exato de início e fim. Valide a integridade dos dados (testes de consistência da base de dados), teste a aplicação (login, consultas, geração de documentos) e registe todos os erros encontrados e o tempo de cada fase.
Qual é o erro mais comum nos procedimentos de recuperação?
Deixar o procedimento nas mãos de um único técnico. Se esse técnico sair da empresa ou ficar doente no dia da crise, ninguém consegue recuperar nada. Os procedimentos devem ser claros o suficiente para um técnico novo os seguir sem ajuda, com passos numerados, comandos exatos e contactos de suporte.
Quanto tempo deve levar uma auditoria completa ao plano de disaster recovery?
O artigo oferece um checklist de 16 controlos práticos que pode completar em 4 horas. Este tempo permite identificar falhas e documentar o que testar cada trimestre, sem necessidade de intervenção prolongada na operação.
Fontes
- CERT.PT — Relatório de Incidentes de Cibersegurança em Portugal 2024 (Instituto Nacional de Cibersegurança)
- Norma ISO/IEC 27031:2021 — Guidelines for information and communication technology readiness for business continuity
- Diretiva (UE) 2022/2555 (NIS2) — Network and Information Security Directive, requisitos de continuidade operacional para entidades críticas
- ENISA — Guidelines on Disaster Recovery and Business Continuity (European Union Agency for Cybersecurity)
- Banco de Portugal — Recomendações sobre Planos de Continuidade de Negócio para Instituições Financeiras (Circular 4/2020)