Category: Storage e Backup

Disaster Recovery suona come una di quelle parole che gli enterprise usano per fare bei diagrammi. In un homelab significa una cosa molto più pragmatica: se domani brucia il modem, sparisce il NAS, mi rubano il portatile, in quanto tempo posso ricostruire e quanto ho perso? Per me la risposta deve essere: poche ore di lavoro, al massimo una settimana di dati.

Qui descrivo come ho messo in piedi un piano DR per il mio piccolo homelab, costo annuale qualche euro, recupero garantito.

Cosa salvare

Prima ancora di scegliere strumenti, ho fatto la lista di cosa “duole” davvero perdere:

– Configurazioni di sistema: /etc dei vari host, unit systemd custom, vhost nginx/apache, certificati Let’s Encrypt

– Dati di servizi: database (Snipe-IT, Vikunja, Grafana, InfluxDB), volumi Docker persistenti

– Foto e documenti personali: archivio storico, scansioni, materiale di lavoro

– Codice sorgente: progetti personali, repo git che non vivono su forge remote

– Note e wiki: knowledge base personale

ciò che invece NON salvo: ISO di OS (riscaricabili), cache di servizi, snapshot intermedi di backup (sarebbe ridondante).

Strumenti

Tre soli, ben rodati:

– rsync per copie incrementali rapide, locali e su NAS

– restic per backup cifrati deduplicati, locali e remoti

– rclone per portare backup verso object storage cloud su tier gratuiti

Niente custom script complicati, niente backup tool esotici. Cose che funzionano da quindici anni e funzioneranno tra quindici.

Layer 1: snapshot locali con rsync

Ogni notte alle 02:00 un job cron fa snapshot delle directory critiche su un disco USB attaccato al server principale. Il comando:

rsync -aH --delete --link-dest=/mnt/usb/backup/yesterday \
  /etc /home/user/Documenti /var/lib/docker/volumes \
  /mnt/usb/backup/today

--link-dest fa hardlink ai file invariati rispetto a ieri: 30 giorni di snapshot occupano circa lo spazio di uno solo, più i delta. Ruoto today su yesterday con un secondo job mattutino.

è il “recovery time” più veloce: copio indietro con cp -a e sono operativo in minuti.

Layer 2: restic verso NAS

Una volta al giorno, dopo gli snapshot rsync, lancio restic verso un repository sul NAS:

restic -r /mnt/nas/restic backup /mnt/usb/backup/today \
  --exclude-caches --tag daily

Restic è incrementale, cifrato con chiave persistente, deduplicato a livello blocco. La password del repo sta in due posti: gestore password e supporto offline cartaceo. Senza, nessun ripristino è possibile, neanche fisicamente.

Layer 3: rclone verso object storage

Settimanalmente sincronizzo il repo restic verso un bucket S3-compatibile su tier gratuito di un cloud provider:

rclone sync /mnt/nas/restic OFFSITE_S3:dr-restic \
  --transfers 4 --bwlimit 5M

--bwlimit 5M evita che il backup notturno saturi la mia banda. OFFSITE_S3 è un alias generico in ~/.config/rclone/rclone.conf, configurato con credenziali read-write per un singolo bucket, niente account-level.

Layer 4: copia fredda offline

Ogni due mesi giro un disco USB cifrato con LUKS, contenente l’ultima snapshot restic, e lo deposito a casa di un familiare. è il vero off-site, indipendente da qualunque cloud. Se domani tutti i miei cloud provider mi cancellassero l’account, avrei comunque una copia rilevante.

Un caso reale

Un martedì sera, verso le 21:00, l’SSD USB del mio server principale ha smesso di rispondere. SMART pulito fino al giorno prima, ma il dispositivo era diventato read-only per un crash del controller. Servizi giù: Snipe-IT, Vikunja, dashboard Grafana, repo git locali. Ho sostituito il disco con uno nuovo il mattino dopo, installato Debian fresco, ripristinato /etc e /var/lib/docker/volumes con un restic restore latest --target / dal repo NAS, e in due ore e mezza tutto era di nuovo online. RPO finale: 18 ore di dati persi (l’ultimo snapshot era della notte precedente). RTO: due ore e mezza dal momento del primo comando. Senza i tre layer mi sarei trovato a reinstallare e riconfigurare ogni servizio a mano, una giornata buona.

Cosa funziona bene

Più layer = più tranquillità. Anche se un layer si compromette (ransomware su cloud, NAS che muore, password persa), gli altri reggono. Restic deduplica e cifra in modo trasparente: il bucket cloud non vede mai dati in chiaro. Tutto è scriptabile e testabile fuori dall’emergenza.

Limiti

Il DR test è il pezzo che si tende a saltare. Una volta l’anno faccio un ripristino simulato su una macchina nuova, partendo solo dalla password restic e dall’accesso al bucket cloud. è scomodo, ma è l’unico modo per sapere se il piano funziona davvero. Restic verifica integrità via check, ma non garantisce che tu sappia ancora come usarlo dopo dieci mesi che non lo lanci.

In pratica

DR per un homelab non è un progetto enterprise, è una disciplina quotidiana di tre comandi automatizzati e un disco da ruotare ogni tanto. Costa meno di un servizio SaaS, dà più garanzie, ed è l’unica cosa che si parla davvero quando il disco fisico decide che oggi non gli va più di rispondere.

---

Immagine generata con Cloudflare Workers AI / FLUX.

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.