In questo articolo Indice dei contenuti 2 sezioni
Un RAID che continua a funzionare dopo la rottura di un hard disk dà una sensazione di sicurezza che può rivelarsi ingannevole, perché un RAID non è un backup. I file restano accessibili, le macchine virtuali non si fermano e il NAS si limita a segnalare che un’unità va sostituita. È proprio il compito per cui questi sistemi esistono: sopportare certi guasti hardware senza interrompere l’accesso ai dati. Il momento più delicato però arriva spesso dopo, quando si prova a ripristinare la ridondanza ricostruendo sul nuovo disco le informazioni mancanti. Un secondo disco può nascondere settori illeggibili, il controller può aver escluso un’unità ancora sana per un errore temporaneo o un cavo difettoso, e alcune informazioni di parità possono non corrispondere più ai blocchi realmente scritti, magari per una scrittura interrotta all’improvviso. In queste condizioni un’operazione che sembra ordinaria può tradursi in una vera perdita di dati.
Il pericolo nascosto durante la ricostruzione
Si pensi a un RAID 5, che distribuisce dati e parità su almeno tre dischi e tollera il guasto di uno di essi, composto da quattro unità da 12 TB. Quando un disco cede, i blocchi mancanti vengono ricalcolati partendo da quanto conservato sugli altri tre. Una ricostruzione tradizionale può quindi richiedere la lettura di circa 36 TB complessivi dai dischi superstiti. Il guaio è che anche un’unità all’apparenza sana può avere settori che non riesce più a leggere. I produttori indicano nelle specifiche un tasso di errori non recuperabili, chiamato URE (Unrecoverable Read Error). Ipotizzando una probabilità di errore indipendente per ogni bit pari a 1 su un milione di miliardi, leggere 36 TB porterebbe a una probabilità teorica di incontrare almeno un errore vicina al 25%. Questo non vuol dire che il rebuild fallisca una volta su quattro, dato che i valori dichiarati non descrivono una probabilità uniforme e le varie implementazioni reagiscono in modo diverso. Il numero però rende bene l’idea: durante il ripristino il sistema deve accedere anche a dati che magari nessuno legge da tempo. In un array degradato basta un settore illeggibile per compromettere uno o più blocchi, con esiti che vanno dalla perdita di qualche file fino all’interruzione dell’intera procedura.
C’è poi un altro aspetto da non sottovalutare. Non tutti i dischi segnati come guasti hanno davvero un difetto fisico. Un timeout SATA, cioè una richiesta di lettura o scrittura non completata nei tempi previsti, può bastare perché il controller giudichi l’unità inaffidabile. Lo stesso può succedere con un cavo rovinato o collegato male, con un problema al backplane, la scheda che collega i dischi a controller e alimentazione tipica di NAS e server, oppure con un’alimentazione instabile. Il punto critico è il reinserimento: se nel frattempo l’array ha continuato a ricevere scritture, il disco escluso contiene versioni vecchie di alcuni blocchi, e forzarne il rientro senza controllare i metadati significa introdurre informazioni obsolete.
Come controllare lo stato su Linux e Windows
Su Linux il RAID software integrato nel kernel, noto come MD RAID, si gestisce soprattutto con l’utilità mdadm, che permette di esaminare i metadati di ciascun membro. Vale la pena guardare l’identificativo dell’array, il ruolo dell’unità e il contatore Events, utile per capire le differenze nella storia degli aggiornamenti. Un contatore più basso rispetto agli altri dischi è un segnale da approfondire e non certo un via libera per forzare l’assemblaggio, visto che l’opzione force usata alla cieca può peggiorare parecchio le cose.
Su Windows lo scenario cambia. Un controller hardware può presentare al sistema un unico disco logico, e in quel caso servono gli strumenti diagnostici del produttore. Con Storage Spaces, disponibile anche su Windows 11, è invece il sistema operativo a gestire pool di dischi fisici e unità virtuali, mentre Windows Server aggiunge Storage Spaces Direct per distribuire la resilienza tra più server. Da PowerShell con privilegi amministrativi si possono interrogare separatamente dischi fisici e volumi virtuali, distinzione fondamentale: un volume può restare utilizzabile anche dopo un guasto ma senza più la protezione originaria. Microsoft distingue alcuni stati chiave. Incomplete può indicare la mancanza di unità con copie aggiornate, Degraded segnala una resilienza ridotta, mentre No Redundancy indica che il disco virtuale ha già perso dati superando la propria tolleranza ai guasti.
Anche i contatori di affidabilità meritano attenzione, perché un aumento degli errori non corretti o timeout ripetuti contano più di una semplice etichetta Healthy, anche se alcuni controller non espongono questi dati. Nel Visualizzatore eventi gli eventi con ID 129, 153 e 157 possono offrire indizi utili, da leggere sempre insieme alla loro origine. Su Windows Server, infine, aggiungere un disco nuovo non garantisce che il ripristino parta subito: il sistema deve poter ricollocare copie e parità rispettando colonne, disposizione dei dati e domini di errore. Il comando di riparazione del disco virtuale va lanciato solo dopo una diagnosi completa e mai su un pool che mostra ulteriori errori.
Fonte: TecnoAndroid