Backup local ou cloud: qual protege melhor?

Uma falha de armazenamento às 10h00, uma conta administrativa comprometida ou um ataque de ransomware não são problemas teóricos. São interrupções que podem parar faturação, produção, atendimento e acesso a aplicações críticas. A decisão entre cópia de segurança local ou na nuvem deve, por isso, começar pela recuperação do negócio, não pelo preço por terabyte.

A pergunta certa não é onde guardar uma cópia. É esta: quanto tempo pode cada serviço estar indisponível e quanta informação pode a empresa perder sem impacto operacional, financeiro ou legal? As respostas definem RTO, RPO, arquitetura, custos e responsabilidades.

Cópia de segurança local ou na nuvem não é uma escolha binária

A cópia de segurança local continua a ser relevante porque oferece velocidade. Uma cópia armazenada num repositório dedicado no centro de dados ou nas instalações da empresa pode permitir recuperações rápidas de máquinas virtuais, ficheiros, bases de dados e serviços críticos. Quando o objetivo é restaurar um servidor em minutos ou disponibilizar dados para uma recuperação operacional imediata, a proximidade física conta.

Mas uma cópia local, isolada, não protege contra todos os cenários. Incêndio, inundação, furto, falha elétrica grave, erro humano com privilégios elevados ou ransomware que alcança o repositório podem comprometer produção e a cópia de segurança no mesmo evento. Ter duas cópias no mesmo edifício não é uma estratégia de continuidade de negócio.

A nuvem resolve principalmente o risco geográfico e acrescenta capacidade de retenção sem exigir crescimento permanente de infraestrutura local. Porém, não transforma automaticamente uma política de cópia de segurança numa política de recuperação. A largura de banda disponível, o volume de dados, os custos de saída, a configuração da imutabilidade e os procedimentos de restauro determinam se essa cópia será efetivamente utilizável quando for necessária.

Para a maioria das empresas portuguesas de média dimensão, a resposta mais segura é híbrida: recuperação rápida local para serviços prioritários e uma cópia externa, protegida e imutável, para sobreviver a incidentes graves.

Quando a cópia de segurança local faz sentido

A cópia de segurança local é indicada quando existem cargas com RTO exigente. Um ERP, um servidor de ficheiros intensamente utilizado, uma base de dados transacional ou máquinas virtuais que suportam operações diárias não podem ficar dependentes de descarregamentos demorados a partir da nuvem.

Um repositório local corretamente dimensionado permite restaurar grandes volumes com previsibilidade. Também reduz a dependência da ligação à Internet durante uma indisponibilidade. Isto é particularmente relevante em organizações com sucursais, fábricas, sistemas de videovigilância, ambientes de engenharia ou grandes volumes de dados não estruturados.

Há, contudo, condições técnicas que não podem ser ignoradas. O repositório não deve partilhar as mesmas credenciais administrativas da produção, nem estar permanentemente exposto à rede sem segmentação. Deve existir controlo de acesso, encriptação, monitorização de capacidade, alertas de falha e retenção definida por política. Se o atacante comprometer o domínio e conseguir apagar as cópias de segurança, a recuperação deixa de ser uma opção.

Também é necessário avaliar o custo total de propriedade. Equipamento, discos, energia, manutenção, renovação tecnológica e operação têm de entrar na conta. Comprar capacidade sem monitorização nem testes não cria resiliência. Cria apenas mais um ativo para gerir.

Quando a cópia de segurança na nuvem é a melhor resposta

A cópia de segurança na nuvem é especialmente útil para garantir uma cópia fora do local, ampliar retenções e proteger ambientes distribuídos. Para empresas sem um segundo centro de dados, é muitas vezes a forma mais pragmática de cumprir o princípio de separação geográfica.

É uma escolha forte para retenção de longo prazo, proteção de Microsoft 365 e outras aplicações SaaS, cópias de filiais com pouca infraestrutura e cenários em que a empresa pretende evitar investimento inicial elevado em capacidade secundária. A elasticidade é uma vantagem real, desde que o consumo seja controlado e previsível.

Mas a nuvem não significa apenas enviar dados para um fornecedor. É preciso validar onde os dados residem, que mecanismos de encriptação estão activos, quem controla as chaves, como funciona a retenção e se existe imutabilidade. Uma política mal configurada pode permitir a eliminação de cópias antes do prazo previsto. Uma conta na nuvem sem autenticação multifator e segregação de funções pode ser tão vulnerável quanto um servidor local mal protegido.

A recuperação também deve ser calculada antes do incidente. Restaurar 20 GB de documentos é diferente de recuperar vários terabytes de máquinas virtuais. Em determinados cenários, pode ser necessário recorrer a recuperação direta na nuvem, a uma zona de recuperação de desastre ou a um processo de recuperação faseado. Não há uma resposta universal: depende dos RTO/RPO acordados e do impacto de cada serviço.

A arquitetura híbrida reduz os compromissos

Uma estratégia híbrida bem desenhada usa cada camada para o que faz melhor. A cópia local serve a recuperação rápida. A cópia externa protege contra desastre no local principal. A imutabilidade impede que alterações maliciosas ou acidentais destruam pontos de recuperação válidos.

Este modelo aproxima-se da regra 3-2-1-1-0: três cópias dos dados, em dois suportes distintos, uma cópia fora do local, uma cópia imutável ou isolada e zero erros verificados nas recuperações. Não é uma fórmula decorativa. É uma disciplina operacional que obriga a pensar em falhas reais.

Por exemplo, uma empresa pode manter cópias de segurança diárias de máquinas virtuais num appliance local, replicar esses pontos para a nuvem com retenção imutável e preservar cópias mensais durante o período exigido por obrigações legais ou internas. Os sistemas mais críticos podem ainda ter replicação para um ambiente de recuperação, reduzindo o tempo necessário para retomar serviço após uma falha total.

A classificação é decisiva. Nem todos os dados justificam o mesmo custo ou a mesma frequência de cópia. Um ficheiro de trabalho pode admitir um RPO de 24 horas; uma base de dados de encomendas pode exigir pontos de recuperação de 15 minutos. Tratar tudo da mesma forma aumenta custos e, frequentemente, deixa os serviços prioritários sem a proteção necessária.

RTO e RPO devem mandar na decisão

O RPO define a quantidade máxima de dados que a empresa aceita perder. O RTO define o tempo máximo aceitável para recuperar um serviço. Ambos devem ser aprovados pelos responsáveis de negócio, não apenas pela equipa de TI.

Se o RPO de uma aplicação for de quatro horas, uma cópia de segurança diária não cumpre o requisito. Se o RTO for de duas horas, uma recuperação que dependa de descarregar vários terabytes pela Internet pode ser inadequada. Estes desvios só se tornam visíveis quando se testa a recuperação — e nessa altura, se não houver preparação, o incidente já está em curso.

É também aqui que a NIS2 e a governança ganham expressão prática. A capacidade de demonstrar políticas, responsabilidades, registos de execução, monitorização e testes de recuperação é tão relevante quanto adquirir tecnologia. A direcção precisa de saber quem decide, quem executa e como se prova que o plano funciona.

Da política à recuperação: quatro fases de execução

Uma estratégia de cópia de segurança não deve começar pela escolha de um produto. Começa por um diagnóstico: identificar aplicações, dependências, volumes, classificações de dados, RTO/RPO, requisitos de retenção e riscos de cibersegurança. Sem este inventário, qualquer dimensionamento é uma estimativa frágil.

A segunda fase é a arquitetura. Define-se a combinação de repositório local, nuvem, imutabilidade, segmentação de rede, encriptação, contas de serviço e capacidade necessária. Também se estabelecem políticas de retenção que conciliem exigências legais, necessidades do negócio e controlo de custos.

Depois segue-se a implementação, com configuração, migração quando aplicável, validação de jobs, documentação e testes iniciais de restauro. Não basta confirmar que o relatório indica sucesso. É necessário abrir os ficheiros, arrancar as máquinas recuperadas e validar consistência das aplicações.

Por fim, a operação contínua. As cópias de segurança precisam de acompanhamento diário, gestão de excepções, revisão de capacidade, atualização de componentes e testes periódicos. Na ITPOINT, esta é a diferença entre vender armazenamento e operar infraestrutura: assumir responsabilidades claras, monitorização e suporte com SLA contratual.

O erro mais caro é descobrir tarde demais

Os problemas mais frequentes são previsíveis: cópias sem isolamento, retenções demasiado curtas, credenciais partilhadas, alertas ignorados, capacidade esgotada e recuperações nunca testadas. O denominador comum é assumir que uma cópia de segurança concluída equivale a uma cópia de segurança recuperável.

A melhor estratégia não é a que acumula mais cópias. É a que permite recuperar os serviços certos, no tempo acordado, com dados válidos e sem depender de decisões improvisadas durante uma crise. É essa prova operacional que deve orientar a escolha entre cópia de segurança local, na nuvem ou uma arquitetura híbrida.