Um guia para políticas de backup

Uma falha de armazenamento, um ataque de ransomware ou um erro humano podem interromper operações essenciais em poucos minutos. Um guia para políticas de backup permite transformar a cópia de dados de uma tarefa técnica pouco visível num compromisso operacional claro, com responsáveis, critérios de recuperação e validação regular.

Ter backups não é, por si só, uma garantia de continuidade. A questão decisiva é outra: a empresa consegue recuperar a informação certa, no prazo exigido pelo negócio e sem introduzir novo risco? Uma política bem definida responde a essa pergunta antes de ocorrer um incidente.

Guia para políticas de backup: começar pelo risco

Uma política de backup eficaz não deve começar pela escolha da ferramenta nem por uma regra genérica como “fazer cópias todos os dias”. Deve começar pela identificação dos serviços e dados cujo indisponibilidade tem maior impacto: sistemas de gestão, bases de dados, ficheiros de projeto, plataformas de colaboração, correio eletrónico, máquinas virtuais, configurações de rede e aplicações críticas.

Cada activo deve ser avaliado segundo três critérios: impacto financeiro e operacional da paragem, sensibilidade dos dados e dependências técnicas. Um sistema de faturação parado durante quatro horas pode ter uma prioridade diferente de uma área documental que pode ficar indisponível até ao dia seguinte. Tratar ambos da mesma forma aumenta custos sem garantir melhor proteção.

Esta análise deve envolver a direção de TI, responsáveis operacionais, segurança e áreas de negócio. A tecnologia executa o backup, mas só o negócio consegue determinar quais os dados que não podem ser perdidos e durante quanto tempo pode tolerar uma interrupção.

Definir RPO e RTO sem ambiguidade

Dois indicadores tornam a política mensurável: o RPO e o RTO. O RPO, Recovery Point Objective, define a perda máxima de dados aceitável. Se o RPO de uma base de dados for uma hora, a empresa tem de conseguir recuperar informação com, no máximo, uma hora de desfasamento.

O RTO, Recovery Time Objective, estabelece o tempo máximo para repor um serviço. Um RTO de duas horas significa que, após uma falha, a aplicação deverá estar operacional nesse período, incluindo validações técnicas essenciais.

Estes objetivos não devem ser definidos por hábito. Um RPO de cinco minutos e um RTO de trinta minutos podem ser justificados para uma operação transaccional crítica, mas exigem infraestrutura, automação, armazenamento e monitorização mais exigentes. Para sistemas menos críticos, metas mais equilibradas podem oferecer a proteção necessária com um investimento controlado.

O que deve constar numa política de backup

Uma política útil tem de ser suficientemente objectiva para orientar a operação diária e suficientemente clara para apoiar decisões durante um incidente. Não deve ficar limitada a um documento arquivado sem revisão ou a instruções conhecidas apenas por um administrador.

A política deve identificar os sistemas abrangidos, os proprietários da informação, as frequências de cópia, os períodos de retenção, os locais de armazenamento e os procedimentos de recuperação. Deve também indicar quem pode solicitar um restauro, quem o aprova e como se regista a intervenção.

A distinção entre responsabilidade técnica e responsabilidade de negócio é particularmente relevante. A equipa de TI pode assegurar que uma cópia é executada, mas o proprietário do sistema deve confirmar quais os dados prioritários e validar que o restauro responde às necessidades da operação.

Uma política madura deverá incluir, pelo menos, os seguintes elementos:

  • Inventário dos sistemas, dados e configurações abrangidos pelo backup.
  • Classificação de criticidade e objetivos de RPO e RTO por serviço.
  • Frequência das cópias e regras de retenção diária, mensal e anual.
  • Localização das cópias, requisitos de cifragem e controlo de acessos.
  • Processo de monitorização, testes de restauro, reporte de falhas e revisão periódica.

A retenção merece atenção especial. Manter cópias durante demasiado pouco tempo pode impedir a recuperação de informação eliminada ou comprometida semanas antes. Manter tudo indefinidamente pode elevar custos, complicar a gestão e criar riscos de conformidade. A duração adequada depende de obrigações legais, necessidades contratuais, ciclos contabilísticos e valor operacional dos dados.

Aplicar a regra 3-2-1-1-0 com critério

A regra 3-2-1-1-0 continua a ser uma referência prática. Pressupõe três cópias dos dados, em dois suportes ou ambientes distintos, uma cópia fora do local principal, uma cópia imutável ou isolada e zero erros verificados nos backups.

Não é uma fórmula rígida aplicável da mesma forma a todos os ambientes. Uma organização com aplicações em cloud, servidores locais e serviços SaaS precisa de adaptar o modelo às suas responsabilidades reais. Os dados alojados num serviço cloud não estão automaticamente protegidos contra eliminação acidental, erros de sincronização, credenciais comprometidas ou políticas de retenção insuficientes do próprio serviço.

A cópia imutável é uma proteção relevante contra ransomware, pois impede a alteração ou eliminação dos backups durante um período definido. Ainda assim, não substitui os restantes controlos. Se as credenciais administrativas do ambiente de backup forem demasiado permissivas, se não houver segmentação de rede ou se os alertas forem ignorados, a capacidade de recuperação pode ficar comprometida.

Também importa proteger as configurações. Um backup de dados sem cópias das configurações de firewalls, equipamentos de rede, aplicações, políticas de segurança e credenciais de serviço pode prolongar significativamente a recuperação. Em muitos incidentes, repor os dados é apenas uma parte do trabalho.

Segurança, conformidade e controlo de acessos

Os backups contêm, muitas vezes, a informação mais completa da empresa. Por isso, devem ser tratados como activos sensíveis e não como simples réplicas técnicas. A política deve exigir cifragem em trânsito e em repouso, autenticação multifator para contas administrativas e privilégio mínimo no acesso às consolas de gestão.

É aconselhável separar funções sempre que possível. Quem administra os sistemas de produção não deve ter, sem controlo, capacidade total para eliminar cópias de segurança. Da mesma forma, as contas usadas para executar backups devem ter apenas as permissões indispensáveis.

No contexto do RGPD, a política deve alinhar-se com os princípios de limitação da conservação e segurança do tratamento. Isto não significa eliminar backups ao primeiro pedido de apagamento, pois podem existir obrigações legais e limitações técnicas legítimas. Significa documentar os prazos, justificar a retenção e assegurar que os dados restaurados não voltam a introduzir informação indevidamente tratada nos sistemas produtivos.

Testar a recuperação é o verdadeiro controlo

Um backup concluído com sucesso prova apenas que foi criada uma cópia. Não prova que essa cópia é recuperável, completa, consistente ou adequada ao RTO definido. A validação exige testes regulares de restauro.

Os testes devem começar por ficheiros e pastas, mas não podem terminar aí. É necessário testar a recuperação de bases de dados, máquinas virtuais, aplicações críticas e serviços completos, incluindo as suas dependências. Um restauro tecnicamente bem-sucedido que deixa uma aplicação sem ligação à base de dados, sem certificados ou sem configurações de rede não satisfaz a necessidade do negócio.

A frequência depende da criticidade. Os serviços mais relevantes devem ser testados em cenários controlados com maior regularidade, enquanto os restantes podem seguir um calendário trimestral ou semestral. O essencial é registar o tempo efectivo de recuperação, as falhas encontradas, os passos manuais necessários e as medidas correctivas.

Estes exercícios também devem considerar cenários realistas: indisponibilidade do local principal, perda de uma credencial privilegiada, infeção por ransomware ou falha simultânea de vários sistemas. Não se trata de criar alarmismo, mas de remover incerteza quando a pressão é maior.

Operar, monitorizar e rever a política

Uma política de backup perde valor quando não acompanha alterações no ambiente tecnológico. A entrada de uma nova aplicação, uma migração para cloud, a abertura de uma filial ou uma alteração nos requisitos de retenção devem desencadear uma revisão. Caso contrário, surgem zonas sem proteção, frequentemente detetadas apenas depois de um incidente.

A monitorização deve confirmar mais do que o estado de execução. Deve detetar falhas recorrentes, volumes anormais de dados, redução inesperada de espaço, cópias incompletas, alterações de configuração e tentativas de eliminação. Os alertas precisam de chegar a uma equipa com responsabilidade e capacidade de intervenção, incluindo fora do horário normal quando a criticidade o justifique.

Para muitas empresas, a dificuldade não está em reconhecer estes requisitos, mas em garantir a disciplina operacional necessária para os cumprir. A gestão continuada de backups exige visibilidade, competências, documentação actualizada e capacidade de resposta. Um parceiro especializado, como a FACTIS, pode apoiar esta operação como extensão da equipa interna, ligando a proteção de dados à gestão de serviço, segurança e continuidade operacional.

O melhor momento para testar uma recuperação não é depois de receber uma mensagem de extorsão ou de descobrir que uma base de dados foi eliminada. Marque um teste, envolva os responsáveis do negócio e meça o resultado. A certeza de que consegue recuperar vale muito mais do que a expectativa de que o backup funcionará.