Backup con Restic fatti bene

Restic è uno degli strumenti di backup più utili a disposizione di un amministratore Linux. Salva snapshot cifrati in un repository locale o remoto, trasferisce soltanto i dati non ancora presenti, supporta la compressione, verifica l'integrità del repository e permette di consultare o ripristinare versioni precedenti senza dover scompattare una catena di archivi.

Questo tutorial costruisce una configurazione Linux completa e manutenibile. Parte da un repository locale su disco esterno e affronta poi SFTP, esclusioni, automazione, conservazione, verifiche, consultazione, recupero selettivo e una strategia più sicura basata su due copie.

Gli esempi sono stati verificati con Restic 0.19.1. Prima di aggiornare un sistema di backup in produzione è sempre opportuno leggere le note di rilascio.

Un backup non è dimostrato da un comando `backup` terminato con successo. È dimostrato dal ripristino riuscito dei dati che servono davvero.

1. Che cosa fa Restic

Un repository Restic contiene una sequenza di snapshot. Ogni snapshot rappresenta i file e le directory selezionati in un determinato momento, ma Restic non crea ogni volta una seconda copia completa. I dati vengono suddivisi in blocchi determinati dal contenuto, cifrati e deduplicati. Un blocco già presente nel repository non deve essere memorizzato nuovamente.

Questo comportamento offre diverse proprietà utili:

dal punto di vista dell'utente ogni snapshot appare completo;
i backup ripetuti salvano normalmente solo i dati nuovi o modificati;
i contenuti duplicati possono essere riutilizzati anche quando compaiono in file diversi;
il contenuto del repository è cifrato;
l'integrità del repository può essere verificata;
gli snapshot più vecchi possono essere eliminati secondo una politica di conservazione;
sui sistemi supportati gli snapshot possono essere montati e consultati come un filesystem.

La compressione è supportata dal formato repository versione 2, attualmente usato come impostazione predefinita per i nuovi repository.

2. Installare Restic

Su Ubuntu o Debian:

sudo apt update
sudo apt install restic
restic version

I pacchetti delle distribuzioni possono essere meno recenti rispetto al progetto ufficiale. Per un'installazione in produzione conviene confrontare la versione installata con la versione stabile corrente di Restic. È possibile installare anche i binari ufficiali autonomi; un binario ufficiale può aggiornarsi con:

sudo restic self-update

Non automatizzare aggiornamenti alla cieca. Prova prima la nuova versione su un repository non critico e conserva una copia del binario precedente finché i controlli e la prova di ripristino non sono terminati correttamente.

3. Scegliere la posizione del repository

Il repository è la destinazione che contiene i dati cifrati del backup e i relativi metadati. Può essere:

una directory su un altro disco locale;
un disco USB rimovibile;
un server SFTP;
un server REST di Restic;
Amazon S3 o uno storage a oggetti compatibile;
un altro backend supportato direttamente o tramite `rclone`.

Per la prima configurazione supponiamo che un disco esterno sia montato in:

/media/backupdisk

Il repository sarà:

/media/backupdisk/restic/my-workstation

Non conservare l'unico repository sullo stesso disco fisico dei dati originali. In quel caso saresti protetto da una cancellazione accidentale, ma non da guasto del disco, furto, danno elettrico o ransomware capace di raggiungere entrambe le posizioni.

4. Creare una directory di configurazione protetta

Crea una directory per la configurazione di Restic, appartenente a root:

sudo install -d -m 0700 /etc/restic

Genera una password lunga e unica per il repository:

sudo sh -c 'umask 077; openssl rand -base64 48 > /etc/restic/password'

Controlla i permessi:

sudo stat -c '%a %U:%G %n' /etc/restic/password

Output atteso:

600 root:root /etc/restic/password

La password consente di decifrare e utilizzare il repository. Perderla significa perdere il backup. Conservane una copia separata e offline in un password manager o in un altro luogo sicuro che rimanga accessibile anche durante un disastro.

Non inserire la password direttamente nella riga di comando. Gli argomenti possono essere esposti nella cronologia della shell o durante l'ispezione dei processi. Un file protetto o un comando dedicato alla lettura della password sono normalmente più sicuri.

5. Definire le variabili d'ambiente

Crea `/etc/restic/workstation.env`:

sudo tee /etc/restic/workstation.env > /dev/null <<'EOF'
RESTIC_REPOSITORY=/media/backupdisk/restic/my-workstation
RESTIC_PASSWORD_FILE=/etc/restic/password
RESTIC_CACHE_DIR=/var/cache/restic
EOF

Proteggilo:

sudo chmod 0600 /etc/restic/workstation.env
sudo install -d -m 0700 /var/cache/restic

Quando lavori manualmente, caricalo nella shell corrente:

set -a
source /etc/restic/workstation.env
set +a

Controlla il percorso del repository senza visualizzare la password:

printf '%s\n' "$RESTIC_REPOSITORY"

6. Inizializzare il repository

Assicurati che il filesystem esterno sia montato, quindi crea il repository:

sudo mkdir -p /media/backupdisk/restic/my-workstation
sudo -E restic init

L'inizializzazione crea la struttura del repository e le chiavi di cifratura.

Questo comando va eseguito una sola volta per ogni repository. Se `restic init` segnala che il repository esiste già, fermati e verifica la situazione invece di sostituire qualcosa.

Elenca le chiavi del repository:

sudo -E restic key list

Restic può gestire più chiavi per lo stesso repository. È possibile aggiungere una nuova chiave prima di ritirare una vecchia password:

sudo -E restic key add

Non rimuovere mai l'ultima chiave utilizzabile.

7. Decidere che cosa salvare

Per una workstation, un insieme iniziale ragionevole potrebbe essere:

/home
/etc
/usr/local
/opt
/root

Non includere alla cieca pseudo-filesystem, cache e dati temporanei di runtime. Una strategia completa di ripristino Linux richiede anche elenchi dei pacchetti, dump dei database, configurazioni delle applicazioni, credenziali e documentazione della struttura dello storage. Restic conserva i file, ma non trasforma automaticamente uno snapshot arbitrario di un server acceso in un'immagine bare-metal avviabile.

Per i database crea prima un dump coerente. Salvare i file di un database vivo mentre vengono modificati può produrre uno snapshot difficile o impossibile da ripristinare correttamente.

Esempio di directory per i dump MariaDB:

sudo install -d -m 0700 /var/backups/database
sudo bash -o pipefail -c 'mariadb-dump --all-databases --single-transaction --routines --events \
  | gzip -c > /var/backups/database/all-databases.sql.gz'

Per sistemi importanti usa la procedura di backup raccomandata dal produttore del database.

8. Creare un file di esclusione

Crea `/etc/restic/excludes.txt`:

sudo tee /etc/restic/excludes.txt > /dev/null <<'EOF'
# Cache degli utenti e cestino
/home/*/.cache
/home/*/.local/share/Trash

# Cache dei browser
/home/*/.mozilla/firefox/*/cache2
/home/*/.cache/google-chrome
/home/*/.cache/chromium

# Dipendenze di sviluppo ricostruibili
**/node_modules
**/.venv
**/vendor

# Dati temporanei e di runtime
/tmp
/var/tmp
/var/cache
/var/run
/run

# Filesystem virtuali
/proc
/sys
/dev

# I filesystem montati vengono gestiti separatamente
/mnt
/media
EOF

Proteggi il file:

sudo chmod 0600 /etc/restic/excludes.txt

Controlla con attenzione le esclusioni. `node_modules` può essere eliminabile in un progetto, ma contenere modifiche locali non riproducibili in un altro. Escludi soltanto dati che sei davvero in grado di ricreare.

9. Eseguire il primo backup

Con le variabili d'ambiente caricate:

