Como implementar políticas de backup 3-2-1

1. Fundamentos da Estratégia 3-2-1

A regra 3-2-1 é o padrão-ouro em resiliência de dados, originada das melhores práticas de administração de sistemas nos anos 2000. Ela estabelece:

  • 3 cópias dos dados (1 primária + 2 backups)
  • 2 mídias diferentes (ex.: HDD + fita magnética, ou SSD + nuvem)
  • 1 cópia fora do site (off-site, geograficamente distante)

Diferencie backup (cópia para recuperação pontual), réplica (espelho contínuo para alta disponibilidade) e snapshot (instantâneo de estado, dependente do sistema original). No contexto 3-2-1, o backup é a principal ferramenta, pois oferece independência do ambiente primário.

2. Planejamento da Infraestrutura de Armazenamento

Selecione duas mídias com características complementares:

Mídia Vantagem Desvantagem
HDD/SSD local Baixa latência, fácil acesso Vulnerável a desastres físicos
Fita LTO Baixo custo por TB, longa duração Lentidão em restaurações
Nuvem (S3/Glacier) Escalabilidade infinita, off-site nativo Custos de egress e latência de rede

Dimensionamento: reserve 3x o tamanho dos dados primários para acomodar versões incrementais e retenção. Para 10 TB de dados críticos, planeje 30 TB de capacidade total de backup.

Localização off-site: distância mínima de 50 km do site primário para evitar desastres regionais (enchentes, incêndios). Latência de rede aceitável: até 100 ms para backups batch.

3. Implementação da Cópia Primária (Local)

Configure backup completo diário + incrementais a cada 4 horas. Exemplo com rsync e script shell:

#!/bin/bash
# Backup completo semanal (domingo) + incremental diário
BACKUP_DIR="/mnt/backup_local"
DATA_DIR="/dados/producao"
DATE=$(date +%Y-%m-%d)
DAY=$(date +%u)

if [ "$DAY" -eq 7 ]; then
    # Completo
    rsync -av --delete "$DATA_DIR" "$BACKUP_DIR/completo/$DATE"
else
    # Incremental
    rsync -av --link-dest="$BACKUP_DIR/completo/$(ls -t $BACKUP_DIR/completo | head -1)" \
          "$DATA_DIR" "$BACKUP_DIR/incremental/$DATE"
fi

Política de retenção local:
- 7 dias: backups diários
- 30 dias: backups semanais
- 90 dias: backups mensais

Ferramentas como Veeam ou Bacula automatizam essa rotação com políticas de expiração.

4. Implementação da Cópia Secundária (Mídia Diferente)

Escolha uma mídia alternativa à primária. Exemplo: se o backup local está em HDD, use fita LTO-9 (18 TB nativos) ou armazenamento óptico (Blu-ray M-DISC para arquivamento de longa duração).

Conversão entre formatos: garanta legibilidade futura exportando metadados e usando formatos abertos (tar, ZIP com compressão padrão). Exemplo de script para gravação em fita com mt e tar:

# Backup para fita LTO
mt -f /dev/st0 rewind
tar -cvf /dev/st0 /mnt/backup_local/completo/$(date +%Y-%m-%d)
mt -f /dev/st0 offline

Teste de restauração cruzada: a cada trimestre, restaure um arquivo aleatório da fita para o HDD e vice-versa. Documente o sucesso ou falha.

5. Implementação da Cópia Off-Site

Opções viáveis:
- Nuvem pública: AWS S3 (padrão) ou Glacier (arquivamento frio)
- Datacenter secundário: servidor próprio em outra cidade
- Cofre físico: armazenamento terceirizado com coleta semanal

Criptografia: use AES-256 em trânsito (TLS 1.3) e em repouso (chave gerenciada pelo KMS). Exemplo com gpg antes do upload:

# Criptografar antes de enviar para S3
gpg --symmetric --cipher-algo AES256 --passfile /etc/backup.key \
    /mnt/backup_local/completo/$(date +%Y-%m-%d).tar.gz

aws s3 cp /mnt/backup_local/completo/$(date +%Y-%m-%d).tar.gz.gpg \
    s3://meu-bucket-offsite/backups/

Sincronização: assíncrona (RPO de minutos) vs batch programado (RPO de horas). Para dados críticos, prefira assíncrona com replicação contínua; para dados menos críticos, batch diário reduz custos de egress.

6. Automação e Monitoramento do Ciclo de Backup

Agende com cron (Linux) ou systemd timers:

# /etc/cron.d/backup_3-2-1
0 2 * * * root /usr/local/bin/backup_local.sh
0 4 * * * root /usr/local/bin/backup_offsite.sh
0 6 * * 0 root /usr/local/bin/backup_fita.sh

Alertas: integre com Slack ou e-mail para falhas. Exemplo com curl e webhook:

# Alerta em caso de falha
if [ $? -ne 0 ]; then
    curl -X POST -H "Content-type: application/json" \
         --data '{"text":"Falha no backup off-site - $(date)"}' \
         https://hooks.slack.com/services/TOKEN
fi

Métricas:
- Tempo de janela de backup (ideal < 4 horas)
- Taxa de compressão (mínimo 1.5:1 para dados textuais)
- Checksums (SHA256) para verificar integridade pós-backup

7. Testes de Restauração e Validação

Procedimento trimestral:

  1. Isolar ambiente: monte um servidor de teste sem conexão com produção.
  2. Restaurar completo: do backup local, depois da fita, depois da nuvem.
  3. Verificar consistência:
  4. Checksums dos arquivos restaurados vs originais
  5. Logs de aplicação (ex.: banco de dados deve iniciar sem erros)
  6. Integridade de banco (ex.: DBCC CHECKDB no SQL Server)

Documente o RTO real (ex.: 2 horas para 500 GB) vs planejado (ex.: 1 hora). Ajuste processos se a diferença for > 50%.

8. Evolução e Manutenção da Política

Revisão semestral:
- Ajuste retenção conforme crescimento de dados (ex.: dobrar de 90 para 180 dias se o volume aumentar 20% ao ano)
- Migre para novas gerações de mídia (ex.: LTO-8 para LTO-9 a cada 3 anos)

Integração com compliance:
- LGPD: backups devem ser criptografados e com política de expurgo após 5 anos
- SOX: retenção mínima de 7 anos para dados financeiros
- ISO 27001: testes de restauração documentados e auditoria anual

Referências