O Problema: Backups Não São Apenas uma Tarefa de TI
É fácil ignorar os backups quando tudo está funcionando. Mas, em um ambiente corporativo real, a perda de dados não precisa vir de um grande desastre. Às vezes, é apenas um disco com defeito, um usuário apagando uma pasta acidentalmente ou uma estação de trabalho que precisa ser formatada sem aviso prévio.
No ambiente que eu gerencio, já havíamos enfrentado problemas desse tipo. Arquivos de usuários sendo perdidos, pastas compartilhadas precisando de melhor proteção, e o risco mais crítico era o nosso banco de dados ERP on-premises. Esse banco de dados armazenava informações essenciais para o negócio e, na época, não tínhamos uma estratégia adequada de backup e recuperação caso algo grave acontecesse com o servidor.
Essa situação me forçou a pensar além de simples cópias de arquivos. Eu precisava projetar uma estratégia de backup que considerasse diferentes tipos de dados, diferentes cenários de falha e diferentes necessidades de recuperação.
Este post é a primeira parte de uma série onde vou explicar como comecei a construir uma estratégia de backup em camadas para o nosso ambiente.
O Ambiente em Que Eu Trabalhava
O ambiente da empresa era majoritariamente on-premises, com Active Directory, estações de trabalho Windows, compartilhamentos de arquivos, máquinas virtuais Proxmox e um sistema ERP apoiado por um banco de dados PostgreSQL rodando em uma VM Linux. Na época, ainda não tínhamos uma estrutura madura de endpoints ou backups baseada em nuvem, então tive que trabalhar com as ferramentas e a infraestrutura já disponíveis.
Os Riscos Que Eu Precisava Tratar
Antes de escolher as ferramentas, tentei separar os riscos em diferentes categorias:
- usuários perdendo seus arquivos locais (acontece mais do que você imagina);
- pastas e arquivos compartilhados sendo modificados ou excluídos acidentalmente;
- falha de VM;
- corrupção ou perda do banco de dados do ERP;
- perda do destino principal de backup;
- desastre físico ou ransomware afetando o ambiente local.
A Estratégia de Backup em Camadas
Proteção de Arquivos de Usuários
Para os arquivos dos usuários, implementei uma abordagem baseada em políticas (GPO) usando o Active Directory e o Redirecionamento de Pastas (Folder Redirection). O objetivo era manter os arquivos importantes dos usuários sincronizados com um local no servidor, reduzindo o risco de perda de dados quando uma estação de trabalho falhasse ou precisasse ser formatada.
Backups de Pastas Compartilhadas
As pastas compartilhadas tinham um perfil de risco diferente. Elas eram usadas por múltiplos departamentos e usuários e continham arquivos que poderiam ser excluídos, sobrescritos ou modificados acidentalmente. Por esse motivo, precisavam de backups agendados e um caminho de restauração claro.
Backups do Banco de Dados PostgreSQL
O banco de dados do ERP exigia uma abordagem diferente. Um banco de dados não é apenas mais uma pasta para copiar. Como ele rodava em PostgreSQL, escolhi implementar uma estratégia de backup consciente do banco de dados (database-aware) com o Barman, permitindo um planejamento de backup e recuperação mais confiável do que uma simples cópia de arquivos.
O objetivo não era apenas ter uma cópia dos arquivos do banco de dados, mas sim ter um processo de recuperação que respeitasse o funcionamento do PostgreSQL. Isso é importante porque os bancos de dados podem ficar em um estado inconsistente se forem copiados incorretamente enquanto estão em execução.
Backups das VMs Proxmox
Os backups de VM eram usados para proteger a camada de infraestrutura. Enquanto os backups no nível do banco de dados protegem os dados dentro do sistema, os backups de VM ajudam a recuperar o estado do servidor, sistema operacional, serviços e configurações. Essa camada era importante porque os backups locais ainda estão expostos a incidentes locais. Se o mesmo local físico, rede ou ambiente administrativo for comprometido, uma cópia remota se torna parte do plano de recuperação.
Camada Secundária de Backup Local
Eu também queria evitar depender de um único destino de backup. Se todos os backups existirem apenas em um lugar, esse armazenamento se torna outro ponto único de falha. Por esse motivo, adicionei uma camada secundária de backup local em um servidor dedicado.
Camada de Backup Remoto
Por fim, adicionei uma camada de backup remoto. Backups locais são úteis para restaurações rápidas, mas não protegem totalmente contra incidentes físicos, falhas graves de infraestrutura ou cenários em que o próprio ambiente local é comprometido.
Transformando a Estratégia em Rotinas de Backup
Após definir os principais riscos, traduzi a estratégia em rotinas de backup agendadas. Cada rotina tinha um propósito específico, frequência, período de retenção e expectativa de recuperação. Isso ajudou a evitar tratar todos os dados da mesma forma, pois arquivos de usuários, pastas compartilhadas, máquinas virtuais e bancos de dados têm necessidades de recuperação diferentes.
| Área de backup | Propósito | Frequência | Retenção | Observações |
|---|---|---|---|---|
| Pastas compartilhadas | Proteger arquivos de departamentos e do negócio contra exclusão, sobrescrita ou corrupção | Diária | Retenção diária e semanal | Backup incremental para reduzir o uso de armazenamento |
| Banco de dados ERP PostgreSQL | Proteger dados críticos do negócio com recuperação consciente do banco de dados | Backup completo diário + arquivamento frequente de WAL | Retenção operacional de curto prazo | Restauração testada regularmente |
| VMs Proxmox | Recuperar estado do servidor, SO, serviços e configurações | Diária | Vários pontos de recuperação recentes | Diferentes modos de backup dependendo da criticidade da VM |
| Pastas de usuários | Reduzir a perda de dados durante falha ou formatação de estações de trabalho | Contínuo/sincronizado | Baseado na política de backup do lado do servidor | Implementado através do Active Directory e Redirecionamento de Pastas |
| Backup local secundário | Evitar depender de apenas um destino de backup | Diária / agendada | Depende do tipo de backup de origem | Servidor de backup local dedicado |
| Backup remoto | Adicionar proteção contra falha da infraestrutura local | Agendada | Depende do armazenamento disponível e necessidades de recuperação | Usado como uma camada de recuperação offsite |
O Que Eu Aprendi
Uma das principais lições que aprendi é que a estratégia de backup não se trata apenas de criar cópias. Trata-se de entender o que pode falhar, quantos dados a empresa pode se dar ao luxo de perder, quão rápido os sistemas precisam ser restaurados e se o processo de recuperação realmente funciona quando testado.
O Que Vem a Seguir
Este post é apenas uma visão geral da lógica de backup que construí. Nos próximos artigos, detalharei cada camada com mais profundidade, incluindo como usei o Redirecionamento de Pastas via Política de Grupo para os arquivos dos usuários, como configurei os backups do PostgreSQL com o Barman, como os backups das VMs Proxmox se encaixam na estratégia e como adicionei as camadas de backup local secundário e remoto.