Backup e Disaster Recovery para Provedores de Internet

Perder a configuracao de um roteador de borda em plena madrugada de sexta-feira. Ter o banco de dados do billing corrompido sem backup recente. Descobrir que os logs de CGNAT dos ultimos 6 meses sumiram quando chega um oficio judicial. Qualquer um desses cenarios pode custar desde horas de indisponibilidade ate multas de R$ 10.000 por dia.

Neste guia, vamos montar uma estrategia completa de backup e disaster recovery pensada especificamente para provedores de internet brasileiros, cobrindo todos os ativos criticos: equipamentos de rede, bancos de dados, logs regulatorios e sistemas de gestao.

Por que ISPs precisam de uma estrategia diferenciada

Um provedor nao e uma empresa de software comum. Existem particularidades que tornam backup e DR mais complexos:

• Equipamentos distribuidos: roteadores, OLTs, switches em torres e POPs remotos
• Obrigacoes legais: o Marco Civil da Internet exige guarda de registros de conexao por 1 ano (art. 13)
• Disponibilidade 24/7: cada minuto fora do ar impacta centenas ou milhares de assinantes
• Dados heterogeneos: configs de rede, bancos SQL, logs syslog/NetFlow, RADIUS accounting
• Volume de logs: um provedor com 5.000 assinantes em CGNAT pode gerar 50-100 GB de logs por dia

Inventario: o que precisa de backup

Antes de definir ferramentas, liste todos os ativos criticos:

Backup de equipamentos de rede com Oxidized

O Oxidized e a ferramenta padrao do mercado para backup automatico de configuracoes de equipamentos de rede. Ele substitui o antigo RANCID com uma arquitetura mais moderna em Ruby.

Instalacao via Docker

# docker-compose.yml para Oxidized
version: '3.8'
services:
  oxidized:
    image: oxidized/oxidized:latest
    container_name: oxidized
    restart: unless-stopped
    ports:
      - "127.0.0.1:8888:8888"
    volumes:
      - ./oxidized-config:/home/oxidized/.config/oxidized
    environment:
      CONFIG_RELOAD_INTERVAL: 600

Configuracao para MikroTik e Huawei

# /home/oxidized/.config/oxidized/config
---
username: backup-user
password: SenhaF0rte!2026
model: routeros
interval: 3600
use_syslog: true
log: /home/oxidized/.config/oxidized/logs/oxidized.log
groups:
  mikrotik:
    model: routeros
  huawei:
    model: vrp
source:
  default: csv
  csv:
    file: /home/oxidized/.config/oxidized/router.db
    delimiter: ;
    map:
      name: 0
      ip: 1
      model: 2
      group: 3
output:
  default: git
  git:
    user: oxidized
    email: oxidized@provedor.com.br
    repo: /home/oxidized/.config/oxidized/devices.git

# router.db
CCR1036-Borda;172.20.1.105;routeros;mikrotik
CCR-Tavares;172.20.1.58;routeros;mikrotik
NE8000;172.20.1.1;vrp;huawei
S5732-Princesa;172.20.1.90;vrp;huawei

Com output em Git, cada alteracao de configuracao gera um commit automatico. Voce tem historico completo de todas as mudancas, com diff entre versoes.

Backup de bancos de dados

MySQL/MariaDB (billing, RADIUS)

# Backup completo com compressao
mysqldump --single-transaction --routines --triggers \
  --all-databases | gzip > /backup/mysql/full-$(date +%Y%m%d-%H%M).sql.gz

# Backup incremental com binlog
mysql -e "FLUSH LOGS;"
cp /var/lib/mysql/binlog.* /backup/mysql/binlog/

# Cron - backup diario 4h, binlog a cada hora
0 4 * * * /opt/scripts/mysql-full-backup.sh
0 * * * * /opt/scripts/mysql-binlog-backup.sh

PostgreSQL (se usar IXCSoft ou outro)

