Estratégias de backup e restauração de dados

1. Fundamentos de Backup de Dados

A continuidade de negócios depende diretamente da capacidade de recuperar dados após falhas, ataques ou desastres. Backup é a cópia de dados em um local separado, enquanto réplica mantém cópias sincronizadas em tempo real e snapshots capturam o estado de um sistema em um instante específico. Dois indicadores críticos definem qualquer estratégia: RPO (Recovery Point Objective) — quantidade máxima de dados que pode ser perdida — e RTO (Recovery Time Objective) — tempo máximo para restaurar operações.

2. Tipos de Backup e Estruturas de Armazenamento

Backup completo, incremental e diferencial

  • Completo: copia todos os dados. Simples de restaurar, mas consome mais tempo e espaço.
  • Incremental: copia apenas dados alterados desde o último backup (completo ou incremental). Economiza espaço, mas restauração exige a cadeia completa.
  • Diferencial: copia alterações desde o último backup completo. Equilíbrio entre velocidade de backup e restauração.

Backup lógico vs. físico

Backup lógico exporta dados em formato legível (ex: SQL), permitindo restauração seletiva. Backup físico copia arquivos de dados brutos, sendo mais rápido para recuperação total.

Estratégia 3-2-1

Mantenha 3 cópias dos dados, em 2 mídias diferentes, com 1 cópia offsite. Exemplo: produção local, backup em NAS e cópia na nuvem.

3. Estratégias para Bancos de Dados Relacionais

PostgreSQL

pg_dump para backups lógicos:

pg_dump -U usuario -h localhost -d meubanco > backup_completo.sql

pg_basebackup para backup físico:

pg_basebackup -U replicador -h localhost -D /backup/pgdata -X stream -P

WAL archiving permite PITR (Point-In-Time Recovery):

# postgresql.conf
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'

Restauração PITR:

# recovery.conf
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2024-12-20 14:30:00 BRT'

MySQL/MariaDB

mysqldump para backups lógicos:

mysqldump -u root -p --all-databases > backup_completo.sql

XtraBackup para backups físicos com consistência transacional:

xtrabackup --backup --target-dir=/backup/mysql
xtrabackup --prepare --target-dir=/backup/mysql

Binlog para PITR:

mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

4. Estratégias para Bancos NoSQL e Sistemas Distribuídos

MongoDB

mongodump para backup lógico:

mongodump --uri="mongodb://localhost:27017" --out=/backup/mongo

mongorestore para restauração:

mongorestore --uri="mongodb://localhost:27017" /backup/mongo

Snapshots de arquivos (LVM/EBS) para backups físicos consistentes.

Redis/Valkey

RDB snapshots (dump.rdb) e AOF logs (append-only file):

# redis.conf
save 900 1
save 300 10
save 60 10000
appendonly yes

Backup combinado:

cp /var/lib/redis/dump.rdb /backup/redis/
cp /var/lib/redis/appendonly.aof /backup/redis/

Desafios em sistemas distribuídos

Cassandra usa snapshots e commit logs; Elasticsearch usa snapshots de índices. Consistência eventual exige validação de dados após restauração.

5. Automação, Monitoramento e Testes de Restauração

Automação com scripts shell e cron

#!/bin/bash
# backup_postgres.sh
DATA=$(date +%Y%m%d_%H%M)
pg_dump -U admin meubanco > /backup/meubanco_$DATA.sql
find /backup -name "*.sql" -mtime +7 -delete

Crontab:

0 2 * * * /usr/local/bin/backup_postgres.sh

Ferramentas especializadas

  • Barman: gerenciamento de backups PostgreSQL com PITR.
  • pgBackRest: backup físico com compressão e paralelismo.

Testes de restauração

Crie ambientes isolados (Docker) para validar backups periodicamente:

docker run --name test_restore -e POSTGRES_PASSWORD=teste -d postgres:16
cat backup.sql | docker exec -i test_restore psql -U postgres
docker exec test_restore psql -U postgres -c "SELECT count(*) FROM tabela_importante;"

6. Segurança, Criptografia e Conformidade

Criptografia em trânsito e repouso

Backup com GPG:

pg_dump -U admin meubanco | gpg --encrypt --recipitor admin@empresa.com > backup.sql.gpg

Descriptografia para restauração:

gpg --decrypt backup.sql.gpg | psql -U admin meubanco

Políticas de retenção

  • Backups diários: 7 dias
  • Backups semanais: 4 semanas
  • Backups mensais: 12 meses

LGPD/GDPR

Dados sensíveis devem ser anonimizados em backups de desenvolvimento/teste. Ferramentas como pg_anon permitem mascaramento.

7. Recuperação de Desastres e Planos de Contingência

Estratégias de disaster recovery

  • Failover automático: replicação síncrona com Patroni (PostgreSQL) ou Galera (MariaDB).
  • Multi-região: backups replicados para AWS S3 em regiões diferentes.
  • Backups offsite: cópia para cloud storage (S3, GCS, Azure Blob).

Runbook de restauração

Documente passo a passo:

1. Identificar o backup mais recente
2. Parar serviço de banco
3. Restaurar arquivos de dados
4. Aplicar WAL logs (se PITR)
5. Iniciar serviço e validar consistência
6. Registrar horário de conclusão

Análise pós-incidente

  • Documente causas e soluções
  • Ajuste RPO/RTO conforme necessário
  • Automatize falhas manuais identificadas

Referências