La business continuity non comincia dal cluster ridondato o dal piano di disaster recovery. Comincia molto più in basso: dall'integrità del singolo bit scritto sul disco. Un dettaglio che la maggior parte delle infrastrutture IT, ancora oggi, gestisce male — o non gestisce affatto.
Il problema che nessuno vede
Quando l'amministratore di sistema dice "l'infrastruttura è ridondata", quasi sempre intende ridondanza a livello di nodo, di link, di datacenter. Quello che non viene quasi mai messo in discussione è un assunto silenzioso: che il dato letto dal disco sia uguale a quello che ci era stato scritto.
Non lo è. Statisticamente, su un dispositivo enterprise di buona qualità si verifica un errore non rilevato di lettura ogni circa 10¹⁶ bit transferiti. Su un singolo array di pochi TB, in produzione 24/7, è una questione di mesi prima che un errore silente attraversi la pipeline di lettura senza essere mai accorto. Le fonti possibili sono molte:
- Bit rot: l'inversione spontanea di un bit sul supporto fisico, che si accumula con la vita del device — più frequente su HDD, ma presente anche sugli SSD per fenomeni di "charge leakage" delle celle
- Phantom write: il dato scritto è corrotto ma il checksum interno al blocco è coerente con quel dato corrotto, quindi nessuno se ne accorge
- Phantom read: il sistema legge dal blocco sbagliato e nemmeno il filesystem si accorge dell'errore
- Errori di parità DMA tra controller e memoria del server
- Bug nel firmware del disco — più comuni di quanto si creda, soprattutto sui drive di grossa capacità
- Picchi di corrente che corrompono scritture in corso
- Errori del driver che fa finire i dati nel buffer sbagliato del kernel
La grande maggioranza dei filesystem in produzione oggi (NTFS, ext4, XFS, JFS, UFS) non rileva queste corruzioni. Il dato corrotto viene servito all'applicazione come se fosse buono.
Perché il RAID non basta
L'obiezione tipica è: "ma noi abbiamo il RAID, è ridondato." Il RAID protegge da un guasto fisico esplicito di un disco — quello su cui il controller riceve un errore di lettura SMART o un timeout. Non protegge da un dato scritto male, ma scritto. Non protegge dal phantom write. Non protegge dal bit rot silenzioso. Non rileva nemmeno quando uno dei dischi del mirror legge un valore diverso dall'altro: in quei casi prende uno dei due, in modo tipicamente non deterministico, e procede.
C'è poi un problema strutturale del RAID 5/6 tradizionale, noto come write hole. Se durante una scrittura interviene un evento (caduta di tensione, panic del kernel, fault del controller) tra il momento in cui i dati sono stati scritti su un disco e il momento in cui la parità è stata aggiornata sull'altro, l'array rimane in uno stato inconsistente che può degenerare in danni gravi durante una successiva ricostruzione. Per questo molti sistemi RAID enterprise hanno batterie tampone (BBU) o memoria non volatile sul controller — patch alla radice del problema, non sua soluzione.
ZFS: cos'è e da dove viene
ZFS (Zettabyte File System) nasce nel 2004 dentro Sun Microsystems, sviluppato dal team di Jeff Bonwick. Il suo obiettivo dichiarato era ribaltare l'assunto: l'integrità del dato non è un effetto collaterale, è il requisito di partenza dell'intera architettura. Tutto il resto — le performance, le feature, la scalabilità — viene costruito sopra a questa fondazione.
Il nome originale era un orgoglioso riferimento ai limiti teorici da Zettabyte (1 ZB = 1.000.000.000.000.000.000.000 byte ≈ 909 milioni di TB). Oggi ZFS come marchio è di Oracle, ma il riferimento di fatto per chiunque lo usi seriamente è OpenZFS, l'implementazione open-source mantenuta dalla comunità e disponibile su Linux, FreeBSD, illumos, macOS. È la base di sistemi come TrueNAS, di molti backup target enterprise, e di non poche soluzioni storage scale-out.
Le quattro idee chiave
1. Copy on write — non sovrascrivere mai
Quando un blocco di dati viene modificato, ZFS non sovrascrive il blocco originale. Scrive il nuovo dato in un blocco libero, calcola i nuovi metadati, e solo alla fine — atomicamente — sposta il puntatore della radice del filesystem. Finché quell'ultimo passo non è completato, l'intero "albero vecchio" del filesystem è ancora valido e accessibile.
Conseguenza diretta: ZFS è permanentemente consistente. Una caduta di corrente o un kernel panic non possono lasciarlo in uno stato inconsistente. Niente bisogno di journaling, niente fsck, niente verifying al riavvio. Lo stato sul disco è sempre uno stato valido.
Conseguenza indiretta: il problema del write hole del RAID classico semplicemente non esiste in RAID-Z (l'equivalente RAID di ZFS). Le scritture sono atomiche al livello del filesystem, non al livello del singolo blocco.
2. Checksum end-to-end (albero Merkle)
Per ogni blocco di dati ZFS calcola un checksum (storicamente SHA-256, oggi anche Fletcher4, Edon-R, Skein, Blake3 a seconda dei casi). Il punto fondamentale è dove questo checksum viene salvato: non dentro il blocco stesso (come fanno tutti gli altri filesystem), ma dentro il puntatore al blocco — cioè in un blocco diverso. A sua volta quel puntatore è dentro un altro blocco, anch'esso con un proprio checksum salvato nel suo puntatore padre. La gerarchia risale fino all'uberblock, l'unico blocco con un checksum auto-validante.
La struttura risultante è un albero di Merkle: dato un uberblock validato, ogni blocco dell'intero pool può essere verificato. Ogni volta che un blocco viene letto, ZFS ricalcola il suo checksum e lo confronta con il valore atteso registrato nel puntatore. Se i due valori non coincidono, ZFS sa con certezza che quel blocco è corrotto — non per intuizione, ma per dimostrazione crittografica.
Questo risolve il phantom write: anche se il disco riporta che la scrittura è andata a buon fine, e anche se il blocco letto sembra coerente con sé stesso, ZFS lo confronta con un checksum salvato altrove. La probabilità che entrambi siano stati corrotti nello stesso modo è negligibile.
3. Self-healing
Quando ZFS rileva un blocco corrotto e il pool ha ridondanza disponibile (mirror o RAID-Z), il file system non si limita a segnalare l'errore: ripara. Recupera la copia integra dalla ridondanza, ricalcola il checksum, lo confronta — e se tutto torna, sovrascrive la copia danneggiata sul disco originale. La riparazione è automatica e trasparente all'applicazione.
Questa operazione è chiamata scrub quando viene eseguita proattivamente su tutto il pool (consigliata su base settimanale o mensile a seconda dei carichi). È il modo per scoprire e correggere il bit rot prima che il bit corrotto venga effettivamente letto da un'applicazione.
4. Snapshot come primitiva, non come funzione
Poiché ZFS non sovrascrive mai i blocchi, "fare uno snapshot" non significa copiare niente: significa semplicemente congelare il puntatore alla radice del filesystem in quel momento e impedire al garbage collector di liberare i blocchi che vi appartengono. Il costo computazionale è praticamente nullo. Il limite teorico di snapshot per filesystem è 2⁴⁸ — circa 280.000 miliardi.
Per la business continuity questa è una proprietà preziosissima: significa poter avere snapshot orari (anche su scala mensile) senza pagare un costo significativo né in spazio né in performance, a meno della quantità di dati effettivamente cambiati tra uno snapshot e l'altro. È anche la fondazione per la replica incrementale verso un sito remoto (zfs send | zfs receive), uno dei modi più puliti che esistano per fare disaster recovery basato su filesystem.
Le tre cache (ARC, L2ARC, ZIL)
Una nota tecnica per capire perché ZFS performa anche in scenari ostici. Tre componenti lavorano insieme:
- ARC (Adaptive Replacement Cache) — cache di lettura in RAM, gestita con un algoritmo proprietario che bilancia "frequenza" e "recente": tendenzialmente più efficiente del classico LRU dei filesystem tradizionali
- L2ARC — secondo livello di cache di lettura tipicamente su SSD, popolato dai dati che escono dall'ARC ma che restano "interessanti"
- ZIL (ZFS Intent Log) — log persistente delle scritture sincrone, usato per garantire la durabilità senza dover aspettare il flush completo allo storage primario
L'effetto combinato è che ZFS riesce a tenere alte le performance anche su pool con grosse quantità di dischi rotazionali, sfruttando SSD veloci come acceleratore.
Cosa significa, in pratica
ZFS non è la risposta a tutto: è una tecnologia complessa, vorace di RAM (la regola pratica è 1 GB ogni TB di pool, di più con deduplica attiva), e ha un percorso di adozione lungo. Non sostituisce un'infrastruttura iperconvergente moderna, e spesso non è la scelta giusta per un cluster VMware o Nutanix di produzione, dove ci sono altre risposte ai problemi di integrità (es. RAIN nei sistemi software-defined).
Dove ZFS dà il meglio è in tre scenari concreti:
- Backup target — il "secondo livello" dove i backup vengono scritti e devono restare integri per anni. Combinazione di compression, deduplica, checksum end-to-end e snapshot rende ZFS una delle migliori opzioni in assoluto
- NAS dipartimentali e archivi — file di progetto, repository di dati di laboratorio, archivi documentali con retention pluriennale
- Storage per dati di valore "lungo" — laddove la corruzione silenziosa di un dato vecchio scoperto dopo cinque anni significa un problema serio (cartelle cliniche storiche, dati di ricerca, archivi legali)
La lezione che resta
Anche per chi non userà mai ZFS direttamente, capire perché esiste è utile. Significa fare le domande giuste sull'infrastruttura che si possiede:
- Il filesystem o lo storage in uso ha checksum end-to-end veri, o si fida del disco?
- Il piano di backup ha controlli di integrità periodici sui dati scritti — non solo "il job è andato a buon fine"?
- Sappiamo dire, dopo cinque anni, quanti dei nostri archivi sono ancora bit-perfect rispetto al momento della scrittura?
La business continuity comincia dal cluster, ma non finisce lì. Comincia, soprattutto, dal singolo bit. Un dato corrotto che entra silenziosamente in un backup è una bomba a orologeria: prima o poi viene ripristinato, e ti accorgi del problema esattamente nel momento in cui non puoi permettertelo.
Il tema dell'integrità del dato è uno dei più sottovalutati nelle infrastrutture italiane. Non perché manchino le tecnologie: perché è invisibile finché non scoppia.