# Backup com pg_dump
pg_dump -Fc -Z6 billing_db > /backup/pgsql/billing-$(date +%Y%m%d).dump

# WAL archiving para point-in-time recovery
# postgresql.conf
archive_mode = on
archive_command = 'cp %p /backup/pgsql/wal/%f'

Backup de logs CGNAT

Logs de CGNAT sao o ativo mais volumoso e um dos mais criticos legalmente. A estrategia depende de como voce os armazena:

Se usa NATVault (VictoriaLogs)

O NATVault ja cuida da retencao e redundancia dos logs. Para backup adicional:

# Export periodico para storage frio
curl -s 'http://natvault:9428/select/logsql/query' \
  --data-urlencode "query=_stream:{source=\"cgnat\"}" \
  --data-urlencode "start=$(date -d 'yesterday' +%Y-%m-%dT00:00:00Z)" \
  --data-urlencode "end=$(date -d 'yesterday' +%Y-%m-%dT23:59:59Z)" \
  | gzip > /backup/cgnat/cgnat-$(date -d yesterday +%Y%m%d).json.gz

Se usa syslog em arquivos

# Compressao diaria e envio para storage remoto
find /var/log/cgnat/ -name '*.log' -mtime +1 -exec gzip {} \;
rsync -az /var/log/cgnat/*.gz backup-server:/backup/cgnat/

Definindo RPO e RTO

Dois conceitos fundamentais para disaster recovery:

• RPO (Recovery Point Objective): quanto de dados voce aceita perder. RPO de 1 hora = voce aceita perder ate 1 hora de dados.
• RTO (Recovery Time Objective): quanto tempo ate restaurar o servico. RTO de 4 horas = servico precisa voltar em ate 4 horas.

Plano de Disaster Recovery

Cenario 1: Falha de disco no servidor principal

1. Detectar via Zabbix/monitoramento (SMART alerts)
2. Avaliar: disco de SO vs disco de dados
3. Se SO: restaurar VM do ultimo vzdump em outro host Proxmox
4. Se dados: restaurar backup mais recente do banco
5. Aplicar binlogs/WAL para minimizar perda

Cenario 2: Roteador de borda falhou

1. Substituir por equipamento spare (manter pelo menos 1 CCR reserva)
2. Restaurar config do Oxidized: /system/backup/load name=oxidized-backup
3. Verificar BGP sessions e PPPoE
4. Tempo estimado: 15-30 minutos com spare pronto

Cenario 3: Perda total do data center

1. Ativar site DR (se existir) ou provisionar cloud temporario
2. Restaurar configs de rede do Git (Oxidized)
3. Restaurar bancos do backup off-site
4. Restaurar VMs do vzdump remoto
5. Redirecionar DNS/BGP
6. Tempo estimado: 4-8 horas

Regra 3-2-1 para ISPs

A regra classica de backup adaptada para provedores:

• 3 copias de cada dado critico
• 2 midias diferentes (disco local + storage remoto ou fita)
• 1 copia off-site (outro POP, cloud S3-compatible, ou datacenter parceiro)

# Script de sincronizacao off-site com rclone
# Suporta S3, Backblaze B2, Google Cloud Storage, etc
rclone sync /backup/ remote:provedor-backup/ \
  --transfers 8 --checkers 16 \
  --bwlimit 50M \
  --log-file /var/log/rclone-backup.log

Testando a restauracao

Um backup que nunca foi testado nao e um backup. Agende testes regulares:

• Mensal: restaurar backup do banco em ambiente de teste, verificar integridade
• Trimestral: simular falha de um equipamento, restaurar config do Oxidized
• Semestral: simular disaster recovery completo em ambiente isolado

# Teste automatico de integridade do backup MySQL
gunzip -c /backup/mysql/full-latest.sql.gz | \
  mysql --host=test-server billing_test && \
  mysql --host=test-server -e "SELECT COUNT(*) FROM billing_test.clientes;" | \
  mail -s 'Backup test OK' noc@provedor.com.br