Backups Imutáveis com BorgBackup e Restic: Porque o Acesso Root Não Deve Permitir Apagar Backups

A Falha Crítica nos Backups Tradicionais em Servidores Linux

Certamente já ouviste falar da regra 3-2-1 para cópias de segurança: manter três cópias dos teus dados, em dois suportes diferentes, com pelo menos uma cópia fora do servidor principal. Contudo, em quase todos os ataques modernos de ransomware contra empresas, as vítimas deparam-se com um cenário devastador: os atacantes apagaram todas as cópias de segurança horas antes de encriptarem a base de dados principal.

O problema reside na confiança simétrica. Quando o teu servidor de produção Debian tem um script automático que se liga a um servidor remoto de armazenamento com credenciais que têm permissão de apagar ficheiros, esse script é uma bomba-relógio. No segundo em que um invasor obtém privilégios de root na tua máquina web, ele inspeciona o teu histórico ou o ficheiro /etc/crontab, descobre as chaves do armazenamento remoto e corre um comando para destruir todos os backups anteriores.

CONFIANÇA SIMÉTRICA VULNERÁVEL VS. REPOSITÓRIO APPEND-ONLY

• CENÁRIO VULNERÁVEL (ACESSO TOTAL À ESCRITA E APAGAMENTO): [Servidor de Produção] → Invasor Root Obtém as Credenciais
• COMANDO DE APAGAMENTO ENVIADO
• Servidor de Backups: Histórico Destruído (Perda Irrecuperável)
• CENÁRIO BLINDADO (MODO APENAS-ACRESCENTO / APPEND-ONLY): [Servidor de Produção] → Apenas Consegue ENVIAR Novos Blocos
• Invasor Tenta Apagar Cópias Antigas?
• RESPOSTA: 403 FORBIDDEN
• Repositório Imutável: Os Teus Snapshots Históricos Ficam Intactos!

Na Webxtek, desenhamos arquiteturas de dados partindo do princípio de que qualquer máquina de produção pode ser alvo de uma intrusão. Ao separares a capacidade de gravar cópias da capacidade de as destruir através da nossa consultoria técnica e soluções de alojamento gerido, garantias a sobrevivência do teu negócio.

Fatiamento Dinâmico por Conteúdo: Como o Borg e o Restic Poupam Espaço

As ferramentas clássicas como o tar ou o rsync trabalham com ficheiros inteiros ou blocos com tamanhos fixos. Se tiveres uma base de dados com 40GB e alterares alguns registos no início do ficheiro, as ferramentas antigas acabam por regravar e transmitir dezenas de gigabytes pela rede.

O BorgBackup e o Restic resolvem este desafio através de fatiamento dinâmico baseado no conteúdo (Content-Defined Chunking ou FastCDC). O ficheiro é dividido em blocos cujas fronteiras são determinadas por uma janela deslizante inteligente.

FATIAMENTO BASEADO NO CONTEÚDO (FASTCDC)

• VERSÃO ORIGINAL DO FICHEIRO: [ Bloco A: 4MB ] [ Bloco B: 3.2MB ] [ Bloco C: 5.1MB ] [ Bloco D: 2.8MB ]
• NOVA VERSÃO (Adicionaste 300KB entre o Bloco B e C): [ Bloco A: 4MB ] [ Bloco B: 3.2MB ] [ Bloco E: 300KB ] [ Bloco C: 5.1MB ] [ Bloco D: 2.8MB ]
• (Já Existe: Não Envia Nada) (Já Existe: Não Envia Nada)

Apenas o Bloco E (os novos 300KB) é comprimido, encriptado localmente com cifras autenticadas (como AES-256 ou ChaCha20-Poly1305) e enviado para o teu repositório. Um backup diário que antes demorava horas a transferir passa a demorar apenas alguns segundos.

Configurar o BorgBackup em Modo Append-Only com SSH Forçado

