Un blackout raramente dura più di qualche secondo. Eppure basta a rendere illeggibile un volume RAID o a corrompere un intero file system su un server o un NAS. Contrariamente a un’idea diffusa, il rischio non deriva dall’assenza di alimentazione in sé, ma dall’interruzione brutale di scritture in corso in più livelli di memoria volatile: cache del controller RAID, RAM, cache del disco. Ecco cosa succede realmente in quei pochi secondi, e come limitare il rischio in anticipo.
Cosa succede realmente durante un blackout improvviso
Un server in funzione non scrive mai direttamente sui suoi dischi a ogni operazione. I dati passano attraverso più zone tampone prima di essere fisicamente incisi: la cache del controller RAID, la memoria RAM del sistema, poi la cache interna del disco stesso. Questa architettura migliora considerevolmente le prestazioni, ma ha un costo in caso di blackout: tutto ciò che non è ancora stato scritto sul supporto fisico viene perso, e il file system si trova in uno stato incoerente, quello che si chiama uno spegnimento non sincronizzato (dirty shutdown).
I file system moderni come ext4, Btrfs o ZFS integrano meccanismi di protezione (journaling, copy-on-write) pensati precisamente per questo scenario. Queste protezioni hanno tuttavia dei limiti, in particolare quando il blackout avviene durante una fase di scrittura intensiva o durante una ricostruzione RAID in corso. È in questi momenti di maggiore vulnerabilità che si verificano gli incidenti più seri.
La cache del controller RAID, una protezione da monitorare
Sui server professionali equipaggiati con controller RAID hardware (Dell PERC, HP Smart Array, Broadcom MegaRAID), la modalità di scrittura predefinita è spesso il write-back: i dati sono confermati come scritti non appena arrivano nella cache del controller, ancora prima di essere fisicamente incisi sui dischi. Questa modalità guadagna in prestazioni, ma esporrebbe i dati non ancora scritti in caso di blackout, a meno di essere protetta.
Due tecnologie garantiscono questa protezione:
- Una batteria BBU, la cui durata di vita si aggira generalmente intorno ai 3-5 anni, capace di mantenere la cache sotto tensione per 24-48 ore secondo il modello di controller.
- Supercondensatori, che trasferiscono il contenuto della cache verso una memoria flash in pochi secondi.
Una batteria che invecchia perde progressivamente capacità. Quando un controller rileva una BBU difettosa, normalmente passa da solo in modalità write-through, più lenta ma senza rischi, poiché ogni scrittura viene allora confermata solo una volta incisa sul disco. Forzare manualmente il ritorno alla modalità write-back mentre la batteria è segnalata come difettosa è una pratica da evitare: è esattamente lo scenario che trasforma un blackout banale in un incidente sui dati.
I NAS consumer (Synology, QNAP, Asustor) funzionano diversamente: si basano su RAID software, senza controller hardware dedicato né protezione BBU equivalente. La loro esposizione a un blackout segue quindi una logica distinta, più legata allo stato del file system al momento dello spegnimento che alla cache di un controller.
Il gruppo di continuità: indispensabile, ma non infallibile
Un gruppo di continuità (UPS) svolge due funzioni: fornire un’alimentazione temporanea durante un blackout e filtrare i picchi di tensione che spesso lo accompagnano. Sui NAS, i sistemi operativi come Synology DSM o QNAP QTS sanno rilevare il passaggio su batteria dell’UPS e attivare uno spegnimento pulito del dispositivo prima dell’esaurimento completo dell’autonomia restante.
Il problema più frequente non deriva dall’UPS stesso, ma dalla sua batteria. Le batterie al piombo-acido che equipaggiano la maggior parte degli UPS hanno una durata di vita di 3-5 anni, riducibile in ambienti caldi. Una batteria degradata può resistere solo pochi secondi invece dei minuti necessari per lasciare al NAS il tempo di spegnersi correttamente. Alcune semplici precauzioni limitano questo rischio:
- Programmare un auto-test mensile della batteria.
- Sostituire la batteria ogni 3-5 anni, senza aspettare un segno di debolezza visibile.
- Puntare ad almeno 5 minuti di autonomia reale sotto carico, non solo a vuoto.
Bisogna anche tenere presente ciò che un UPS non fa: non protegge da un guasto dell’alimentazione interna del server, e non sostituisce in alcun modo la protezione BBU di un controller RAID. Sono due dispositivi complementari, non intercambiabili.
Corruzioni diverse secondo il file system
Il comportamento di un volume dopo un blackout dipende direttamente dal file system utilizzato.
ext4
Il journal delle transazioni si riavvia automaticamente al riavvio. La coerenza viene generalmente ritrovata, al prezzo degli ultimissimi secondi di scrittura prima del blackout. Se il journal stesso è corrotto, l’utility e2fsck tenta una ricostruzione, con risultati più incerti.
Btrfs
Il suo funzionamento in copy-on-write lo rende più resiliente in linea di principio. Ma un’interruzione che avviene esattamente durante l’aggiornamento del superblocco può rendere il volume semplicemente impossibile da montare, senza fase intermedia.
ZFS
Generalmente robusto grazie ai suoi checksum sistematici su ogni blocco. Un blackout che avviene durante un resilvering (ricostruzione di un disco sostituito) resta comunque un momento di vulnerabilità reale.
Livello RAID
Un blackout può provocare un’incoerenza di parità, fenomeno noto come write hole. Il bitmap di scrittura (write-intent bitmap sotto mdadm) limita l’estensione della resincronizzazione necessaria in seguito, evitando di dover riverificare l’intero volume.
Tre livelli di protezione complementari
Nessuna protezione isolata basta da sola. La riduzione del rischio si basa su tre livelli che si completano a vicenda:
- Un gruppo di continuità configurato correttamente, con spegnimento automatico programmato del server o del NAS, batteria testata mensilmente e sostituita ogni 3-5 anni, o non appena l’autonomia diventa insufficiente.
- Su un server equipaggiato con un controller RAID hardware: una verifica regolare dello stato della BBU o del supercondensatore tramite gli strumenti forniti dal produttore, e il divieto assoluto di forzare la modalità write-back se viene segnalato un guasto della batteria.
- Un backup secondo la regola 3-2-1 (tre copie, due supporti distinti, una copia fuori sede): è l’unica garanzia reale in caso di sinistro maggiore, indipendentemente dalla robustezza del file system in uso.
I riflessi giusti subito dopo un blackout
Ciò che fai nei minuti successivi al riavvio pesa quanto il blackout stesso sul risultato finale.
- Non interrompere una verifica automatica già in corso (rilettura del journal, verifica Btrfs, resincronizzazione RAID).
- Non lanciare fsck o btrfs check manualmente su un volume degradato: questi strumenti possono eliminare metadati ancora utilizzabili tentando di “riparare” troppo in fretta.
- Rifiutare qualsiasi proposta di reinizializzazione del volume emessa da uno strumento di sistema, anche se sembra la soluzione più rapida.
- Se il sistema resta anomalo nonostante queste precauzioni, spegnerlo correttamente, annotare o etichettare la configurazione esatta dei dischi, e rivolgersi a uno specialista invece di moltiplicare i tentativi.
Un punto merita di essere ricordato più di ogni altro: finché nessuna riscrittura è iniziata sui dischi, i metadati RAID restano generalmente utilizzabili. È esattamente questo margine di tempo che va preservato evitando manipolazioni frettolose.
Un blackout su un server o un NAS professionale non comporta sistematicamente una perdita di dati, ma crea una finestra di fragilità che è meglio anticipare che subire. Se il tuo volume non riparte normalmente dopo un incidente di questo tipo, ogni manipolazione aggiuntiva riduce le possibilità di un recupero completo.