Backup 3-2-1 per un server web: come applicarlo davvero con restic e Borg

Un backup che non si è mai ripristinato è una scommessa, non una protezione. Questa guida copre la regola 3-2-1 applicata a un server web Ubuntu, con i comandi reali di restic e di BorgBackup, la pianificazione via cron e - punto che quasi tutti saltano - come verificare che il ripristino funzioni davvero. Aggiornata al 14 ottobre 2026, resta valida indipendentemente dalla versione del sistema: i comandi di base di restic e Borg non cambiano da anni.

Cos'è la regola 3-2-1

La regola 3-2-1 dice: 3 copie dei dati (l'originale più due backup), su 2 supporti o sistemi di storage diversi, con 1 copia conservata fuori sede (offsite). Per un server web tipico questo significa, in pratica: i file e il database in produzione, un backup locale su un disco separato dal volume di sistema, e un backup su uno storage remoto (un altro datacenter, un bucket S3-compatibile, uno Storage Box) raggiungibile anche se il server principale va distrutto.

Non basta "fare lo snapshot del provider": se lo snapshot vive sullo stesso account e lo stesso provider, è un solo supporto. Conta come copia offsite solo uno storage gestito da un fornitore diverso o comunque fuori dal raggio di un singolo incidente (hardware, attacco, errore umano, fatturazione bloccata).

restic: repository e primo backup

restic è disponibile nei repository Ubuntu e si installa con sudo apt install restic. Il concetto centrale è il repository: una destinazione cifrata dove restic salva le revisioni dei file.

Per creare un repository locale:

sudo mkdir -p /backup/restic
sudo restic init --repo /backup/restic

Il comando chiede una password: quella password serve per proteggere il repository e va ricordata, perché serve per ogni operazione successiva. Senza password non si recupera nulla.

Per un repository remoto via SFTP, lo schema è lo stesso ma cambia la destinazione:

restic -r sftp:user@hostname:/path/to/repo init

come indicato nella documentazione di restic per i backend remoti.

Il backup vero e proprio di una cartella (es. la webroot) si lancia con:

sudo restic -r /backup/restic backup /var/www

Per uno storage S3-compatibile (MinIO, Wasabi, Backblaze B2 via S3) basta cambiare la stringa del repository, ad esempio s3:https://endpoint/bucket/nome-repo, impostando prima le variabili AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

Per controllare l'integrità del repository, non solo che esista:

sudo restic -r /backup/restic check

Borg: init, create, prune

BorgBackup lavora per archivi dentro un repository. L'inizializzazione:

borg init --encryption=repokey /path/to/repo

Una repository è una directory del filesystem contenente i dati deduplicati di zero o più archivi.

Il backup crea un nuovo archivio con nome a scelta (tipicamente data e host):

borg create /path/to/repo::Monday ~/src ~/Documents

Su un server reale lo schema tipico include le cartelle di sistema e le esclusioni delle directory volatili, come mostrato nello script ufficiale della quickstart di Borg:

borg create --compression lz4 --exclude-caches \
 ::'{hostname}-{now}' /etc /home /var/www

Per il backend remoto via SSH, la sintassi usa lo stesso schema con utente, host e percorso:

borg init --encryption=repokey ssh://user@host:porta/./backups/server1

La retention si gestisce con prune, che cancella tutti gli archivi che non corrispondono a nessuna delle opzioni di conservazione specificate. Un esempio per tenere 7 copie giornaliere e 4 settimanali:

borg prune -v --list --dry-run --keep-daily=7 --keep-weekly=4 /path/to/repo

È fortemente raccomandato eseguire sempre prima prune con --dry-run, perché prune cancella in modo definitivo gli archivi non trattenuti. Da notare: pruning non libera subito lo spazio sul repository, per quello serve borg compact dopo il prune.

Pianificazione con cron

Entrambi gli strumenti si schedulano con una riga di crontab. Per restic, un backup notturno alle 2:30 con retention settimanale:

30 2 * * * RESTIC_REPOSITORY=/backup/restic RESTIC_PASSWORD_FILE=/etc/restic/password restic backup /var/www && restic forget --keep-daily 7 --keep-weekly 4 --prune

Per Borg, lo stesso schema richiama lo script di backup che include create e prune in sequenza, con le variabili BORG_REPO e BORG_PASSPHRASE esportate in testa allo script, come nello script di esempio della documentazione ufficiale. Il file va reso eseguibile solo dall'utente che lancia il backup (permessi 0700) e il crontab va impostato sull'utenza che ha accesso al repository, non su root se non necessario.

Testare il ripristino: la parte che conta

Un backup non verificato è un file che occupa spazio. Il test di ripristino va fatto a intervalli regolari, non una volta sola alla configurazione.

Con restic, il ripristino di uno snapshot specifico in una cartella separata:

restic -r /backup/restic restore <snapshot-id> --target /tmp/restore-test

Prima di cercare lo snapshot-id si lista cosa è disponibile con restic -r /backup/restic snapshots. In alternativa, per un controllo rapido senza ripristinare tutto, restic permette di montare il repository come filesystem e navigare i file di una versione passata senza estrarli.

Con Borg, l'estrazione di un archivio specifico funziona in modo analogo:

borg extract /path/to/repo::nome-archivio

eseguito dentro una directory di test vuota, mai sulla produzione. Borg supporta anche il mount FUSE di un archivio per ispezionarlo senza estrarlo, utile per verificare rapidamente che un singolo file sia recuperabile.

Checklist minima per un backup che si fida di sé stesso

• Verificare che il job cron sia effettivamente andato a buon fine (log, non solo "esiste il file crontab").
• Lanciare restic check o borg check sul repository con una frequenza periodica, non solo al setup.
• Fare un ripristino di prova in una directory separata almeno una volta al mese, non aspettare l'emergenza per scoprire che la password è sbagliata o il repository è corrotto.
• Tenere la password del repository (restic) o la passphrase (Borg) in un posto diverso dal server che si sta backuppando: se il server muore e la password era solo lì, i dati sono persi comunque.
• Controllare che la copia offsite sia su un account e un fornitore diversi da quello del server principale: è la condizione che rende la regola 3-2-1 reale e non solo scritta nella documentazione interna.