Backup em cloud vs. on-premise: continuidade do negocio

O servidor caiu às 7h43 de uma segunda-feira. O ERP não arranca. A linha de produção parou. O chefe de turno está à espera. Quanto tempo aguenta a sua empresa assim — e sabe, com precisão de minutos, quanto tempo demora a restaurar tudo numa máquina limpa?

Este artigo defende uma tese incómoda: a maioria das PME industriais portuguesas não tem um problema de backup. Tem um problema de recuperação. E a escolha entre cloud e on-premise é secundária enquanto o processo de restauro nunca tiver sido ensaiado.

A distinção que ninguém faz — e que decide tudo

Fazem-se cópias. Às vezes. Mas o ficheiro de backup do mês passado pode estar corrompido. O ERP pode precisar de uma sequência específica de restauro que só o fornecedor conhece. A base de dados pode ter dependências que o snapshot não captura. Nenhum destes problemas aparece enquanto não há incidente — e todos aparecem ao mesmo tempo quando há.

O Verizon Data Breach Investigations Report de 2025 documenta que o ransomware esteve presente em 88% das violações de dados em PME, contra 39% nas grandes organizações. As PME são o alvo desproporcionado precisamente porque têm backups menos testados e tempos de recuperação mais longos. A arquitetura de armazenamento importa menos do que saber, com precisão de minutos, quanto tempo demora a voltar a operar.

Dito isto: a arquitetura importa. Vamos a ela — com critérios concretos, uma matriz de decisão e um checklist de auditoria prontos a usar.

O que precisa de ter definido antes de escolher qualquer arquitetura

Sem este inventário, qualquer decisão técnica é arbitrária. Para cada sistema crítico — ERP, MES, ficheiros de faturação, base de dados de clientes, dados de produção em curso — defina dois números:

RTO (Recovery Time Objective): quanto tempo de paragem é aceitável. Para o ERP de uma fábrica de confeção com 120 colaboradores, quatro horas de paragem numa segunda-feira de fim de mês têm um custo operacional muito diferente de quatro horas numa sexta à tarde. O RTO tem de ser aprovado pela gestão, não apenas estimado pelo IT.

RPO (Recovery Point Objective): quantas horas de dados pode perder sem dano grave. Se a última encomenda confirmada antes do incidente não for recuperável, qual é o impacto? Responder a esta pergunta obriga o CEO e o CFO a sentar à mesa com o responsável de IT — e é aí que os números reais aparecem.

A estes dois acrescente: mapa de dependências do sistema (o ERP depende do servidor de base de dados, que depende do storage, que depende da UPS), localização física e digital das licenças e chaves de ativação — guardadas fora do servidor principal —, largura de banda disponível medida em hora de pico de produção, e orçamento de TCO a três anos, não apenas o custo de aquisição inicial.

Passo 1 — Classifique os dados por criticidade real, não por intuição

Uma fábrica de confeção do Vale do Ave com 120 colaboradores tem três categorias distintas de dados. Tratá-las com a mesma política de backup é o erro mais comum que vemos em projetos de infraestrutura industrial.

Os dados críticos — base de dados do ERP, ficheiros de faturação, dados de produção em curso — exigem RTO inferior a quatro horas e replicação contínua com RPO de minutos. Os dados importantes — histórico de encomendas, fichas técnicas, dados de RH — toleram RTO até 24 horas. Os dados de arquivo — documentação de projetos encerrados, backups históricos de conformidade fiscal — podem viver em tape ou cold storage cloud a custo mínimo, com RTO superior a 72 horas.

A classificação tem de ser revista anualmente e validada pela gestão. Vemos regularmente situações em que o IT classifica um sistema como "importante" e o CEO, quando confrontado com o custo real de 24 horas de paragem, reclassifica-o imediatamente como "crítico". Essa conversa tem de acontecer antes do incidente.

Passo 2 — Avalie a rede com honestidade aritmética

Backup em cloud pressupõe conectividade. Uma empresa com ligação de 100 Mbps partilhada entre escritório e chão de fábrica vai sentir a replicação contínua. O cálculo é direto: 500 GB de dados novos por dia exigem, em transferência contínua de oito horas, cerca de 139 Mbps dedicados. Se a linha não aguenta isso sem degradar o ERP, a cloud pura não é viável sem upgrades de rede.

A cloud híbrida resolve este problema. O backup primário fica on-premise — rápido, sem consumo de banda —, e a replicação para cloud acontece fora das horas de pico. É a arquitetura que mais vemos funcionar em unidades industriais portuguesas com 50 a 300 colaboradores. Verifique também se tem SLA de uptime garantido pelo ISP (mínimo 99,5%) e se existe ligação de failover por 4G ou 5G para quando a fibra cair.

Passo 3 — Compare as arquiteturas com critérios reais

