BorgBackup

1. Visão geral e contexto

O BorgBackup (comumente chamado apenas de Borg) é uma ferramenta de backup open‑source (BSD‑3‑Clause) que combina deduplicação em nível de bloco, compressão e criptografia autenticada em um fluxo de trabalho simples via linha de comando. Ele foi projetado para ambientes onde a eficiência de armazenamento e a segurança dos dados são prioridades — exatamente o perfil de um ISP que precisa fazer backups diários de bases de bilhetagem, configurações de equipamentos e logs.

O grande diferencial do Borg em relação a outras ferramentas de perfil similar (como o restic) é o modo append‑only nativo via SSH forçado, que permite implementar a camada de imutabilidade exigida pela regra 3‑2‑1‑1‑0 sem depender de armazenamento em nuvem com Object Lock — usando apenas um servidor Linux remoto com acesso SSH restrito. Essa característica, combinada com a capacidade de montar snapshots como sistemas de arquivos (FUSE), torna o Borg uma escolha robusta para ISPs que querem simplicidade operacional sem abrir mão da proteção contra ransomware.

2. Características técnicas

O funcionamento interno do Borg baseia‑se em chunking de conteúdo (divisão do fluxo de dados em blocos de tamanho variável, determinados pelo conteúdo, não por fronteiras de arquivos). Esse método, conhecido como content‑defined chunking, permite que pequenas alterações em arquivos grandes (ex.: inserção de uma linha no meio de um dump SQL de 500 MB) gerem apenas novos chunks para a parte modificada — o restante do arquivo é referenciado aos chunks já existentes no repositório. A economia de espaço em backups incrementais diários de bases MySQL de bilhetagem pode ultrapassar 90% em relação ao tamanho original.

• Deduplicação — entre arquivos, entre snapshots, entre servidores diferentes (se usarem o mesmo repositório).
• Criptografia autenticada — AES‑256‑CTR com HMAC‑SHA256 (modo repokey‑blake2 recomendado; a chave fica dentro do repositório, protegida por senha).
• Compressão — lz4 (rápida, padrão), zstd (mais compacta, mais CPU), zlib, lzma.
• Repositório local ou remoto via SSH — sem necessidade de agente externo; o próprio Borg gerencia a comunicação.
• Montagem FUSE — qualquer snapshot pode ser montado como um diretório virtual, permitindo navegação e recuperação seletiva sem extrair tudo.
• Modo append‑only — o servidor de destino aceita apenas gravação de novos dados; comandos de exclusão ou modificação de archives existentes são rejeitados (seção 6).

3. Instalação

# Debian/Ubuntu — servidor de origem (cliente)
apt install borgbackup

# Servidor de destino do backup (repositório remoto via SSH)
apt install borgbackup

A versão nos repositórios oficiais do Debian/Ubuntu costuma ser estável. Para funcionalidades mais recentes (ex.: --restrict-to-repository), verifique a documentação oficial — pode ser necessário instalar via pip ou compilar.

4. Inicializar repositório

# Repositório local
export BORG_PASSPHRASE="senha-forte"
borg init --encryption=repokey-blake2 /mnt/backup-disk/repo-radius

# Repositório remoto via SSH
borg init --encryption=repokey-blake2 \
    ssh://backup-user@servidor-remoto:22/./backups/repo-radius

repokey-blake2: a chave de criptografia é armazenada dentro do próprio repositório (protegida pela senha). Não perca a senha — sem ela, os dados são irrecuperáveis, mesmo com acesso físico ao disco.

5. Backup e listagem

# Dump do banco + backup dos arquivos, num único archive nomeado por data
mysqldump --single-transaction -u radius -p radius_db > /tmp/radius-dump.sql

borg create --stats --progress \
    ssh://backup-user@servidor-remoto:22/./backups/repo-radius::radius-{now:%Y-%m-%d} \
    /etc/freeradius /tmp/radius-dump.sql

rm /tmp/radius-dump.sql

# Listar archives (snapshots) existentes
borg list ssh://backup-user@servidor-remoto:22/./backups/repo-radius

# Ver conteúdo de um archive específico
borg list ::radius-2026-08-05

A flag --stats exibe um resumo após o backup: tamanho original, comprimido, deduplicado e número de chunks. Guarde esse output para monitoramento (seção 11).

6. Modo append‑only — defesa real contra ransomware

Esta é a característica mais importante do Borg para quem implementa a regra 3‑2‑1‑1‑0 sem depender de nuvem. O modo append‑only funciona restringindo o comando executado no servidor de destino via SSH: o cliente só consegue adicionar novos dados ao repositório, mas não pode apagar, sobrescrever ou modificar archives já existentes. Mesmo que o servidor de origem (cliente) seja completamente comprometido por ransomware, o atacante não consegue destruir os backups remotos usando as credenciais SSH do cliente — o servidor simplesmente rejeita qualquer comando de exclusão.

command="borg serve --append-only --restrict-to-path /backups/repo-radius",restrict ssh-ed25519 AAAA...chave-publica-do-cliente...

O command="..." força qualquer conexão SSH feita com essa chave a rodar somente o borg serve com as restrições especificadas — o cliente nunca ganha um shell interativo real no servidor de destino. --restrict-to-path impede acesso a qualquer coisa fora daquele repositório específico. Para versões mais recentes do Borg, prefira --restrict-to-repository /backups/repo-radius (mais seguro que --restrict-to-path).

7. Restauração — extract e mount

# Extração completa de um archive
mkdir /tmp/restauracao-teste && cd /tmp/restauracao-teste
borg extract ssh://backup-user@servidor-remoto:22/./backups/repo-radius::radius-2026-08-05

# Ou montar como sistema de arquivos (FUSE) pra navegar sem extrair tudo
mkdir /mnt/borg-mount
borg mount ::radius-2026-08-05 /mnt/borg-mount
ls /mnt/borg-mount/etc/freeradius
borg umount /mnt/borg-mount

8. Teste de restore automatizado (exigência LGPD)

A LGPD (Art. 46) exige medidas de recuperação; a regra 3‑2‑1‑1‑0 adiciona "0 erros" = testes periódicos. Script automatizado que restaura, compara e registra o resultado:

#!/bin/bash
# teste-restore-borg.sh
REPO="ssh://backup-user@servidor-remoto:22/./backups/repo-radius"
ARCHIVE="radius-$(date +%Y-%m-%d)"
RESTORE_DIR="/tmp/borg-restore-teste"

mkdir -p $RESTORE_DIR
borg extract $REPO::$ARCHIVE --target $RESTORE_DIR

# Validação básica — compara arquivo crítico
diff -r /etc/freeradius $RESTORE_DIR/etc/freeradius \
  && echo "RESTORE OK $(date)" >> /var/log/borg-test.log \
  || echo "FALHA RESTORE $(date)" >> /var/log/borg-test.log

rm -rf $RESTORE_DIR

9. Retenção (prune) e compactação

# Rodar a PARTIR DO SERVIDOR DE DESTINO, com chave sem append-only
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
    /backups/repo-radius

# Compactar espaço liberado pelo prune (roda depois, separado)
borg compact /backups/repo-radius

Por que no servidor de destino? O cliente que envia backups NUNCA deve ter permissão de exclusão — isso anularia a proteção append‑only. O prune é uma tarefa administrativa do lado do repositório, executada periodicamente (ex.: 1x por mês) por um operador que acessa diretamente o servidor de backup.

10. Verificação de integridade (check)

# Verificação estrutural (rápida)
borg check ssh://backup-user@servidor-remoto:22/./backups/repo-radius

# Verificação completa com checksum de cada chunk (mais lenta, mais segura)
borg check --verify-data ssh://backup-user@servidor-remoto:22/./backups/repo-radius

--verify-data confere o checksum de cada chunk, não só a estrutura do repositório — é o teste real de integridade, equivalente ao "0" da regra 3‑2‑1‑1‑0 quando combinado com um extract de teste periódico. Para repositórios grandes (>500 GB), agende esse check para horários de baixa utilização (ex.: domingo de madrugada).

11. Monitoramento e métricas

Para integrar com Zabbix, PRTG ou LibreNMS, utilize scripts que parseiam a saída do Borg. Exemplo de health check que verifica se o último backup foi concluído com sucesso:

#!/bin/bash
# check_borg_backup.sh
REPO="ssh://backup-user@servidor-remoto:22/./backups/repo-radius"
ULTIMO_ARCHIVE=$(borg list $REPO --short --last 1)
borg info $REPO::$ULTIMO_ARCHIVE | grep -q "This archive" \
  && echo "OK - Último backup: $ULTIMO_ARCHIVE" \
  || echo "CRITICAL - Falha no último backup"

Métricas úteis extraíveis do borg info: tamanho original, comprimido, deduplicado, número de arquivos. Essas métricas podem alimentar dashboards de tendência de crescimento do repositório.

12. Dimensionamento e performance

Exemplo prático para um ISP com 5 servidores (RADIUS, DNS, portal, etc.), cada um gerando ~500 MB de dados por backup full semanal e ~25 MB de incremento diário:

• Volume bruto por servidor/mês: 1 Full (500 MB) + 29 Incrementais (29×25 MB) = ~1.225 MB.
• Com deduplicação (80%): ~245 MB/servidor/mês → ~1.2 GB para 5 servidores/mês.
• Retenção de 3 meses: ~3.6 GB + overhead de metadados (~10%) → ~4 GB.
• I/O recomendado: HDD SATA 7200 RPM já atende bem; SSD traz ganho em borg check e prune.
• Rede: o backup incremental diário de 5 servidores gera ~125 MB de tráfego — um link de 10 Mbps já é suficiente, desde que fora do horário de pico.

13. Borg vs. restic vs. Bacula

14. Glossário

15. Referências

• Documentação oficial BorgBackup (borgbackup.readthedocs.io) — modo append‑only, restrição SSH, comandos.
• NIST SP 800-209 — Security Guidelines for Storage Infrastructure (recomendações de imutabilidade).
• CISA — #StopRansomware Guide (justificativa para armazenamento offline/imutável).
• Páginas relacionadas: Regra 3-2-1(-1-0), restic, Bacula, LGPD.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro. Comandos e configurações refletem o funcionamento real do software.