Como configurar backup com restic no VPS

Por que um backup no mesmo servidor não é um backup

O Restic é uma ferramenta de backup gratuita e de código aberto que envia snapshots criptografados e com deduplicação de seus arquivos para um repositório externo: um segundo VPS, uma máquina doméstica ou um armazenamento de objetos compatível com S3. Este guia realiza a configuração no Ubuntu 24.04, desde a instalação até um repositório via SFTP, o primeiro backup, um timer systemd noturno, uma política de retenção e o teste de restore para validar o processo. O destino deve ser outra máquina, pois uma cópia armazenada no mesmo servidor é perdida junto com o servidor.

Um diretório backup/ na máquina de origem protege você de apenas uma coisa: a exclusão acidental de um arquivo. Ele não sobrevive a uma falha de disco, pois estava naquele disco. Ele não sobrevive a um invasor com acesso root, pois o invasor excluirá as cópias primeiro. Ele não sobrevive a um erro de conta que resulte na remoção do próprio VPS. O datacenter menos eficiente do mundo faz piada sobre um tarball chamado backup_final_v2_REAL armazenado no mesmo array que os dados, e a piada é real porque muitos de nós já fizemos exatamente isso. O padrão é manter o backup fora da máquina, e o restic é a forma menos complexa de seguir essa regra.

Restic em quatro conceitos

Repository. O local onde o restic grava os dados. É um diretório no formato próprio do restic, composto por blobs criptografados, e apenas o restic pode lê-lo. Nunca edite o diretório manualmente; utilize comandos do restic e o endereço -r para interagir com ele.

Snapshot. Uma imagem dos arquivos em um ponto específico no tempo. Cada execução de backup cria um snapshot; cada snapshot pode ser restaurado individualmente e cada um funciona como uma cópia completa dos seus dados naquele momento.

Deduplication. O restic divide arquivos em chunks definidos pelo conteúdo e envia apenas os chunks que o repository ainda não possui. O primeiro backup envia tudo; as execuções seguintes enviam apenas o que mudou. Um snapshot diário de 20 GB com 50 MB de alteração custa cerca de 50 MB, por isso manter dezenas de snapshots é barato.

Encryption by default. Um repository restic é sempre criptografado (AES-256), e todos os comandos exigem a senha do repository. O host de backup ou o provedor de storage enxerga apenas blobs criptografados. A consequência direta: se perder a senha, os dados serão perdidos permanentemente por design. Guarde uma cópia da senha em um local que não seja este servidor. Este ponto é importante o suficiente para ser mencionado mais duas vezes abaixo.

Instalar restic no Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

No Ubuntu 24.04, este comando instala o restic 0.16.4, enquanto a versão atual do upstream é a 0.19.1. Essa diferença ocorre porque uma versão LTS (long term support) congela as versões de seus pacotes. Isso não é um problema aqui: a versão 0.16.4 executa todas as funções deste guia. Se você precisar da versão mais recente para obter melhorias de performance, baixe o binário oficial na página de releases do GitHub do projeto restic, descompacte com bunzip2 e instale em /usr/local/bin/restic; a instalação do restic consiste apenas nisso.

Criar o repositório em outro servidor via SFTP

Você precisa de uma máquina de destino: um segundo VPS pequeno é a solução comum, mas qualquer máquina com um servidor SSH e espaço em disco funciona. O Restic utiliza SFTP (transferência de arquivos via SSH), portanto o host de backup não precisa de nada instalado. Neste guia, o host de backup é 10.0.0.12 com um usuário chamado restic. Não nomeie esse usuário como backup: o Ubuntu e o Debian instalam uma conta de sistema reservada chamada backup (uid 34, sem shell de login) em todas as instalações, o que faz o adduser backup falhar e o ssh backup@... ser salvo em nologin.

O job noturno será executado como root no servidor de origem, portanto o root precisa de login por chave no host de backup. Crie uma chave dedicada sem passphrase, pois não haverá ninguém para digitá-la às 3h da manhã, e copie-a:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Se você não tem experiência com chaves, básico de gerenciamento de chaves SSH explica o modelo, as permissões e como revogar uma chave posteriormente.