Uma nota sobre o custo de egress que quase nenhum contrato destaca na proposta inicial: transferir grandes volumes de dados de volta da cloud para restauro tem custo por GB na maioria dos fornecedores. Calcule este custo no cenário de pior caso — restauro completo da base de dados do ERP — antes de assinar. Em projetos de infraestrutura que acompanhámos, este custo surpresa chegou a triplicar o custo mensal previsto no mês de um incidente grave.

Passo 4 — Implemente a regra 3-2-1-1

A regra clássica era 3-2-1: três cópias, em dois suportes diferentes, uma fora do local. Com ransomware a cifrar backups ligados à rede, a versão atual é 3-2-1-1 — acrescenta uma cópia imutável, que não pode ser alterada nem apagada durante um período definido, tipicamente 30 a 90 dias. A maioria dos fornecedores cloud oferece object lock ou WORM storage para este efeito.

Na prática, para uma empresa industrial portuguesa com ERP MULTI ou outro ERP vertical, as quatro cópias ficam assim distribuídas: snapshot local em NAS dedicado, fora do domínio de produção; replicação para segundo site ou appliance de backup com deduplicação; replicação cloud com retenção de 30 dias e object lock ativo; e a cópia imutável em conta separada, não acessível pelas credenciais de administrador do dia-a-dia.

O período de retenção tem de cobrir o tempo médio de deteção de ransomware, que ronda os 20 a 30 dias. Um backup de 15 dias não chega se o malware entrou há três semanas e só agora cifrou os ficheiros.

Passo 5 — Teste o restauro. Agora. Não amanhã.

Um backup que nunca foi testado não é um backup. É uma esperança guardada em disco.

O teste não é verificar que o ficheiro existe. O teste é restaurar numa máquina isolada e confirmar que o ERP arranca, que a base de dados está consistente, e que o tempo de restauro real cabe no RTO definido. Há um detalhe operacional que os manuais raramente referem: muitos ERPs verticais para indústria têxtil ou calçado têm dependências de licença ligadas ao hostname ou ao MAC address do servidor. Um restauro numa máquina diferente pode falhar na ativação mesmo com todos os ficheiros intactos. Confirme este ponto com o fornecedor do ERP antes do incidente — não durante.

Defina um calendário: mensal para sistemas críticos, trimestral para os restantes. Documente cada teste com data, sistema, volume restaurado, tempo decorrido e anomalias encontradas. Este registo é também evidência de conformidade para auditorias RGPD e, se a sua empresa estiver abrangida pela Diretiva NIS2 transposta em Portugal pelo Decreto-Lei n.º 65/2025, para as obrigações de gestão de risco e continuidade de serviço.

Passo 6 — Documente o plano em linguagem operacional

O plano de continuidade não pode ter 40 páginas que ninguém lê. Precisa de uma folha A4 plastificada na sala de servidores e outra no telemóvel do responsável de IT. Com três secções: o que aconteceu (lista de cenários — ransomware, falha de hardware, incêndio, falha de ISP — com o primeiro passo para cada um); quem faz o quê (nomes, telemóveis, responsabilidades sem ambiguidade); onde estão os acessos (localização física e digital das credenciais de recuperação, chaves de licença, contactos de suporte do fornecedor de ERP).

Vemos regularmente em projetos de infraestrutura que o plano existe em PowerPoint no computador do IT manager — que está de férias quando o servidor cai. A documentação tem de ser acessível a quem está presente, não a quem a escreveu. Isto parece óbvio. Não é: em mais de metade dos projetos de recuperação que acompanhámos após incidente, o acesso às credenciais de restauro estava bloqueado por dependência de uma única pessoa.

Erros que se repetem — e como cortar o padrão

Backup no mesmo servidor que os dados de produção. Um ataque de ransomware cifra tudo na mesma rede. Separe fisicamente ou use air gap cloud com object lock. Não há meio-termo aqui.

RTO definido pelo IT sem validação da gestão. O IT diz "restauramos em quatro horas". O CEO não sabe que quatro horas de paragem numa segunda-feira de fim de mês têm um custo concreto em produção parada, encomendas atrasadas e penalizações contratuais. Alinhe os números e o custo antes do incidente — não depois.

Contratos cloud sem cláusula de localização de dados. O RGPD exige que os dados de cidadãos europeus sejam processados em servidores com garantias adequadas. Exija contrato de Data Processing Agreement e confirme que a região de armazenamento é a UE. Alguns fornecedores cloud colocam backups em regiões fora da UE por defeito, para reduzir latência ou custo. Verifique.

Ignorar a prevenção e focar apenas na recuperação. Backup é recuperação. Prevenção reduz a frequência com que precisa de recuperar. Consulte proteção perimetral e SOC para perceber como as duas camadas se complementam — e por que razão uma firewall mal configurada invalida a melhor política de backup do mundo.

O contexto regulatório que não pode ignorar

A Diretiva NIS2 (Diretiva (UE) 2022/2555), transposta em Portugal pelo Decreto-Lei n.º 65/2025, obriga médias e grandes empresas de setores críticos — incluindo indústria transformadora — a implementar medidas de gestão de risco que incluem explicitamente políticas de backup e continuidade de negócio. O incumprimento pode resultar em coimas até 10 milhões de euros ou 2% do volume de negócios global.