sudo -E restic backup \
  /home \
  /etc \
  /usr/local \
  /opt \
  /root \
  /var/backups/database \
  --exclude-file=/etc/restic/excludes.txt \
  --one-file-system \
  --tag workstation \
  --tag automatic

In un terminale interattivo Restic mostra l'avanzamento. Il riepilogo indica file nuovi, modificati e invariati, quantità di dati analizzata, dati aggiunti al repository e identificativo del nuovo snapshot.

`--one-file-system` impedisce a Restic di attraversare altri filesystem montati sotto uno dei percorsi selezionati. È utile per evitare di entrare accidentalmente nel disco di backup, in mount di rete o in grandi volumi non pertinenti. Gli altri filesystem necessari vanno aggiunti esplicitamente.

Esegui un secondo backup senza modificare nulla:

sudo -E restic backup \
  /home /etc /usr/local /opt /root /var/backups/database \
  --exclude-file=/etc/restic/excludes.txt \
  --one-file-system \
  --tag workstation \
  --tag manual-test

La seconda esecuzione deve comunque analizzare i metadati, ma se le sorgenti non sono cambiate dovrebbe aggiungere pochissimi dati.

10. Esaminare gli snapshot

Elenca tutti gli snapshot:

sudo -E restic snapshots

Raggruppali per host e percorsi:

sudo -E restic snapshots --group-by host,paths

Mostra lo snapshot più recente:

sudo -E restic snapshots --latest 1

Visualizza le statistiche del repository:

sudo -E restic stats

Per una vista più dettagliata dei dati fisicamente memorizzati:

sudo -E restic stats --mode raw-data

La dimensione di uno snapshot è la dimensione logica dei dati rappresentati, non necessariamente lo spazio fisico aggiunto da quella esecuzione. Deduplicazione e compressione fanno sì che i due valori siano diversi.

11. Consultare il backup senza ripristinare tutto

Esistono tre metodi pratici per esaminare il contenuto.

Elencare i file di uno snapshot

sudo -E restic ls latest

Limita l'elenco a una directory:

sudo -E restic ls latest /home/daniele/Documents

Cercare un file

sudo -E restic find '**/invoice-*.pdf'

Cerca soltanto nello snapshot più recente:

sudo -E restic find --snapshot latest '**/invoice-*.pdf'

Racchiudi i pattern con wildcard tra apici, altrimenti la shell potrebbe espanderli prima che Restic li riceva.

Montare il repository con FUSE

Installa il supporto FUSE se necessario:

sudo apt install fuse3
sudo mkdir -p /mnt/restic

Monta il repository:

sudo -E restic mount /mnt/restic

Lascia il processo in esecuzione e consulta `/mnt/restic` da un altro terminale o da un file manager. Troverai viste organizzate per ID dello snapshot, date, host e tag.

Al termine smonta il filesystem:

sudo umount /mnt/restic

Non usare mai come punto di mount la directory del repository stesso o un percorso che si sovrappone ad essa.

12. Ripristinare un singolo file o una directory

Ripristinare in una directory vuota e separata è più sicuro che sovrascrivere direttamente i file in produzione.

Crea una destinazione:

sudo mkdir -p /var/tmp/restic-restore
sudo chmod 0700 /var/tmp/restic-restore

Ripristina una singola directory dallo snapshot più recente:

sudo -E restic restore latest \
  --target /var/tmp/restic-restore \
  --include '/home/daniele/Documents/Accounts/**'

Ripristina un file specifico:

sudo -E restic restore latest \
  --target /var/tmp/restic-restore \
  --include '/etc/ssh/sshd_config'

Controlla i dati ripristinati prima di copiarli in produzione:

sudo find /var/tmp/restic-restore -maxdepth 5 -ls

La directory ripristinata contiene normalmente il percorso assoluto originale sotto la destinazione. Per esempio `/etc/ssh/sshd_config` comparirà in:

/var/tmp/restic-restore/etc/ssh/sshd_config

13. Ripristinare uno snapshot completo

Scegli un ID con `restic snapshots`, quindi ripristinalo in una destinazione vuota:

sudo mkdir -p /restore/full
sudo -E restic restore SNAPSHOT_ID --target /restore/full

Non indirizzare il primo ripristino completo verso `/`. Ripristina altrove, controlla il risultato, arresta i servizi interessati e copia i dati solo dopo aver definito un piano di recupero.

Il recupero di un server segue spesso questo ordine:

1. reinstallare o avviare un sistema operativo pulito; 2. ricreare storage, utenti e pacchetti necessari; 3. installare Restic e recuperare la password del repository; 4. ripristinare configurazioni e file delle applicazioni; 5. ripristinare i database con i loro strumenti nativi; 6. verificare proprietari, permessi, servizi e configurazione di rete; 7. provare l'applicazione prima di riaprire l'accesso.

14. Leggere direttamente un file da uno snapshot

Per un controllo rapido usa `dump`:

sudo -E restic dump latest /etc/ssh/sshd_config | less

Estrai un singolo file:

sudo -E restic dump latest /etc/ssh/sshd_config \
  > /var/tmp/sshd_config.from-backup

Puoi anche estrarre una directory come archivio:

sudo -E restic dump latest /home/daniele/Documents \
  --archive tar > /var/tmp/Documents.tar

15. Confrontare gli snapshot

Individua le differenze tra due snapshot:

sudo -E restic diff OLD_SNAPSHOT_ID NEW_SNAPSHOT_ID

È utile dopo una modifica sospetta della configurazione, una cancellazione accidentale o un aggiornamento dell'applicazione.

16. Verificare l'integrità del repository

Esegui regolarmente il controllo strutturale:

sudo -E restic check

Il comando verifica metadati, indici, snapshot, alberi e struttura dei pack memorizzati. Per impostazione predefinita non legge ogni byte di tutti i blocchi di dati.

Per una lettura completa:

sudo -E restic check --read-data

Una lettura completa può essere costosa su un grande repository remoto. Puoi distribuire il controllo su più esecuzioni:

sudo -E restic check --read-data-subset=1/7
sudo -E restic check --read-data-subset=2/7
sudo -E restic check --read-data-subset=3/7

Continua fino a `7/7` nei giorni successivi. In questo modo l'intero repository viene verificato in sette porzioni.

Il controllo di integrità è essenziale, ma non sostituisce una prova di ripristino a livello applicativo. Un dump del database può essere integro come file e comunque inutilizzabile perché la procedura di esportazione era sbagliata.

17. Definire una politica di conservazione

Gli snapshot si accumulano finché non vengono dimenticati esplicitamente. Inizia con una simulazione:

sudo -E restic forget \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --keep-yearly 5 \
  --tag workstation \
  --dry-run

Leggi attentamente l'output. Quando corrisponde alle tue intenzioni, rimuovi `--dry-run`:

sudo -E restic forget \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --keep-yearly 5 \
  --tag workstation

`forget` elimina i riferimenti agli snapshot, ma non recupera necessariamente subito spazio fisico.

Esegui `prune` per eliminare i dati non più referenziati:

sudo -E restic prune

Oppure combina le due operazioni:

sudo -E restic forget \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --keep-yearly 5 \
  --tag workstation \
  --prune

Il pruning può scaricare, ricomporre e ricaricare dati, soprattutto con un repository remoto. Pianificalo meno frequentemente dei backup e non interromperlo senza motivo.

18. Creare uno script di backup riutilizzabile

Crea `/usr/local/sbin/restic-workstation-backup`:

sudo tee /usr/local/sbin/restic-workstation-backup > /dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

ENV_FILE=/etc/restic/workstation.env
EXCLUDE_FILE=/etc/restic/excludes.txt
LOCK_FILE=/run/lock/restic-workstation.lock

exec 9>"$LOCK_FILE"
if ! flock -n 9; then
    echo "È già in esecuzione un altro backup Restic." >&2
    exit 75
fi

set -a
# shellcheck disable=SC1090
source "$ENV_FILE"
set +a

if ! mountpoint -q /media/backupdisk; then
    echo "Il disco di backup non è montato: operazione interrotta." >&2
    exit 1
fi

/usr/bin/restic backup \
    /home \
    /etc \
    /usr/local \
    /opt \
    /root \
    /var/backups/database \
    --exclude-file="$EXCLUDE_FILE" \
    --one-file-system \
    --tag workstation \
    --tag automatic

/usr/bin/restic check --with-cache
EOF

sudo chmod 0700 /usr/local/sbin/restic-workstation-backup

Prova manualmente lo script:

sudo /usr/local/sbin/restic-workstation-backup

Il blocco con `flock` impedisce esecuzioni sovrapposte. Il controllo del mount point evita un problema pericoloso: se il disco esterno manca, Restic potrebbe creare un nuovo repository nella normale directory vuota del punto di mount, riempiendo il disco di sistema.

19. Pianificare i backup con systemd

Crea `/etc/systemd/system/restic-workstation.service`:

[Unit]
Description=Backup cifrato Restic della workstation
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-workstation-backup
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Crea `/etc/systemd/system/restic-workstation.timer`:

[Unit]
Description=Esegue ogni giorno il backup Restic della workstation

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

[Install]
WantedBy=timers.target

Abilitalo:

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

Controlla la pianificazione:

systemctl list-timers restic-workstation.timer

Avvialo immediatamente:

sudo systemctl start restic-workstation.service

Leggi il log:

sudo journalctl -u restic-workstation.service -n 200 --no-pager

`Persistent=true` fa partire dopo il successivo avvio della macchina un'esecuzione saltata. `RandomizedDelaySec` evita che tutte le macchine contattino lo storage remoto nello stesso identico secondo.

20. Pianificare separatamente la manutenzione

I backup devono essere frequenti; il pruning può essere settimanale o mensile.

Crea `/usr/local/sbin/restic-workstation-maintenance`:

sudo tee /usr/local/sbin/restic-workstation-maintenance > /dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

set -a
# shellcheck disable=SC1091
source /etc/restic/workstation.env
set +a

exec 9>/run/lock/restic-workstation.lock
flock -n 9 || exit 75

/usr/bin/restic forget \
    --keep-daily 7 \
    --keep-weekly 5 \
    --keep-monthly 12 \
    --keep-yearly 5 \
    --tag workstation \
    --prune

WEEK_NUMBER=$(date +%V)
SUBSET=$((10#$WEEK_NUMBER % 4 + 1))
/usr/bin/restic check --read-data-subset="${SUBSET}/4"
EOF

sudo chmod 0700 /usr/local/sbin/restic-workstation-maintenance

Crea `/etc/systemd/system/restic-workstation-maintenance.service`:

[Unit]
Description=Conservazione, pruning e verifica parziale dei dati Restic
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-workstation-maintenance
Nice=15
IOSchedulingClass=idle

Crea `/etc/systemd/system/restic-workstation-maintenance.timer`:

[Unit]
Description=Esegue settimanalmente la manutenzione Restic

[Timer]
OnCalendar=Sun *-*-* 04:15:00
Persistent=true
RandomizedDelaySec=30m

[Install]
WantedBy=timers.target

Abilitalo:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-workstation-maintenance.timer

Lo script ricava un quarto del repository dal numero ISO della settimana, così le esecuzioni settimanali consecutive attraversano ciclicamente tutte e quattro le porzioni. Quando dimensioni e banda lo consentono, rimane utile anche un controllo completo occasionale.

21. Usare un repository SFTP

Configura prima l'autenticazione SSH con chiave per un account dedicato ai backup. Verifica che il collegamento funzioni senza password interattiva:

ssh backupuser@backup.example.net

Un percorso SFTP assoluto ha questa forma:

sftp:backupuser@backup.example.net:/srv/restic/workstation

Un percorso relativo alla home dell'utente remoto non contiene la barra iniziale dopo l'host:

sftp:backupuser@backup.example.net:restic/workstation

Imposta il repository nel file d'ambiente:

RESTIC_REPOSITORY=sftp:backupuser@backup.example.net:/srv/restic/workstation

Inizializzalo:

sudo -E restic init

Da quel momento puoi usare gli stessi comandi `backup`, `snapshots`, `restore`, `check`, `forget` e `prune`.

Usa un account dedicato e limita le sue capacità SSH. Una credenziale di backup non dovrebbe concedere accesso amministrativo generale al server remoto.

22. Proteggersi da ransomware e cancellazioni

La cifratura protegge la riservatezza. Non impedisce a un client compromesso, dotato dei permessi di scrittura e cancellazione, di eliminare il repository.

Un progetto più robusto separa la creazione dei backup dalla loro cancellazione:

il client ordinario può aggiungere nuovi backup;
un host amministrativo separato e affidabile esegue conservazione e pruning;
versioning, immutabilità o snapshot dello storage proteggono gli oggetti del repository;
almeno una copia non è continuamente scrivibile dalla macchina protetta.

Il server REST di Restic può essere configurato in modalità append-only. Questo limita ciò che un client di backup compromesso può cancellare, ma la manutenzione amministrativa richiede comunque accesso completo da un sistema meglio protetto.

Occorre prudenza con le politiche di conservazione sui repository append-only. Un aggressore capace di aggiungere snapshot fuorvianti potrebbe influenzare regole basate soltanto sul numero di snapshot giornalieri o settimanali. In questo scenario una conservazione temporale come `--keep-within` è più sicura, ma restano necessari monitoraggio operativo e protezioni indipendenti dello storage.

23. Mantenere un secondo repository

Un solo repository non costituisce un piano completo di disaster recovery. Un approccio pratico prevede:

repository cifrato principale su disco esterno locale o server di backup locale;
repository cifrato secondario in un'altra posizione fisica;
copia periodica offline o immutabile per i dati di maggior valore.

Puoi salvare le stesse sorgenti indipendentemente in due repository. È semplice e offre a ogni destinazione una propria storia di integrità.

Restic può anche copiare gli snapshot tra repository. Quando crei una destinazione appositamente per ricevere snapshot copiati, inizializzala con i parametri del chunker del repository sorgente, così la deduplicazione rimane efficace:

restic -r /srv/restic-repo-copy init \
  --from-repo /srv/restic-repo \
  --copy-chunker-params

Copia tutti gli snapshot:

restic -r /srv/restic-repo-copy copy \
  --from-repo /srv/restic-repo \
  --verbose

Se i repository hanno password diverse, fornisci quella della sorgente con `--from-password-file` e quella della destinazione con la normale opzione `--password-file` o con le corrispondenti variabili d'ambiente.

Il processo di copia decifra i dati dalla sorgente e li cifra per la destinazione, quindi può consumare molta banda in lettura, upload e download. Provalo con attenzione prima di affidargli un sistema di produzione e ricorda che una copia eseguita dallo stesso host compromesso non è automaticamente indipendente dalla compromissione.

24. Monitorare davvero il successo

Un timer eseguito non equivale a un backup riuscito. Controlla almeno:

stato di uscita del servizio systemd;
età dello snapshot più recente;
variazioni inattese della dimensione del backup;
risultati dei controlli del repository;
spazio libero sulla destinazione;
data ed esito dell'ultima prova di ripristino.

Un semplice controllo della freschezza:

sudo -E restic snapshots --json --latest 1

Per il monitoraggio automatico analizza il JSON e genera un avviso quando l'ultimo snapshot riuscito è più vecchio dell'obiettivo concordato per il punto di ripristino.

In un contesto non interattivo Restic normalmente non mostra l'avanzamento. Per scrivere periodicamente lo stato nei log, imposta `RESTIC_PROGRESS_FPS` su un valore basso, per esempio un aggiornamento al minuto:

RESTIC_PROGRESS_FPS=0.016666

Nei sistemi Unix, anche l'invio del segnale `SIGUSR1` a un processo Restic in esecuzione richiede un rapporto di avanzamento.

25. Eseguire una vera prova di ripristino

Almeno una volta ogni trimestre seleziona un insieme rappresentativo:

un normale documento;
una directory con molti file;
un file per il quale proprietario e permessi sono importanti;
una configurazione applicativa;
un dump del database;
un file proveniente da uno snapshot vecchio, non soltanto dall'ultimo.

Ripristina in una destinazione isolata, confronta gli hash quando opportuno, apri realmente i documenti e importa davvero il database in un'istanza temporanea.

Esempio di confronto degli hash:

sha256sum /home/daniele/Documents/important.pdf
sha256sum /var/tmp/restic-restore/home/daniele/Documents/important.pdf

Per una prova di disaster recovery, esegui il ripristino utilizzando soltanto documentazione e credenziali che sarebbero disponibili dopo la perdita della macchina originale.

26. Errori comuni

Il disco di backup non era montato

La directory del mount esisteva comunque e il backup ha riempito il disco di sistema. Verifica sempre con `mountpoint -q` prima di iniziare.

La password del repository esisteva solo sulla macchina sorgente

Dopo la perdita della macchina il repository era integro, ma inaccessibile. Conserva una copia offline protetta della password.

I database vivi sono stati copiati come normali file

Uno snapshot a livello di file non è automaticamente un backup transazionalmente coerente del database. Usa dump o meccanismi snapshot nativi.

La conservazione è stata attivata senza simulazione

Una regola di raggruppamento compresa male ha eliminato più snapshot del previsto. Esegui `forget --dry-run`, controlla i gruppi e documenta la politica.

I backup hanno funzionato per mesi, ma nessuno ha mai provato il ripristino

Errori di configurazione, esclusioni sbagliate o dump applicativi inutilizzabili sono rimasti invisibili. Pianifica le prove di ripristino come attività operativa.

Il client di backup poteva cancellare ogni copia

Ransomware o una credenziale rubata hanno eliminato sia i dati principali sia quelli di backup. Mantieni una copia offline, immutabile o amministrata separatamente.

Il repository è stato copiato con un normale sincronizzatore mentre era attivo

Copiare un repository durante modifiche concorrenti può produrre una seconda copia incoerente. Preferisci backup indipendenti, le funzioni di copia tra repository di Restic o uno snapshot dello storage eseguito con adeguate garanzie di coerenza.

27. Una checklist operativa compatta

Per un piccolo sistema Linux, la routine minima credibile è:

# Ogni giorno
restic backup ...

# Dopo ogni backup, o almeno con regolarità
restic snapshots --latest 1
restic check

# Ogni settimana o mese
restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 5 --prune

# In porzioni a rotazione oppure periodicamente in modo completo
restic check --read-data-subset=1/4

# Ogni trimestre
restic restore SNAPSHOT_ID --target /isolated/restore-test

Conclusione

Restic rende piacevolmente semplice la creazione di snapshot cifrati, deduplicati e compressi. Il comando, però, è soltanto una parte di un sistema di backup affidabile.

Il sistema reale comprende una password protetta, un repository conservato in modo indipendente, esclusioni ragionevoli, dump coerenti dei database, esecuzione automatica, monitoraggio degli errori, conservazione, verifica del repository e ripetute prove di ripristino.

Questa è la differenza tra avere dei file di backup e avere un piano di recupero.

Backup con Restic fatti bene: cifratura, conservazione, consultazione e ripristino