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.

Articolo originale su rpi.temporiti.net