Backups de servidores com Restic e S3: menos custo, mais confiança

Este artigo foi escrito com a ajuda de IA.

Fazer backup de um servidor não deveria significar replicar discos inteiros, pagar por dados repetidos ou confiar que um rsync local salvará o dia. Uma combinação bastante pragmática para servidores Linux é Restic + armazenamento de objetos compatível com S3: Amazon S3 quando a infraestrutura já está na AWS, ou Backblaze B2 quando o custo de armazenamento é a prioridade.

O Restic cuida do que é difícil no cliente: criptografia, deduplicação, snapshots e restauração. O bucket cuida da durabilidade e de manter os dados fora do servidor que pode falhar.

O que torna essa combinação interessante

O primeiro backup envia todos os blocos necessários. Nos seguintes, o Restic compara o estado atual com o snapshot anterior, reutiliza os dados que já existem no repositório e envia apenas conteúdo novo. Ele ainda cria um snapshot por execução, o que permite restaurar um diretório como ele estava em uma data específica.

Isso muda bastante a conta. Se um servidor tem 200 GB, mas apenas 2 GB de bancos, uploads ou configurações mudam por dia, não faz sentido transferir 200 GB diariamente. O volume processado pelo comando pode continuar alto — afinal, os arquivos precisam ser examinados —, mas o volume efetivamente transferido tende a acompanhar as mudanças. A deduplicação também funciona entre snapshots e pode beneficiar hosts diferentes no mesmo repositório, desde que isso faça sentido para a política de isolamento da equipe.

Há outro ganho importante: o repositório é criptografado pelo próprio Restic antes do envio. O provedor de objetos armazena blobs cifrados; a senha do repositório continua sendo essencial para recuperar os dados.

S3, Backblaze B2 e custo

Amazon S3 é uma escolha natural quando os servidores, permissões e observabilidade já vivem na AWS. O ponto de atenção é que o custo não é só GB/mês: requests, armazenamento de versões, transferência e a classe de armazenamento também entram na conta.

O Backblaze B2 costuma ser atraente para backups por ter uma estrutura de preço simples para armazenamento. Para o Restic, a recomendação atual da própria documentação é usar a API compatível com S3 do B2, em vez do backend B2 nativo. Ao seguir esse caminho, crie uma chave de aplicação S3 limitada ao bucket de backup e use o endpoint da região do bucket.

Em B2, configure também uma regra de ciclo de vida para manter somente a última versão de cada arquivo. O backend S3 do Restic marca objetos não necessários como ocultos; sem uma regra de ciclo de vida, versões ocultas podem continuar ocupando espaço e diluir a economia esperada.

Não existe um provedor universalmente mais barato. Para decidir, modele pelo menos:

dados iniciais e crescimento mensal;
taxa real de mudança diária;
retenção desejada;
custo de requisições e de recuperação;
transferência para fora do provedor em um cenário de desastre.

O melhor custo é o custo total de um backup que você consegue restaurar, não apenas o menor valor por GB.

Configuração: credenciais fora do script

Comece criando um bucket exclusivo, por exemplo meu-servidor-restic. A chave deve ter apenas as permissões necessárias naquele bucket; não use credenciais administrativas da conta.

Guarde as variáveis em um arquivo que só o usuário de backup consegue ler, como /etc/restic/env com permissão 0600:

export RESTIC_REPOSITORY="s3:https://s3.<regiao>.backblazeb2.com/meu-servidor-restic"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
export AWS_ACCESS_KEY_ID="<chave-s3-do-bucket>"
export AWS_SECRET_ACCESS_KEY="<segredo-da-chave-s3>"
export AWS_DEFAULT_REGION="<regiao-do-bucket>"

Para Amazon S3, o repositório usa o endpoint da região, no formato abaixo:

export RESTIC_REPOSITORY="s3:s3.us-east-1.amazonaws.com/meu-servidor-restic"

Em um serviço S3 compatível, s3:https://endpoint/bucket é o formato mais explícito. Se o provedor exigir, informe a região com AWS_DEFAULT_REGION ou -o s3.region="...". Não coloque segredos no crontab, no repositório Git ou em uma unit que qualquer usuário possa ler.

Depois inicialize o repositório uma única vez:

source /etc/restic/env
restic init

Perder a senha do repositório significa perder a capacidade de restaurar os dados. Mantenha essa senha em um gerenciador de segredos e pense em um procedimento de recuperação que não dependa de uma única pessoa.

Um backup diário útil

O exemplo abaixo evita pseudo-filesystems e diretórios que não deveriam ser copiados como arquivos. Adapte a lista ao papel do servidor: uma aplicação web, por exemplo, normalmente precisa de configurações, uploads e um dump consistente do banco — não de um backup cego de todo /.

#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/env

restic backup \
  --tag server:app-01 \
  --tag daily \
  --exclude-file=/etc/restic/excludes.txt \
  --one-file-system \
  --skip-if-unchanged \
  /etc /home /srv /var/www /var/backups

Um excludes.txt inicial pode conter:

/proc
/sys
/dev
/run
/tmp
/var/cache
/var/tmp
/var/lib/docker/overlay2

--skip-if-unchanged evita criar um novo snapshot quando nada mudou. Isso não substitui a deduplicação: ela já evita retransferir dados existentes; a opção apenas impede snapshots idênticos de poluírem o histórico.

Para bancos de dados, gere primeiro um dump transacional ou consistente em /var/backups e inclua esse arquivo no backup. Copiar os arquivos internos de um banco em execução não é, por si só, garantia de restauração consistente.

Retenção, limpeza e verificação

Backup sem retenção vira acúmulo; retenção sem limpeza não reduz o bucket. Uma política simples pode manter os últimos snapshots diários, semanais, mensais e anuais:

restic forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --keep-yearly 3

Agende verificações periódicas:

restic check
restic snapshots

E, principalmente, teste a restauração. Um exercício mínimo é restaurar um snapshot em um diretório temporário e validar um arquivo importante:

restic restore latest --target /tmp/restore-test

Em produção, vale ensaiar a recuperação em outra máquina e documentar: onde as credenciais ficam, como instalar o Restic, como escolher um snapshot e como recolocar serviço e dados no ar.

Operação prática

Rode o script por systemd timer ou cron, registre a saída e alerte quando o processo falhar. A execução deve ser serializada por host para evitar concorrência desnecessária no mesmo repositório. Também vale limitar banda e I/O quando o backup disputa recursos com tráfego de produção.

O resultado é um fluxo simples: dados alterados entram no bucket de forma criptografada, dados repetidos não são enviados de novo, snapshots antigos expiram conforme a política e a restauração é tratada como parte da rotina — não como uma esperança durante um incidente.