Il backup, per chi gestisce un homelab, è la prima cosa che ci si dimentica di fare e l’ultima che si vorrebbe avere quando serve davvero. Io ci sono passato: ho perso una collezione di foto del 2014 perché “tanto era sul NAS” e il NAS era l’unica copia. Da quella volta ho adottato un modello hot/warm/cold un po’ rigido ma che mi tiene sereno la notte.
Cos’è hot/warm/cold
è un modo di classificare i dati in base a quanto spesso ti servono e quanto in fretta li devi rivedere:
– Hot: dati che cambiano spesso e che ti servono entro minuti. File di lavoro corrente, configurazioni di servizi, snapshot recenti di database. Storage veloce, locale o quasi.
– Warm: dati importanti ma non urgenti. Backup settimanali completi, archivi recenti. Object storage standard.
– Cold: archivi storici, snapshot vecchi, materiale che serve “se brucia la casa”. Archive tier, costo bassissimo, ripristino lento e con costo di estrazione.
Idealmente i dati esistono in tre copie su due supporti diversi con una copia fuori sede: la regola 3-2-1. Hot/warm/cold è un modo pratico di implementarla.
Tier HOT con Restic su HOT_LOCAL
Restic fa snapshot incrementali deduplicati e cifrati. Lo uso verso un repository locale che chiamo categoricamente HOT_LOCAL, montato dal NAS in LAN: è veloce, locale, retention lunga senza pagare nulla in più.
Init del repository:
restic -r /mnt/HOT_LOCAL/restic init
Backup notturno della cartella dati di un servizio:
restic -r /mnt/HOT_LOCAL/restic backup /var/lib/mio-servizio
Retention policy che applico settimanalmente:
restic -r /mnt/HOT_LOCAL/restic forget \
--keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
Il prune libera spazio davvero, perché senza di lui i dati cancellati restano nel repo finché non passa il garbage collector.
Tier WARM su WARM_NFS e WARM_S3
La copia warm vive in due sottocategorie. Lo snapshot settimanale del repo Restic finisce su un mount NFS dedicato in rete locale (WARM_NFS) e una copia compressa va su un bucket S3-compatibile (WARM_S3_GLACIER) configurato come alias rclone:
rclone sync /mnt/HOT_LOCAL/restic WARM_S3_GLACIER:backup-restic \
--transfers 4 --checkers 8
sync riflette esattamente lo stato sorgente, quindi i file eliminati nel repo vengono eliminati anche sul bucket. Quando voglio mantenere una storia indipendente uso copy invece di sync.
Tier COLD su COLD_S3_GLACIER
Una volta al mese sposto i blocchi più vecchi di sei mesi in un bucket con storage class archive. Il comando rclone, con alias categoriale COLD_S3_GLACIER:
rclone move /mnt/HOT_LOCAL/restic/snapshots-old COLD_S3_GLACIER:archivio \
--min-age 180d
In cold paghi pochissimo per lo storage e tanto per l’estrazione. Lo uso per cose che spero di non rivedere mai (foto del 2010, vecchi log archiviati per audit). Per i dati totalmente offline tengo anche un tier ulteriore che chiamo ICE_TAPE: un disco USB cifrato che giro ogni due mesi e tengo a casa di un familiare fidato. è il vero off-site, slegato da qualunque cloud.
Un caso reale
Un mercoledì sera, verso le 21:15, stavo refactoring uno script di import dati e ho lanciato un rm -rf su una sottocartella sbagliata: 180 GB di dataset analitico spariti. Restic mi ha salvato in 14 minuti netti. Ho lanciato restic restore latest --target /tmp/recover --include /var/lib/dataset puntando al repo HOT_LOCAL sul NAS, e ho ripreso il lavoro senza dover andare a tirare giù copie warm o cold. Il giorno dopo ho aggiunto un check periodico che verifica l’integrità del repo:
restic -r /mnt/HOT_LOCAL/restic check --read-data-subset=10%
Lo lancio ogni due settimane: legge il 10% dei blocchi e verifica gli hash. Mi protegge da repository corrotti silenziosamente, che è il peggior tipo di problema con i backup.
Cosa funziona bene
I tre tier sono autonomi e si validano a vicenda. Se mi muore il NAS, ho ancora warm. Se mi cancellano l’account cloud, ho ancora hot e cold offline. La cifratura Restic ha chiave persistente che tengo in due posti (gestore password + supporto offline), e senza quella nessun ripristino è possibile, neanche per chi possiede fisicamente i bucket.
Limiti
Restic ha un costo CPU notevole sul Raspberry Pi che fa da NAS, e una verifica completa di un repo da 1 TB richiede ore. La latenza di restore da tier cold è nell’ordine delle ore, talvolta della giornata. Bisogna pianificare un DR test almeno una volta l’anno, altrimenti sei sicuro di avere backup solo finché non provi a ripristinarli.
In pratica
Hot/warm/cold non è una architettura, è un modo di pensare ai dati. Lo applico anche a un homelab piccolo, perché obbliga a chiedersi “quanto in fretta deve tornare questo?” prima di scegliere lo strumento. Il risultato è che dormo bene, e nessun rm distratto mi può più rovinare un weekend.
Immagine generata con Cloudflare Workers AI / FLUX.