Backup con restic

Modulo 8: Backup e monitoraggio · Tempo di lettura: 12 minuti

Obiettivo della lezione: Al termine di questa lezione saprà creare con restic backup cifrati su uno storage esterno al Suo server, eliminare le versioni vecchie secondo una politica di conservazione, verificare il backup, ripristinare file e far funzionare il tutto in automatico.

Concetti chiave: restic, repository, init, password (file della password), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, deduplicazione, append-only, timer systemd

Perché restic?

Esistono molti programmi di backup. restic è una buona scelta per un server proprio, perché:

• cifra tutto prima che lasci il server; lo storage vede solo blocchi illeggibili;
• deduplica: un file che non è cambiato non viene salvato di nuovo, quindi i backup giornalieri occupano poco spazio;
• supporta molti tipi di storage: una cartella, un altro server tramite SFTP, uno storage compatibile S3, un proprio rest-server;
• è un unico programma, presente nei repository dei pacchetti di Debian e Ubuntu (apt install restic).

Un'alternativa con caratteristiche simili è BorgBackup. I principi di questa lezione valgono anche lì.

I concetti

• Repository: il luogo in cui restic salva i backup. Sempre al di fuori del server di cui fa il backup.
• Snapshot: un singolo backup in un singolo momento. (Attenzione: è una cosa diversa dallo snapshot del Suo provider visto nella lezione 8.1.)
• Password: ogni repository ha una password con cui viene cifrato tutto. La documentazione di restic è chiara in merito: chi perde la password perde i dati in modo irrecuperabile.

Creare un repository

Supponiamo che Lei disponga di un server di storage backup.example.net a cui può accedere tramite SFTP con una chiave, come utente web1. Crei prima un file con la password sul server (e conservi la stessa password nel Suo password manager, lezione 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.

Con le variabili d'ambiente RESTIC_REPOSITORY e RESTIC_PASSWORD_FILE non deve digitare ogni volta le opzioni -r e --password-file.

Creare un backup

Prima il dump del database (lezione 8.1), poi il backup:

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

Il giorno dopo è molto più veloce: viene incluso solo ciò che è cambiato.

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

Fare pulizia: forget e prune

Uno snapshot in più ogni giorno significa 365 snapshot dopo un anno. Con forget stabilisce quali conservare, tramite una politica di conservazione:

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

Ecco come funziona la politica:

• --keep-daily 7: considera gli ultimi sette giorni in cui esiste uno snapshot e per ogni giorno conserva il più recente;
• --keep-weekly 4: lo stesso per le ultime quattro settimane (da lunedì a domenica compresa);
• --keep-monthly 6: lo stesso per gli ultimi sei mesi.

Uno snapshot viene conservato se soddisfa almeno una delle regole. Tutto ciò che non soddisfa nessuna regola viene dimenticato. Provi prima una nuova politica con --dry-run: così vede che cosa verrebbe rimosso senza che cambi nulla.

Differenza importante: forget rimuove solo il riferimento a uno snapshot. I dati restano nel repository finché prune non elimina i blocchi che non sono più usati da alcuno snapshot. L'opzione --prune di forget fa entrambe le cose in un colpo solo. Prune richiede tempo e blocca il repository; per questo non lo pianifichi in contemporanea con il backup.

Verificare: check

Un backup che si danneggia senza dare segnali lo scopre solo al momento del ripristino. Faccia verificare regolarmente il repository da restic:

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

Un semplice check verifica la struttura. Con --read-data-subset legge effettivamente anche una parte dei dati e ne verifica il contenuto. Lo faccia per esempio ogni settimana con qualche punto percentuale; così, dopo un certo tempo, tutto sarà stato letto almeno una volta.

Ripristinare: restore e mount

Ripristini in una cartella separata, mai direttamente sopra l'originale:

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 è lo snapshot più recente; può anche usare un ID (restic restore 3c7e91d4 ...). Con restic mount /mnt/restic (richiede FUSE) vede tutti gli snapshot come cartelle e può navigare e copiare singoli file. Per uscire usi Ctrl+C.

Un database si ripristina recuperando il dump e importandolo, per esempio gunzip < alles.sql.gz | mariadb.

In automatico, ogni notte

Crei uno script e un timer systemd (lezione 6.3). Lo 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

Un .service con Type=oneshot e ExecStart=/usr/local/sbin/backup.sh, e un .timer con OnCalendar=*-*-* 03:10:00 e Persistent=true. set -eu fa sì che lo script si interrompa al primo errore, in modo che systemd consideri l'esecuzione fallita. Colleghi una notifica (lezione 8.3), altrimenti non si accorgerà di un backup fallito.

Contro il ransomware: append-only

Nello script qui sopra il server stesso può anche cancellare il backup (forget e prune). Se un attaccante prende il controllo del server, quindi, può farlo anche lui. Due modi per evitarlo:

• rest-server in modalità append-only: sul server di storage esegue il rest-server di restic con l'opzione --append-only. Il server web può così aggiungere backup, ma non cancellare nulla. La pulizia (forget --prune) la esegue da un'altra macchina ben protetta con permessi completi.
• Storage con versioning o blocco degli oggetti presso un provider S3, così che gli oggetti eliminati possano essere recuperati ancora per un certo tempo.

Attenzione a una trappola sottile che la documentazione di restic stessa segnala: un attaccante che aggiunge snapshot falsi può indurre una politica come --keep-weekly a dimenticare snapshot reali. Con --keep-within (per esempio --keep-within 30d) tutto ciò che rientra in quel periodo viene conservato, falso o reale che sia.

Riepilogo

• restic cifra, deduplica e può salvare su molti tipi di storage esterni al Suo server; perdere la password significa perdere tutto.
• init crea il repository, backup uno snapshot, snapshots li mostra.
• forget con --keep-* stabilisce che cosa conservare; solo prune (o --prune) elimina davvero i dati. Faccia una prova con --dry-run.
• check (con --read-data-subset) verifica, restore --target ripristina in una cartella separata, mount Le permette di navigare.
• Automatizzi con un timer e una notifica, e tenga almeno un repository fuori dalla portata del server (append-only).

Quiz

Esercizio

Esercizio Z8.2: Che cosa rimane dopo forget? Nel file di esempio restic-snapshots.txt si trovano un elenco di snapshot e una politica di conservazione. Determini quali snapshot rimangono dopo restic forget con quella politica. Il programma confronta la risposta con la soluzione prestabilita.

Esercizio O8.2: Un test di ripristino. Sul Suo server crei un repository restic esterno al server, faccia un backup di /etc e dei Suoi dati e ripristini una cartella in /tmp/terug. Confronti con diff, annoti quanto tempo è stato necessario e indichi dove sono conservati, fuori dal server, la Sua password e i dati di accesso al Suo storage.

Per approfondire

• Strategia di backup: la regola del 3-2-1 per la Sua azienda
• Documentazione di restic, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Documentazione di restic, Removing backup snapshots (forget e prune): https://restic.readthedocs.io/en/stable/060_forget.html
• Documentazione di restic, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server