Em seguida, a senha do repositório. Gere uma senha forte em um arquivo acessível apenas pelo root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Agora copie essa senha para seu gerenciador de senhas antes de prosseguir. Se este VPS falhar, o repositório junto com esta senha restaura tudo; o repositório sem a senha não restaura nada.

Inicialize o repositório:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

O destino alternativo é o armazenamento de objetos compatível com S3, que é a escolha ideal se você não quiser manter uma segunda máquina. Qualquer bucket compatível com S3 funciona da mesma forma; apenas o endereço e duas variáveis de credenciais mudam:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Tudo após init é idêntico para ambos os destinos. O restante deste guia mostra o endereço SFTP; substitua pelo seu.

O primeiro backup, com exclusões

Faça backup apenas dos dados que não podem ser reinstalados, não do filesystem inteiro. O sistema operacional é restaurado com uma reinstalação; suas configurações e dados não. Para um VPS típico, isso significa /etc, /home, e onde quer que suas aplicações guardem estado, como /srv ou /var/www. Exclua caches, pois são grandes, mudam diariamente e são reconstruídos automaticamente:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

A primeira execução faz o upload de tudo, portanto demora. Execute o mesmo comando novamente e ele terminará em segundos, relatando poucos arquivos alterados e poucos MiB adicionados, pois a deduplicação faz o upload apenas de novos chunks. Liste o que você tem:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Cada snapshot mostra um ID, um horário e os caminhos contidos. Esses IDs são o que você utiliza para restaurar.

Execuções diárias com um timer do systemd

Digitar o endereço do repositório em cada comando é cansativo, e um backup feito manualmente deixa de ser executado em menos de um mês. A solução para ambos os problemas é um script e um timer. O script define as duas variáveis de ambiente que o restic utiliza, RESTIC_REPOSITORY e RESTIC_PASSWORD_FILE, mantendo os comandos internos curtos:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

As linhas forget e check são explicadas nas próximas duas seções. Sobre o agendamento: um serviço oneshot que executa o script e um timer que o dispara às 03:00 todas as noites. O timer é preferível ao cron neste caso porque o log de execução vai para o journal, e o Persistent=true executa um backup pendente assim que o servidor volta após uma queda.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Habilite o timer e execute o serviço manualmente uma vez para verificar o funcionamento:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

O comando systemctl list-timers mostra quando será a próxima execução. Você também pode gerar o par de arquivos de unit em vez de digitá-los:

O padrão completo por trás desses dois arquivos, incluindo a sintaxe de calendário e as diretivas de hardening que um serviço pode ter, está em executar um programa como um serviço systemd em uma VPS.

Um backup é apenas um boato até que você o restaure

Considere essa frase como um mandamento. Um job de backup que termina com sucesso todas as noites prova apenas que o job foi executado; não prova que seus dados podem ser recuperados. Dois testes eliminam essa incerteza.

Primeiro, o restic check, que o script já executa todas as noites. Ele verifica a estrutura do repositório e o index, garantindo que corrupções silenciosas no host de backup sejam detectadas na noite seguinte, em vez de no dia da restauração. Uma vez por mês, execute a versão mais profunda, que baixa e verifica criptograficamente um décimo aleatório dos dados reais:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Como o subconjunto é aleatório a cada execução, os testes mensais percorrem todo o repositório sem a necessidade de um download completo.

Segundo, o teste de restauração. Ainda no shell root do passo anterior, restaure um diretório real do snapshot mais recente para um local temporário e compare-o com os arquivos ativos:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Se o diff não imprimir nada, significa que cada byte foi recuperado de forma idêntica, que é a única evidência válida. Delete o /srv/restore-drill depois. Realize este teste mensalmente e, uma ou duas vezes por ano, faça a versão completa: restaure o snapshot mais recente inteiro em um VPS temporário e verifique se sua aplicação inicia corretamente a partir dele. No dia em que você precisar que isso funcione sob pressão, você quer que seja uma rotina que você já executou.

Retenção: forget e prune

Sem uma política, os snapshots acumulam indefinidamente e o repositório cresce continuamente. A linha forget do script aplica uma política todas as noites: --keep-daily 7 mantém um snapshot por dia para os últimos sete dias, --keep-weekly 4 um por semana durante quatro semanas, e --keep-monthly 6 um por mês durante seis meses. Tudo o que não estiver protegido por uma regra é descartado.

