Backup automatici di server e PC con restic e la regola 3-2-1: guida pratica 2026

La regola 3-2-1 è semplice da enunciare: tre copie dei dati, su due supporti diversi, di cui una fuori casa. Metterla in pratica senza dimenticarsene è un’altra storia. restic è lo strumento che consigliamo per farlo su server e PC Linux (funziona anche su macOS e Windows): cifra tutto per impostazione predefinita, salva solo i blocchi che cambiano e parla direttamente con dischi locali, server SFTP e storage compatibili S3. In questa guida costruiamo uno schema completo: un repository locale, uno fuori sede, un timer che li aggiorna ogni notte, una politica di conservazione e un avviso se qualcosa fallisce.

Versioni di riferimento: procedura verificata sulla documentazione ufficiale al 4 novembre 2026. L’ultima versione di restic è la 0.19.1 (5 luglio 2026); Ubuntu 26.04 LTS distribuisce la 0.18.1 e Debian 13 la 0.18.0. Tutti i comandi della guida funzionano con entrambe le serie.

La regola 3-2-1 tradotta in un server di casa

Per le macchine virtuali su Proxmox la scelta naturale è Proxmox Backup Server (versione attuale 4.2), che fa backup incrementali deduplicati delle VM intere; restic è complementare e lavora a livello di file, dentro le VM o sull’host. Per i Mac c’è https://hardwarfare.it/pc-notebook/mac/backup-mac-time-machine-disco-nas/.

Passo 1: installare restic

Su Debian e Ubuntu il pacchetto ufficiale si installa con (serve sudo):

sudo apt-get install restic

Su Fedora sudo dnf install restic, su macOS brew install restic, su Windows winget install --exact --id restic.restic --scope Machine. Chi vuole l’ultima versione può usare i binari ufficiali dalla pagina GitHub del progetto: quelli si aggiornano sul posto con restic self-update.

Passo 2: file di password e repository locale

Per l’automazione la password va in un file leggibile solo da root, indicato con la variabile RESTIC_PASSWORD_FILE. Generatene una lunga e casuale:

sudo mkdir -p /etc/restic
sudo sh -c 'openssl rand -base64 32 > /etc/restic/password'
sudo chmod 600 /etc/restic/password

Montate il disco esterno (nell’esempio in /mnt/backup) e inizializzate il repository:

sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password init

Passo 3: il repository fuori sede

Due opzioni ragionevoli per chi è in Italia:

• Server SFTP (un NAS da un parente, una storage box): la sintassi è sftp:UTENTE@HOST:/percorso. Hetzner, per esempio, elenca restic tra i protocolli delle sue Storage Box; la BX11 da 1 TB costa 3,20 € al mese IVA esclusa secondo il listino di inizio novembre 2026.
• Storage S3: Backblaze B2 parte da 6,95 dollari per TB al mese, con i primi 10 GB gratuiti e traffico in uscita gratuito fino a tre volte lo spazio medio occupato. Per B2 la documentazione di restic raccomanda di usare l’API compatibile S3 invece del backend B2 nativo, per problemi nella gestione degli errori di quest’ultimo, e di impostare sul bucket la regola di ciclo di vita “Keep only the last version of the file”.

Le credenziali S3 si passano con variabili d’ambiente. Create un file /etc/restic/remoto.env (permessi 600) così:

RESTIC_REPOSITORY=s3:https://ENDPOINT_S3/NOME_BUCKET/server-casa
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=CHIAVE_ID
AWS_SECRET_ACCESS_KEY=CHIAVE_SEGRETA

e inizializzate:

sudo chmod 600 /etc/restic/remoto.env
sudo sh -c 'set -a; . /etc/restic/remoto.env; restic init'

Si può usare la stessa password per i due repository o due diverse: due sono più sicure, ma vanno conservate entrambe.

Passo 4: il primo backup e le esclusioni

Create un file di esclusioni /etc/restic/escludi.txt con un modello per riga (per esempio /var/cache, /var/tmp, **/node_modules) e provate prima con --dry-run:

sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password backup /etc /home /srv --exclude-file=/etc/restic/escludi.txt --dry-run -vv
sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password backup /etc /home /srv --exclude-file=/etc/restic/escludi.txt

Attenzione ai database: copiare i file di MariaDB o PostgreSQL mentre il servizio è attivo produce copie potenzialmente inconsistenti. restic può salvare direttamente l’output di un comando di dump con --stdin-from-command, e a differenza di una pipe con --stdin si accorge se il comando fallisce (in quel caso annulla il backup ed esce con codice 1):

sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password backup --stdin-filename tutti-i-db.sql --stdin-from-command -- mariadb-dump --all-databases

Passo 5: conservazione con forget –prune

Senza una politica di conservazione il repository cresce all’infinito. forget rimuove gli snapshot secondo le regole indicate e, con --prune, elimina anche i dati non più referenziati. Uno schema sensato per un server di casa: 7 giornalieri, 4 settimanali, 12 mensili.

sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Il prune blocca il repository mentre lavora: pianificatelo in un orario che non si sovrapponga ai backup. La documentazione consiglia di eseguire restic check dopo il prune.

Passo 6: automatizzare con un timer systemd