O BorgBackup traz suporte nativo para repositórios imutáveis. Ao combinares comandos forçados no ficheiro authorized_keys do teu servidor de destino com a opção --append-only, o teu servidor de produção fica fisicamente impossibilitado de destruir ficheiros.

No servidor exclusivo de backups, cria um utilizador e edita o /home/borgbackup/.ssh/authorized_keys:

command="borg serve --append-only --restrict-to-repository /var/backups/repositorio-prod",no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... chave-cliente

No teu servidor de produção, inicia o repositório e executa a tua rotina de salvaguarda:

# Define a frase-passe segura do repositório
export BORG_PASSPHRASE="tua-frase-passe-criptografica-muito-segura"
export BORG_REPO="borgbackup@servidor-backups.interno:/var/backups/repositorio-prod"

# Inicia o repositório com encriptação autenticada Blake2
borg init --encryption=repokey-blake2

# Cria um novo snapshot de produção
borg create --verbose --stats \
  ::"prod-{now:%Y-%m-%d_%H:%M}" \
  /etc /var/www /var/lib/postgresql/data

PROTEÇÃO CONTRA DESTRUIÇÃO NO BORGBACKUP

• Invasor com Acesso Root no Servidor Web
• Tenta Executar: borg delete ::prod-2026-10-18
• Comando SSH Forçado no Servidor de Backups
• Interceta o Pedido
• Deteta Tentativa de Apagar num Repositório Append-Only
• Bloqueia o Pedido e Regista Alerta de Segurança: (O Teu Histórico Permanece Seguro)

A limpeza de cópias antigas (pruning) é realizada por uma rotina interna agendada diretamente no servidor de backups—o servidor de produção nunca tem permissão para disparar este comando.

Servidor REST do Restic: Imutabilidade Nativa por HTTP

Se preferes uma solução fácil de gerir em ambientes distribuídos, o Restic combinado com o restic-server (disponível no GitHub) oferece uma velocidade extraordinária com proteção append-only nativa por HTTP.

Ao arrancares o servidor com o parâmetro --append-only, a API aceita novos dados mas rejeita qualquer chamada DELETE:

# Inicia o servidor Restic com proteção imutável ativa
./restic-server --path /mnt/disco-backups --append-only --tls-cert cert.pem --tls-key key.pem

No teu servidor de produção, configuras o Restic para guardar os dados na API:

# Variáveis de ligação ao repositório
export RESTIC_REPOSITORY="rest:https://utilizador:password@cofre.interno:8000/"
export RESTIC_PASSWORD="chave-de-encriptacao-dos-blocos"

# Cria um snapshot dos teus ficheiros de configuração e bases de dados
restic backup /var/www /etc/nginx --exclude="*.log"

# Verifica se o repositório está íntegro
restic check

Se alguém entrar no teu servidor e tentar forçar a eliminação de dados antigos (restic forget --prune), a resposta do cofre é imediata: HTTP 403 Forbidden.

Testes Automáticos de Restauro e Proteção Físicamente Isolada

Um backup que nunca foi restaurado é apenas uma esperança, não é uma certeza. De acordo com as normas de segurança da OWASP, deves testar o restauro de ficheiros regularmente montando o teu repositório num ambiente de teste:

# Monta o snapshot mais recente como sistema de ficheiros só de leitura
restic mount /mnt/restauro-teste &
ls -la /mnt/restauro-teste/snapshots/latest/var/www

Para garantir imunidade total contra ataques internos ou falhas catastróficas no datacenter, sincroniza estas cópias imutáveis para um segundo destino físico ou armazenamento com Object Lock.

Ao aliares esta disciplina a serviços profissionais de manutenção contínua, garantes que a tua empresa consegue recuperar qualquer sistema em minutos, sem nunca ceder a chantagens de cibercriminosos.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como provedores de cloud computing e iaas e cibersegurança b2b e inteligência corporativa. Quando alinhas a tua estrutura através de alojamento gerido para websites e aplicações e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.