O CNCS registou 2.758 incidentes de cibersegurança em Portugal em 2024, um aumento de 36% face a 2023, com cerca de 78% a ocorrer em entidades privadas (fonte: CNCS, Relatório Cibersegurança em Portugal, 2024). Para uma PME industrial do Norte do país, isto não é estatística abstrata — é o contexto em que o próximo incidente vai acontecer. A questão não é se, é quando.

Para perceber o que a NIS2 implica na prática fabril, consulte NIS2 na prática: controlos técnicos para a fábrica nos primeiros 90 dias. E se a sua empresa opera com gestão de armazéns ou captura de produção em tempo real, os dados gerados por estes sistemas têm de estar cobertos pela mesma política de backup — não apenas o ERP central.

Matriz de decisão rápida

A pergunta que fica: se o servidor caísse agora, quem na sua empresa saberia exatamente o que fazer nos primeiros 15 minutos — e teria acesso a tudo o que precisa para o fazer?

Perguntas frequentes

Qual é a diferença entre RTO e RPO e por que importam ambos?

RTO (Recovery Time Objective) é o tempo máximo aceitável de paragem. RPO (Recovery Point Objective) é a quantidade máxima de dados que pode perder. Um ERP pode ter RTO de 4 horas (paragem aceitável) mas RPO de 15 minutos (não pode perder mais de 15 min de encomendas). Defini-los com precisão evita decisões técnicas erradas e custos desnecessários.

Por que o backup on-premise falha contra ransomware?

Se o backup está na mesma rede que o servidor principal, o ransomware acede a ambos simultaneamente. Quando descobre o incidente, o ficheiro de backup já está encriptado. A solução é air gap (desconexão física) ou cloud com retenção imutável. Sem isto, tem cópias que não consegue usar quando precisa.

Cloud pura é viável numa fábrica com 100 Mbps partilhada?

Não. Uma replicação contínua de 500 GB diários exige ~139 Mbps dedicados. Se a linha é partilhada com o ERP, degrada-se. A solução é cloud híbrida: backup local rápido (on-premise) e replicação para cloud fora de pico. É a arquitetura que funciona melhor em PME industriais portuguesas.

Qual é o custo real de 24 horas de paragem do ERP?

Depende da atividade. Uma fábrica de confeção com 120 colaboradores perde cerca de 2.400 horas de trabalho direto, mais impacto em encomendas atrasadas e multas contratuais. O CEO e CFO devem quantificar isto antes de escolher arquitetura. Essa conversa define se o sistema é "importante" ou "crítico" — e muda tudo.

Como saber se o backup está realmente funcional?

Só testando restauro completo numa máquina limpa, sem acesso aos dados originais. A maioria das PME nunca faz isto. Recomenda-se teste anual de cada sistema crítico, com cronómetro, para validar RTO real. Se o teste falha, o backup não existe — tem apenas ficheiros que não consegue usar.

Tape ou cloud para arquivo de conformidade fiscal?

Tape é mais barato a longo prazo se o acesso é raro (conformidade fiscal exige 10 anos). Cloud cold storage é mais prático se precisa acesso ocasional. O critério é: se nunca vai restaurar em menos de 72 horas, tape amortiza-se. Se pode precisar em dias, cloud é mais seguro e rastreável.

Preciso de contrato DPA para backup em cloud dentro da UE?

Sim. Mesmo que o fornecedor seja europeu, o contrato de processamento de dados (DPA) é obrigatório por RGPD. Verifique se está explícito que os dados residem em data centers UE e que o fornecedor não os transfere para fora. Sem isto, está em risco de multa regulatória independentemente da segurança técnica.

Qual é o erro mais comum na escolha entre cloud e on-premise?

Escolher a arquitetura antes de definir RTO, RPO e mapa de dependências. Isto leva a investimentos em hardware desnecessário ou contratos cloud que não resolvem o problema real. A arquitetura é secundária. O que decide tudo é saber, com precisão de minutos, quanto tempo demora a voltar a operar.

Fontes

• Verizon Data Breach Investigations Report 2025 — Relatório anual de investigações de violações de dados, publicado pela Verizon Communications Inc.
• Regulamento (UE) 2016/679 (RGPD) — Regulamento Geral sobre a Proteção de Dados, aplicável a processamento de dados pessoais em contexto de backup e conformidade
• Diretiva (UE) 2022/2555 (NIS2) — Diretiva relativa às medidas para um elevado nível comum de cibersegurança, incluindo requisitos de continuidade operacional e backup
• Norma ISO/IEC 27001:2022 — Norma internacional de gestão da segurança da informação, incluindo requisitos de backup, recuperação de dados e planeamento de continuidade
• ENISA Guidelines on Backup and Recovery — Orientações da Agência da União Europeia para a Cibersegurança em matéria de backup, recuperação de dados e RTO/RPO