O comando forget sozinho apenas remove os registros dos snapshots; os chunks de dados permanecem no repositório até que algo os delete. É isso que o --prune faz: ele identifica chunks sem referências de snapshots restantes e os deleta, liberando o espaço em disco. O prune realiza o trabalho real no repositório; por isso, em repositórios grandes, alguns usuários executam o forget diariamente e o --prune semanalmente; para tamanhos típicos de VPS, a execução diária é suficiente.

Databases: faça o dump primeiro, depois o backup do dump

O restic copia arquivos enquanto os lê, e um banco de dados escreve em seus arquivos continuamente. Um arquivo de banco de dados ativo capturado durante uma escrita será restaurado como um banco corrompido, pois a cópia mistura páginas de antes e depois da escrita. A solução é padrão: faça o motor do banco de dados gerar um export consistente para um arquivo e, em seguida, deixe o restic fazer o backup desse arquivo.

Para PostgreSQL, adicione uma linha de dump no topo de restic-backup.sh, antes do comando restic backup, e inclua o diretório do dump nos caminhos de backup:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

O mysqldump desempenha a mesma função para MariaDB e MySQL. Para um exemplo prático de todo o padrão, a seção de backup do Nextcloud ativa o modo de manutenção, faz o dump do Postgres e copia os arquivos como um conjunto consistente, exatamente o conjunto que o restic deve remover da máquina todas as noites. O SQLite segue a mesma lógica com uma abordagem mais simples: o guia do Vaultwarden para o container por alguns segundos para fazer uma cópia fria de db.sqlite3, e esse arquivo é o que o restic envia para fora do servidor.

FAQ

Os backups do restic são criptografados?

Sim, sempre. Todo repositório restic é criptografado com AES-256. Não existe modo sem criptografia e cada comando exige a senha do repositório. A máquina ou o provedor que armazena o repositório possui apenas blobs criptografados, portanto, um host de backup comprometido não expõe seus arquivos. A regra é absoluta: sem a senha, ninguém consegue recuperar os dados; por isso, guarde uma cópia dela fora do servidor.

O restic faz backups incrementais?

Cada snapshot do restic funciona como um backup completo, mas consome apenas o armazenamento incremental. O restic divide arquivos em chunks e faz o upload apenas dos chunks que o repositório ainda não possui; assim, uma execução diária transfere apenas o que mudou no dia. Diferente de esquemas incrementais tradicionais, não existe uma cadeia para reprocessar: qualquer snapshot restaura os dados diretamente e deletar um snapshot antigo nunca corrompe um mais recente.

Como eu restauro arquivos de um backup do restic?

Execute restic snapshots para encontrar o ID do snapshot, depois restic restore <id> --target /some/empty/dir para restaurá-lo, adicionando --include /path para restaurar apenas uma parte. O comando latest funciona no lugar de um ID. O restic recria a estrutura de diretórios original dentro do destino, então restaurar /etc/ssh resultará em /some/empty/dir/etc/ssh. Pratique isso antes de precisar, pois um backup não testado é apenas um rumor.

Com que frequência devo executar o restic backup?

Execuções diárias são o mínimo recomendado para um servidor, e a deduplicação torna o processo barato: cada execução faz o upload apenas dos chunks que mudaram desde a última. Dados que mudam rápido, ou que seriam críticos perder mesmo por um dia, podem ser executados a cada poucas horas com o mesmo padrão de timer. A frequência é a parte fácil; execute também o restic check regularmente e um teste de restauração mensalmente, pois cronograma sem verificação é falsa segurança.

O que acontece se eu perder minha senha do repositório restic?

Os backups tornam-se irrecuperáveis. A criptografia do restic não possui backdoor nem opção de reset, portanto a senha é tão importante quanto os próprios backups. Mantenha uma cópia no seu gerenciador de senhas e em qualquer outro local durável que não seja o servidor de backup. Enquanto você ainda tiver acesso, o comando restic key add pode registrar uma segunda senha para o mesmo repositório, fornecendo uma reserva.