Un disco si guasta nel tuo array RAID 5 o RAID 6. Il controller passa in modalità degradata e propone di avviare la ricostruzione (rebuild) per ricalcolare i dati mancanti a partire dalla parità. È esattamente in questo momento, ancora prima di confermare l’avvio, che si decide il destino dei tuoi dati: un rebuild avviato male trasforma un guasto perfettamente recuperabile in una perdita totale del volume.
Cosa succede realmente durante una ricostruzione
Nei RAID a parità (5 o 6), il guasto di un disco fa passare l’array in modalità degradata: il controller ricalcola al volo il contributo del disco mancante a partire dalla parità memorizzata sugli altri dischi, ma senza alcun margine di tolleranza aggiuntivo. Il rebuild va oltre: legge l’intero contenuto di ogni disco superstite per ricostruire i dati del disco di sostituzione.
Un ordine di grandezza basta a far capire la posta in gioco: su un array RAID 5 di 4 dischi da 16 TB, una ricostruzione comporta circa 48 TB di letture sequenziali distribuite sui 3 dischi restanti. Questo volume enorme, combinato a uno stress meccanico prolungato e a una ridondanza scesa a zero, rende il rebuild la finestra più pericolosa nel ciclo di vita di un array RAID.
Perché un rebuild può fallire
Diversi fattori si combinano e spiegano perché tante ricostruzioni vanno male:
- Gli errori di lettura irrecuperabili (URE). In RAID 5 degradato, un solo URE su un disco superstite basta a perdere definitivamente i dati corrispondenti, senza una seconda possibilità. Incrociando il tasso di errore di lettura irrecuperabile pubblicato dai produttori (nell’ordine di un errore ogni 1014 bit letti su un disco consumer) con il volume da rileggere durante un rebuild, il rischio si attesta intorno al 3-4% su un array RAID 5 di dischi da 6 TB — e scende a una frazione di punto percentuale in RAID 6, grazie alla doppia parità.
- Lo stress meccanico prolungato, che può estendersi su ore o addirittura giorni, sollecita in continuo tutti i dischi superstiti.
- L’usura omogenea dell’array: i dischi di uno stesso raccoglitore condividono spesso lo stesso modello, lo stesso firmware e le stesse ore di funzionamento. Quando uno cede, gli altri di solito non sono lontani dal seguirlo. In laboratorio, un secondo disco che si guasta durante o subito dopo il rebuild non ha nulla di eccezionale.
I 5 errori che trasformano un guasto recuperabile in una perdita totale
La maggior parte delle perdite di dati definitive osservate dopo un rebuild non deriva dal guasto iniziale, ma dal modo in cui la ricostruzione è stata condotta.
- Avviare il rebuild senza aver prima clonato i dischi. È l’errore più comune e con le conseguenze più gravi: se la ricostruzione fallisce durante il processo, i dati originali vengono alterati in modo definitivo, senza una copia di riserva su cui tornare.
- Forzare la rimessa in linea di un disco dichiarato guasto. Un disco segnato come “fuori servizio” a volte ha semplicemente un problema di cablaggio. Forzarlo spinge il controller a ricalcolare la parità partendo da dati obsoleti, il che provoca una corruzione silenziosa, senza alcun messaggio di errore visibile a schermo.
- Sbagliare l’ordine fisico dei dischi dopo aver smontato il raccoglitore. La ricostruzione parte allora da dati disordinati e sovrascrive sia i dati utente che la parità originale.
- Ricostruire con parametri errati: dimensione dello stripe, algoritmo di parità o offset di origine sbagliati. La struttura logica del volume ne esce corrotta in modo irrimediabile.
- Lanciare CHKDSK o FSCK su un volume RAID degradato. Questi strumenti modificano i metadati per ripristinare una coerenza del file system. Di fronte a una corruzione a livello RAID, possono distruggere le ultime tracce utilizzabili per un recupero professionale.
Quanto dura un rebuild, e la trappola dei dischi SMR
Su dischi da 16-20 TB in ambiente di produzione, conta generalmente 2-7 giorni, a volte più di una settimana con carico applicativo elevato. Un parametro tecnico spesso aggrava la situazione senza che l’utente ne sia consapevole: i dischi SMR (Shingled Magnetic Recording), usati per il loro costo contenuto, possono moltiplicare la durata della ricostruzione da 13 a 16 volte rispetto a dischi CMR equivalenti. Su un array già degradato, questa durata prolungata aumenta di conseguenza l’esposizione al rischio e può rivelarsi fatale.
Il disco di riserva (hot spare) non è una soluzione miracolosa
Un hot spare riduce certamente il tempo passato in modalità degradata, poiché il rebuild parte automaticamente non appena viene rilevato un guasto. Ma questo automatismo ha un rovescio della medaglia: la ricostruzione si avvia senza una diagnosi preliminare, senza verificare lo stato reale dei dischi superstiti né la presenza di un backup utilizzabile. In caso di guasto logico (ransomware, cancellazione accidentale, corruzione applicativa piuttosto che guasto hardware), questo rebuild automatico non corregge nulla: si limita a propagare il problema sul disco nuovo.
I livelli RAID di fronte al rebuild, in breve
| Livello | Tolleranza ai guasti | Rischio al rebuild | Durata tipica |
|---|---|---|---|
| RAID 0 | Nessuna | Perdita totale immediata | N/A |
| RAID 1 | 1 disco | Molto basso | Alcune ore |
| RAID 5 | 1 disco | Elevato su grande capacità | 2-7 giorni |
| RAID 6 | 2 dischi | Basso a moderato | 2-7 giorni |
| RAID 10 | 1 per coppia | Molto basso | Alcune ore |
Cosa fare prima di rilanciare qualsiasi cosa
Di fronte a un array in modalità degradata, la prudenza conta più della velocità. Ecco l’ordine di azioni da seguire:
- Documenta lo stato esatto dell’array: log del controller, ordine fisico dei dischi, livello RAID, dimensione dello stripe.
- Avvia un backup immediato se l’array resta accessibile in lettura.
- Clona ogni disco superstite a livello di settore prima di qualsiasi rebuild, non appena l’importanza dei dati lo giustifica.
- Verifica lo stato SMART dei dischi restanti prima di procedere oltre.
- Scegli un disco di sostituzione adeguato: stessa interfaccia, capacità identica o superiore, gestione TLER/ERC compatibile con il tuo controller.
- Riduci al massimo il carico applicativo per tutta la durata del rebuild.
Quando passare da un laboratorio invece di riprovare da solo
Alcune situazioni non perdonano l’improvvisazione, anche con le migliori intenzioni:
- Due o più dischi sono guasti: l’array RAID 5 è perduto, un RAID 6 dispone di un po’ più di margine ma resta critico.
- Una prima ricostruzione è già fallita. Un rebuild parziale peggiora quasi sempre la situazione iniziale.
- Il controller RAID stesso sembra difettoso, con un rischio reale di sovrascrivere metadati ancora validi.
- Il guasto è di natura logica (ransomware, cancellazione): in questo caso, il rebuild si limita a propagare lo stato corrotto invece di correggerlo.
In queste configurazioni, ogni tentativo aggiuntivo riduce le possibilità di recupero. Un laboratorio specializzato lavora su copie a livello di settore, offline, con una diagnosi preliminare che manca proprio in un rebuild automatico.
Il RAID non è un backup
È il messaggio che merita di essere ripetuto: un rebuild riuscito non protegge né da una cancellazione accidentale, né da un ransomware, né da un sinistro che colpisse l’intero raccoglitore. Il RAID garantisce la disponibilità di fronte a un guasto hardware isolato, nulla più. Niente sostituisce una vera strategia di backup 3-2-1, testata regolarmente, per coprire gli scenari che la sola ridondanza non può gestire.
Se il tuo array è in modalità degradata, se un rebuild è già andato male o se hai dei dubbi prima di avviare la ricostruzione, un parere tecnico prima di qualsiasi altra manipolazione può fare la differenza tra un guasto recuperabile e una perdita definitiva.