Cópias de segurança com restic

Módulo 8: Cópias de segurança e monitorização · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: No final desta lição, será capaz de criar com o restic cópias de segurança cifradas para um armazenamento fora do seu servidor, limpar versões antigas segundo um esquema de retenção, verificar a cópia de segurança e repor ficheiros, e pôr tudo isto a funcionar automaticamente.

Conceitos-chave: restic, repositório, init, palavra-passe (ficheiro), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, desduplicação, append-only, temporizador systemd

Porquê o restic?

Existem muitos programas de cópias de segurança. O restic é uma boa escolha para um servidor próprio, porque:

• cifra tudo antes de sair do servidor; o armazenamento só vê blocos ilegíveis;
• desduplica: um ficheiro que não foi alterado não é guardado novamente, pelo que as cópias de segurança diárias ocupam pouco espaço;
• suporta muitos tipos de armazenamento: uma pasta, outro servidor via SFTP, armazenamento compatível com S3, um rest-server próprio;
• é um único programa, disponível nos repositórios de pacotes do Debian e do Ubuntu (apt install restic).

Uma alternativa com características semelhantes é o BorgBackup. Os princípios desta lição aplicam-se também a ele.

Os conceitos

• Repositório: o local onde o restic guarda as cópias de segurança. Fica sempre fora do servidor de que está a fazer a cópia de segurança.
• Snapshot: uma cópia de segurança num determinado momento. (Atenção: não é o mesmo que o snapshot do seu fornecedor referido na lição 8.1.)
• Palavra-passe: cada repositório tem uma palavra-passe com a qual tudo é cifrado. A documentação do restic é clara sobre isto: quem perder a palavra-passe perde os dados de forma irrecuperável.

Criar um repositório

Suponha que tem um servidor de armazenamento backup.example.net ao qual acede via SFTP com uma chave, como utilizador web1. Crie primeiro um ficheiro de palavra-passe no servidor (e guarde a mesma palavra-passe no seu gestor de palavras-passe, lição 8.1):

root@web1:~# install -m 600 /dev/null /root/.restic-wachtwoord
root@web1:~# openssl rand -base64 32 > /root/.restic-wachtwoord
root@web1:~# export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
root@web1:~# export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
root@web1:~# restic init
created restic repository 5f1a9c2e3b at sftp:web1@backup.example.net:/srv/restic/web1

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Com as variáveis de ambiente RESTIC_REPOSITORY e RESTIC_PASSWORD_FILE, não precisa de escrever as opções -r e --password-file de cada vez.

Criar uma cópia de segurança

Primeiro o dump da base de dados (lição 8.1), depois a cópia de segurança:

root@web1:~# restic backup /etc /var/www /opt /var/backups/db \
    --exclude /var/www/*/cache --tag dagelijks
repository 5f1a9c2e opened (version 2, compression level auto)
...
Files:        8421 new,     0 changed,     0 unmodified
Dirs:         1203 new,     0 changed,     0 unmodified
Added to the repository: 612.338 MiB (402.117 MiB stored)

processed 8421 files, 1.204 GiB in 0:41
snapshot 3c7e91d4 saved

No dia seguinte é muito mais rápido: só é incluído o que mudou.

root@web1:~# restic snapshots
ID        Time                 Host  Tags       Paths
-----------------------------------------------------------------------
3c7e91d4  2026-11-08 03:10:02  web1  dagelijks  /etc /opt /var/backups/db /var/www
a18f0b77  2026-11-09 03:10:05  web1  dagelijks  /etc /opt /var/backups/db /var/www
-----------------------------------------------------------------------
2 snapshots

Limpar: forget e prune

Um snapshot novo por dia significa 365 snapshots ao fim de um ano. Com forget define quais guarda, através de um esquema de retenção:

root@web1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

O esquema funciona assim:

• --keep-daily 7: considera os últimos sete dias em que existe um snapshot e mantém, por dia, o mais recente;
• --keep-weekly 4: o mesmo para as últimas quatro semanas (de segunda-feira a domingo);
• --keep-monthly 6: o mesmo para os últimos seis meses.

Um snapshot é mantido se cumprir pelo menos uma das regras. Tudo o que não cumpre nenhuma regra é esquecido. Experimente um esquema novo primeiro com --dry-run: assim vê o que seria removido sem que nada seja alterado.

Diferença importante: o forget remove apenas a referência a um snapshot. Os dados permanecem no repositório até que o prune limpe os blocos que já não são usados por nenhum snapshot. A opção --prune no forget faz isso de uma só vez. O prune demora e bloqueia o repositório; por isso, não o agende ao mesmo tempo que a sua cópia de segurança.

Verificar: check

Uma cópia de segurança que se danifica silenciosamente só é detetada no momento da reposição. Peça ao restic que verifique o repositório regularmente:

root@web1:~# restic check
...
no errors were found
root@web1:~# restic check --read-data-subset=5%

O check simples verifica a estrutura. Com --read-data-subset, lê efetivamente uma parte dos dados e verifica o conteúdo. Faça isto, por exemplo, semanalmente com uma pequena percentagem; assim, ao fim de algum tempo, tudo terá sido lido pelo menos uma vez.

Repor: restore e mount

Reponha sempre para uma pasta separada, nunca diretamente por cima do original:

root@web1:~# restic restore latest --target /tmp/terug --include /etc/nginx
restoring snapshot a18f0b77 of [/etc /opt /var/backups/db /var/www] at 2026-11-09 03:10:05 ...
Summary: Restored 41 files/dirs (88.104 KiB) in 0:00
root@web1:~# diff -r /tmp/terug/etc/nginx /etc/nginx && echo gelijk
gelijk

latest é o snapshot mais recente; também pode usar um ID (restic restore 3c7e91d4 ...). Com restic mount /mnt/restic (requer FUSE), vê todos os snapshots como pastas e pode explorá-los e copiar ficheiros individuais. Para parar, prima Ctrl+C.

Uma base de dados repõe-se recuperando o dump e importando-o, por exemplo gunzip < alles.sql.gz | mariadb.

Automaticamente, todas as noites

Crie um script e um temporizador systemd (lição 6.3). O script:

#!/bin/sh
# /usr/local/sbin/backup.sh
set -eu
export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles.sql.gz
restic backup /etc /var/www /opt /var/backups/db --tag dagelijks
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Um .service com Type=oneshot e ExecStart=/usr/local/sbin/backup.sh, e um .timer com OnCalendar=*-*-* 03:10:00 e Persistent=true. set -eu faz com que o script pare no primeiro erro, para que o systemd considere a execução como falhada. Associe-lhe uma notificação (lição 8.3); caso contrário, não dará por uma cópia de segurança falhada.

Contra ransomware: append-only

No script acima, o próprio servidor também pode apagar a cópia de segurança (forget e prune). Se um atacante tomar conta do servidor, também o pode fazer. Há duas formas de o evitar:

• rest-server em modo append-only: no servidor de armazenamento, executa o rest-server do próprio restic com a opção --append-only. O servidor web pode então acrescentar cópias de segurança, mas não pode apagar nada. A limpeza (forget --prune) é feita a partir de outra máquina, bem protegida e com permissões completas.
• Armazenamento com controlo de versões ou bloqueio de objetos num fornecedor S3, para que os objetos eliminados ainda possam ser recuperados durante algum tempo.

Atenção a uma armadilha subtil que a própria documentação do restic menciona: um atacante que acrescente snapshots falsos pode levar um esquema como --keep-weekly a esquecer snapshots verdadeiros. Com --keep-within (por exemplo --keep-within 30d), tudo o que pertence a esse período é mantido, falso ou verdadeiro.

Resumo

• O restic cifra, desduplica e consegue guardar em muitos tipos de armazenamento fora do seu servidor; perder a palavra-passe é perder tudo.
• init cria o repositório, backup cria um snapshot, snapshots mostra-os.
• forget com --keep-* define o que guarda; só prune (ou --prune) limpa realmente os dados. Experimente com --dry-run.
• check (com --read-data-subset) verifica, restore --target repõe para uma pasta separada, mount permite explorar.
• Automatize com um temporizador e uma notificação, e mantenha pelo menos um repositório fora do alcance do servidor (append-only).

Questionário

Exercício

Exercício Z8.2: O que resta depois do forget? No ficheiro de exemplo restic-snapshots.txt encontra uma lista de snapshots e um esquema de retenção. Determine que snapshots restam depois de restic forget com esse esquema. O programa compara com a chave fixa.

Exercício O8.2: Um teste de reposição. No seu próprio servidor, crie um repositório restic fora do servidor, faça uma cópia de segurança de /etc e dos seus dados, e reponha uma pasta para /tmp/terug. Compare com diff, anote quanto tempo demorou e indique onde estão guardados, fora do servidor, a sua palavra-passe e os dados de acesso ao armazenamento.

Para saber mais

• Estratégia de cópias de segurança: a regra 3-2-1 para a sua própria empresa
• Documentação do restic, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Documentação do restic, Removing backup snapshots (forget e prune): https://restic.readthedocs.io/en/stable/060_forget.html
• Documentação do restic, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server
• Snapshots e cópias de segurança do seu VPS
• VPS: do primeiro início de sessão a um servidor seguro 8.1: Cópias de segurança com restic para outro local
• VPS: do primeiro início de sessão a um servidor seguro 8.2: Incluir corretamente bases de dados e volumes Docker na cópia de segurança