Un piccolo script esegue backup, conservazione e controllo su entrambi i repository. Salvatelo come /usr/local/sbin/backup-restic.sh e rendetelo eseguibile con sudo chmod 700:

#!/bin/sh
set -e
for ENVFILE in /etc/restic/locale.env /etc/restic/remoto.env; do
  set -a; . "$ENVFILE"; set +a
  restic backup /etc /home /srv --exclude-file=/etc/restic/escludi.txt
  restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
  restic check
done

Il file /etc/restic/locale.env contiene solo RESTIC_REPOSITORY=/mnt/backup/restic-repo e RESTIC_PASSWORD_FILE=/etc/restic/password. Con set -e lo script si ferma al primo errore, così systemd lo segnala come fallito. Poi il servizio, /etc/systemd/system/backup-restic.service:

[Unit]
Description=Backup restic notturno
OnFailure=avviso-backup.service

[Service]
Type=oneshot
Environment=RESTIC_CACHE_DIR=/var/cache/restic
ExecStart=/usr/local/sbin/backup-restic.sh

La riga Environment= non è superflua: systemd non imposta $HOME per i servizi di sistema senza User=, e senza una cartella di cache restic, secondo la sua documentazione, termina con un errore. Poi il timer, /etc/systemd/system/backup-restic.timer:

[Unit]
Description=Esegue il backup restic ogni notte

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true fa partire subito il backup saltato se il server era spento all’ora prevista; RandomizedDelaySec aggiunge un ritardo casuale fino a 15 minuti.

sudo systemctl daemon-reload
sudo systemctl enable --now backup-restic.timer

Passo 7: farsi avvisare quando il backup fallisce

Un backup che fallisce in silenzio è peggio di nessun backup, perché dà una falsa sicurezza. La riga OnFailure= del servizio richiama un’unità avviso-backup.service che potete scrivere come preferite: un’email con il sistema di posta del server, un messaggio a un bot Telegram o una chiamata a un servizio di monitoraggio. Un’alternativa più robusta, perché si accorge anche di un server spento, è un servizio “dead man’s switch” che vi avvisa se non riceve il segnale di completamento entro una certa ora. I codici di uscita documentati da restic aiutano a distinguere i casi: 10 repository inesistente, 11 repository bloccato, 12 password errata.

Passo 8: il test di ripristino (obbligatorio)

Un backup mai ripristinato è un’ipotesi. Una volta al mese ripristinate qualcosa in una cartella temporanea e confrontatelo con l’originale:

sudo restic -r /mnt/backup/restic-repo --password-file /etc/restic/password restore latest --target /tmp/prova-ripristino --include /etc/fstab
sudo diff /etc/fstab /tmp/prova-ripristino/etc/fstab

Ogni tanto verificate anche i dati, non solo la struttura: restic check --read-data-subset=10% legge e controlla un decimo, scelto a caso, dei pacchetti del repository: ripetuto nel tempo copre quasi tutto senza scaricare ogni volta l’intero archivio dal cloud (per un giro completo e ordinato la documentazione indica la forma --read-data-subset=1/5, 2/5 e così via). Infine, una volta l’anno, provate un ripristino completo su una macchina diversa usando soltanto la password salvata nel gestore: è la prova che vi servirà davvero.

Se qualcosa va storto

• “Fatal: repository does not exist: unable to open config file”: il percorso o l’URL del repository è sbagliato, oppure il disco esterno non è montato. È il codice di uscita 10. Controllate con findmnt /mnt/backup.
• Codice 11, repository bloccato: un’altra operazione (spesso un prune lungo) è in corso, oppure un processo interrotto ha lasciato un lock. Accertatevi che nessun restic sia in esecuzione prima di usare restic unlock.
• Codice 12, password errata: il file di password non è quello usato all’inizializzazione.
• “The repository index is damaged and must be repaired” durante restic check: eseguite restic repair index, poi di nuovo check.
• Codice 3 a ogni backup: alcuni file non sono leggibili, di solito per permessi o file aperti in esclusiva. Lo snapshot viene creato senza quei file: controllate quali sono nell’output e decidete se escluderli.
• Il disco di backup si riempie: controllate che forget abbia --prune e, su B2, che il bucket abbia la regola di ciclo di vita indicata sopra: senza, le versioni “nascoste” continuano a occupare spazio.

Come tornare indietro

Per sospendere l’automazione: sudo systemctl disable --now backup-restic.timer. Rimuovendo i file del timer, del servizio e dello script il sistema torna com’era; i repository restano intatti e leggibili con la password. Se cambiate strumento, non cancellate subito i repository restic: teneteli finché il nuovo sistema non ha superato almeno un test di ripristino completo.

La nostra lettura

restic non è l’unico buon strumento di backup (BorgBackup, usato anche da Nextcloud All-in-One, è un’ottima alternativa), ma ha il pregio di trattare allo stesso modo un disco USB e uno storage S3, con un solo comando da imparare. Lo schema di questa guida costa pochi euro al mese per lo spazio remoto e un’ora di lavoro; il punto debole non è mai la tecnologia, è la prova di ripristino che si rimanda. Mettetela in calendario. Per controllare anche che i dischi stiano bene, abbinate la guida https://hardwarfare.it/guide/tutorial/controllare-salute-ssd-hard-disk-smart/.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo