I miei dati non sono protetti come pensavo. Scrivo questa frase dopo aver passato un pomeriggio a guardare dentro il mio cluster con occhi diversi — quelli di chi deve documentare ogni cosa per una serie di post. Ho scoperto che il backup offsite è vuoto, che il "mirror" di pve2 non è un mirror, e che 33 GB di backup vivono sullo stesso disco del sistema operativo. Questo post è il resoconto di quello che funziona, di quello che non funziona, e di come intendo sistemarlo.
Cosa funziona vs cosa no — la mappa reale
Prima di entrare nei dettagli, ecco lo stato reale del mio storage e backup al 16 aprile 2026. Il verde non significa "perfetto" — significa che fa il suo lavoro. Il rosso è dove devo intervenire.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Self-Hosting
Installare NAKIVO su Proxmox 9.1: setup Debian 12 in 3 dettagli
Tutorial end-to-end di NAKIVO Backup & Replication v11.2 su LXC Debian 12 in Proxmox VE 9.1. Tre minuti di install, 90 secondi di licenza, 3 dettagli del setup che ti fanno risparmiare mezz'ora: uno è asimmetria Debian/Ubuntu, due sono errori da primo tentativo.
Funziona — 66 GB usati, 31% di 216 GB
Componenterpool (boot drive)
Nodopve2
TipoSingolo
StatoFunziona — 3% usato
Componentezfs-mirror-ssd (NVMe)
Nodopve2
TipoSingolo (nome fuorviante)
StatoContiene repliche, zero ridondanza
ComponenteReplica ZFS cross-node
Nodopve → pve2
TipoIncrementale ogni 15 min
StatoFunziona — 10 CT, zero errori
Componentebackup-ssd
Nodopve
TipoDataset ZFS su pool dedicato
StatoFunziona — 66 GB di backup su zfs-single-ssd
Componentebackup-pve2 (offsite)
Nodopve2
TipoDirectory su rpool
StatoVuoto — storage irraggiungibile dal nodo pve
ComponenteBackup cloud/geografico
Nodo—
Tipo—
StatoNon esiste
Componente
Nodo
Tipo
Stato
zfs-mirror-ssd (2x SSD)
pve
Mirror ZFS
Funziona — zero errori, scrub pulito
zfs-single-ssd (1x SSD)
pve
Pool dedicato ai backup
Funziona — 66 GB usati, 31% di 216 GB
rpool (boot drive)
pve2
Singolo
Funziona — 3% usato
zfs-mirror-ssd (NVMe)
pve2
Singolo (nome fuorviante)
Contiene repliche, zero ridondanza
Replica ZFS cross-node
pve → pve2
Incrementale ogni 15 min
Funziona — 10 CT, zero errori
backup-ssd
pve
Dataset ZFS su pool dedicato
Funziona — 66 GB di backup su zfs-single-ssd
backup-pve2 (offsite)
pve2
Directory su rpool
Vuoto — storage irraggiungibile dal nodo pve
Backup cloud/geografico
—
—
Non esiste
Sei verdi, due rossi. In un datacenter ti licenziano. In un homelab ci scrivi un post.
ZFS mirror su pve: l'unica cosa che dorme tranquilla
Il nodo principale — pve, Ryzen 7 1800X, 47 GB RAM — ha un vero mirror ZFS con due SSD da 222 GB. Tutti e dieci i container LXC girano qui: Forgejo, n8n, Grafana, Authentik, il blog stesso. Se uno dei due dischi muore, ZFS continua a servire i dati dal disco sopravvissuto. Replace il disco guasto, lanci il resilver, torni alla ridondanza. Nessun downtime.
bash
# zpool status zfs-mirror-ssd (pve)
NAME STATE READ WRITE CKSUM
zfs-mirror-ssd ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x500a0751e5aa3e32 ONLINE 0 0 0
wwn-0x500a0751e5ad0705 ONLINE 0 0 0
scan: scrub repaired 0B in 00:01:31 on Sat Apr 12 2026
Scrub settimanale, un minuto e mezzo, zero errori riparati. Con 28 GB usati su 222, lo spazio non è un problema. Questo pool è la parte del mio storage di cui mi fido.
La replica cross-node completa il quadro: ogni 15 minuti, tutti e 10 i CT vengono replicati da pve a pve2 via ZFS send/receive incrementale. Durate dai 2.6 secondi di Grafana ai 18.8 di MyTrainingApp, tutti con fail_count a zero. L'ho documentata nella Parte 2 sul cluster Proxmox, ma qui il dato rilevante è il recovery point: se pve esplode, perdo al massimo 15 minuti di modifiche. Gli snapshot di replica — nominati __replicate_CTID-0_TIMESTAMP__ — vengono creati ad ogni send e sono visibili su entrambi i nodi.
Oltre alla replica, due container hanno protezioni aggiuntive. Forgejo — il mio Git server — ha snapshot giornalieri automatici con 7 giorni di history, perché il codice sorgente è la cosa più difficile da ricostruire. AIWALL viene snapshottato manualmente prima di ogni deploy — l'ultimo è di stanotte, tag pre-deploy-20260420. Se un aggiornamento rompe qualcosa, il rollback è un zfs rollback e via.
I due buchi che ho scoperto scrivendo questo post
Scrivere questa serie mi sta costando più in dignità che in ore. Ogni volta che apro un terminale per raccogliere dati, trovo qualcosa che non va. Questa volta ne ho trovati due, e il primo è quello che mi ha fatto sentire più stupido.
Il "mirror" che non è un mirror. Su pve2 c'è uno storage che si chiama zfs-mirror-ssd. Lo vedevo nella GUI di Proxmox, leggevo "mirror" e mi sentivo protetto. Poi, preparando i dati per questo post, ho fatto zpool status su pve2 e ho trovato un singolo NVMe da 464 GB. Nessun mirror-0, nessun secondo disco. Il nome viene dalla configurazione condivisa di storage.cfg — su pve è un mirror reale con due SSD, su pve2 è un disco singolo che ha ereditato lo stesso nome. Ci sono cascato per mesi. Tutte le repliche ZFS dei miei 10 container vivono su quel disco. Se l'NVMe muore, il failover non ha più dati su cui ripartire.
I backup vivono sullo stesso nodo dei container. Tutti i job vzdump scrivono su backup-ssd, un dataset ZFS montato su un pool dedicato (zfs-single-ssd, 216 GB su SSD separato). Questa parte è sana — disco fisicamente distinto da quello del sistema e da quello dei container. Il problema è che quel disco sta dentro pve, lo stesso nodo dei dieci LXC. Se la macchina fisica muore — scheda madre, alimentatore, incendio localizzato — i container scompaiono e con loro i 66 GB di backup storici. La regola 3-2-1 chiede che almeno una copia viva altrove: per questo esiste il job offsite verso pve2. Che però non funziona — il prossimo buco.
Il backup offsite vuoto. Ho un quinto job vzdump — backup-offsite-pve2 — che dovrebbe girare ogni domenica alle 04:00 e scrivere 8 container sul nodo pve2. Ho guardato la directory di destinazione: vuota. Zero file. Poi ho aperto il journal e l'errore era lì, scritto in chiaro dal 19 aprile alle 04:00:
bash
pvescheduler[...]: could not activate storage 'backup-pve2':
storage 'backup-pve2' is not available on node 'pve'
La radice del problema: backup-pve2 è una directory locale sul nodo pve2, ma il job vzdump viene lanciato dalla scheduler del nodo pve — dove girano i container. Proxmox non può attivare uno storage di tipo dir su un nodo remoto. Serve un meccanismo condiviso: NFS export da pve2, un Proxmox Backup Server, o far eseguire il job direttamente dal nodo pve2. Finché non lo fisso, l'unica copia dei miei dati fuori da pve non esiste.
Backup vzdump: 5 job stratificati per criticità
Al netto dei buchi, la struttura dei backup ha una logica: non tutto ha la stessa importanza, e non tutto merita lo stesso spazio disco.
I container critici — Forgejo con il codice sorgente, n8n con le automazioni, le app in produzione — vengono backuppati ogni sera con 7 giorni di retention giornaliera e due copie mensili. L'infrastruttura che cambia raramente — Grafana, Authentik, il reverse proxy — solo il sabato. AIWALL ha un job dedicato perché è il componente che aggiorno più spesso.
La compressione zstd tiene le dimensioni ragionevoli: Forgejo pesa meno di 1 GB, AIWALL circa 3 GB. Con la retention attuale, 66 GB totali stanno dentro il pool dedicato. Il margine c'è, ma si restringe ogni volta che aggiungo un container al backup.
Scenari di disaster recovery: cosa sopravvive e cosa no
Ho mappato cinque scenari di failure, dal più gestibile al catastrofico. Sapere prima cosa succede in ogni caso è la differenza tra un'ora di downtime e un weekend a ricostruire tutto. Per il meccanismo di failover HA rimando alla Parte 1 sulla filosofia del homelab.
Muore 1 SSD del mirror su pve — zero downtime. ZFS continua dal disco sopravvissuto, replace + resilver per tornare alla ridondanza. Lo scenario più gestibile.
Muore il disco root di pve — il sistema cade, i 10 CT ripartono su pve2 via HA e replica ZFS in 30-60 secondi. I backup storici su zfs-single-ssd sopravvivono, perché sono su un disco fisico diverso.
Muore l'intero nodo pve (board, PSU, incendio locale) — i CT ripartono su pve2 via replica, ma i backup storici su zfs-single-ssd scompaiono col nodo. Senza offsite funzionante, niente versioni precedenti: hai solo lo snapshot di replica più recente, massimo 15 minuti indietro.
Muore l'NVMe di pve2 — le repliche spariscono. pve continua normalmente, ma il failover non ha più dati. Sei senza rete di sicurezza finché non sostituisci il disco.
Muoiono entrambi i nodi — tutto perso. Zero backup offsite significa zero recovery.
Incendio, allagamento, furto — tutto perso. Tutto nella stessa stanza, stesso UPS, stesso punto di failure.
Lo scenario 3 è quello che mi preoccupa di più. Non perché sia probabile, ma perché è subdolo: l'HA funziona, i container ripartono da replica, e potresti pensare che sia tutto a posto. Ma i backup storici — le versioni di 3, 7, 30 giorni fa — sono andate col nodo. E due container critici, Intervento Facile e MyTrainingApp, non sono nemmeno nel job offsite: replicati via ZFS, ma senza backup dedicato fuori dal nodo principale.
La segmentazione di rete documentata nella Parte 3 su VLAN, firewall e VPN isola i servizi tra loro, ma non protegge da un failure fisico. Rete e storage sono problemi diversi, e il secondo è quello che sto trascurando.
Il piano per chiudere i buchi. Non ho ancora risolto niente — ma ho una lista chiara, in ordine di priorità:
Fixare lo storage backup-pve2 (NFS export da pve2, o Proxmox Backup Server) così il job offsite può scrivere davvero — 30 minuti di configurazione, zero costi hardware
Aggiungere CT 114 e 115 al job offsite — copertura completa su pve2
Aggiungere un secondo NVMe su pve2 per creare un vero mirror — circa 35-40 euro per un 500 GB
Backup geografico: rsync notturno su un VPS o bucket S3-compatibile — l'unica protezione contro lo scenario "stessa stanza"
Il costo per passare da "parzialmente protetto" a "regola 3-2-1 reale" è sotto i 100 euro di hardware e un paio d'ore di configurazione. Non è un problema di budget. È un problema di consapevolezza — e finché non ho scritto questo post, non sapevo quanto fosse fragile quello che avevo costruito.
Il fix è in corso mentre scrivo
Nel pomeriggio ho messo mano ai due buchi veri. Il mirror fake su pve2 aspetta un NVMe da 35 euro — ordinabile in qualsiasi momento. Ma l'offsite geografico, quello che mi preoccupava di più, è partito oggi.
La scelta è un Hetzner Storage Box BX11: 1 TB a 3.90 euro al mese IVA inclusa (3.20 + IVA tedesca), datacenter Falkenstein, Germania. Non è una sponsorizzazione — è una scelta tecnica. I criteri erano quattro: privacy EU con GDPR nativo, supporto restic documentato, SSH/SFTP senza overhead da spiegare nei post, prezzo da caffè. Hetzner li copre tutti.
L'engine è restic con crittografia AES-256 client-side. La passphrase vive solo su pve2 (file a 0600, solo root). Hetzner riceve blob cifrati e indicizzati, non può leggere i miei dati anche volendo. Zero-knowledge reale, non marketing.
Il giro completo
text
CT su pve --> vzdump --> /backup-ssd (pool dedicato)
|
v
rsync su LAN 1 Gbit
|
v
/backup-ssd-mirror (pve2)
|
v
restic cifra + deduplica
|
v
Hetzner Storage Box (Falkenstein, EU)
Lo scope iniziale copre sei container di produzione: blog, app differenziata-facile, Forgejo, reverse proxy, Authentik, n8n. Stimati 27 GB al primo upload — dopo dedupe restic, meno. Rate limit a 512 KiB/s, il 29% del mio upload FTTC: il blog resta reattivo per gli utenti mentre il backup carica in background. Cron alle 01:00 ogni notte, flock per evitare overlap se un run sfora. Heartbeat push su Uptime Kuma dopo ogni successo, alert email via Resend se il monitor non riceve heartbeat entro 25 ore.
Cosa ancora non copre. Lo scenario "tutto in fiamme" richiede una copia in un sito fisicamente diverso, non solo in un datacenter diverso. Hetzner Falkenstein protegge dall'incendio a casa mia, ma non dal ransomware che critta prima i dati e poi i backup raggiungibili via rete. Il prossimo passo che sto valutando è una copia offline in un altro sito fisico — scollegata tra una run e l'altra — per alzare ulteriormente il livello. Modalità e tempi li vedremo in un post dedicato.
Il verdetto
ZFS mirror affidabile su pve, replica cross-node ogni 15 minuti, backup stratificati su disco dedicato con retention sensata. Mancava l'offsite funzionante e un secondo NVMe su pve2. Il primo è in moto da stasera: restic cifrato verso Hetzner parte alle 01:00, 3.20 euro al mese per 1 TB in EU. Il secondo aspetta 35 euro di hardware e una serata. Sotto i 50 euro e una settimana mi separano dalla regola 3-2-1 reale. Era ora.
Testalo adesso, non domani
Quando hai fatto l'ultimo restore reale dal tuo backup? Non lanciato — testato ripristinando un file. Se non ricordi, apri il terminale. Non domani: adesso. Un backup che non hai mai restituito è una speranza, non un backup.
