Sostituzione di un'unità guasta in un array mdadm su Ubuntu

Le informazioni contenute in questo post si basano su Ubuntu 18.04 e sulla versione di mdadm inclusa nei suoi repository; al momento della stesura, v4.1-rc1. Potrebbero essere valide o meno per altre versioni.

Di recente ho avuto un guasto improvviso al disco del mio file server domestico, composto da nove unità in un array mdadm RAID-6. È sempre spaventoso, ma fortunatamente sono riuscito a procurarmi rapidamente un disco sostitutivo, che mi è stato consegnato il giorno successivo, così ho potuto iniziare la ricostruzione.

Devo ammettere che sono stato un po' troppo tirchio quando ho configurato il file server; solo due delle unità sono vere e proprie unità NAS (Seagate IronWolf), mentre le altre sono unità desktop (Seagate Barracuda). Non sorprende che fosse una delle unità desktop ad aver ceduto (dopo quasi tre anni di servizio, però). Era completamente morta; dopo averla spostata in un box USB desktop, tutto ciò che ho sentito è stato un fastidioso clic e né Ubuntu 20.04 né Windows 10 sono stati in grado di rilevarlo.

Bene, passiamo al pezzo di ricambio (e sì, il nuovo disco che ho comprato era un IronWolf, lezione imparata): per quanto spaventoso sia perdere un disco in un array in funzione, lo è ancora di più se non si conosce la procedura corretta per sostituirlo. Non è la prima volta che devo sostituire un disco guasto in un array mdadm, ma fortunatamente è così raro che di solito devo cercare i comandi giusti. Questa volta ho deciso di creare una mia piccola guida per riferimento futuro.

Quindi, prima di tutto, quando si riceve la temuta e-mail di errore da mdadm, è necessario identificare l'unità guasta. Certo, verrà indicato il nome del dispositivo (nel mio caso /dev/sdf), ma probabilmente non è ovvio quale sia effettivamente l'unità fisica, poiché i nomi possono cambiare all'avvio della macchina.

Se non sei nemmeno sicuro di quale nome del dispositivo non sia riuscito, puoi usare il seguente comando per scoprirlo (sostituisci /dev/md0 con il tuo dispositivo RAID):

Come accennato, nel mio caso era /dev/sdf, quindi continuiamo con quello.

Quindi, puoi provare a trovare il numero di serie dell'unità guasta emettendo questo comando:

(se smartctl non viene trovato, è necessario installare il pacchetto smartmontools su Ubuntu)

Il numero di serie può quindi essere confrontato con i numeri di serie presenti sull'etichetta fisica delle unità per individuare quella difettosa.

Questa volta, però, non sono stato così fortunato. L'unità era completamente morta e si rifiutava persino di fornire dati SMART o di altro tipo, incluso il numero di serie.

Dato che avevo accesso fisico al server (cosa di cui hai davvero bisogno se devi sostituire un disco fisico da solo, suppongo ;-)) e il server era effettivamente in funzione quando il disco si è rotto (e ha continuato a funzionare correttamente grazie alla ridondanza RAID-6), ho optato per il metodo davvero primitivo, ma in realtà molto efficace e ovvio, di copiare semplicemente un file di grandi dimensioni sul server e osservare quale spia dell'HDD non lampeggiava. In pochi secondi avevo identificato il colpevole.

Ora, prima di estrarre l'unità fisica, è una buona idea informare formalmente mdadm di questa intenzione, emettendo questo comando (sostituisci i nomi dei dispositivi con i tuoi, se necessario):

In caso di successo, mdadm risponderà con un messaggio che informa che l'unità è stata "rimossa a caldo", apparentemente perché il dispositivo raid virtuale è effettivamente in esecuzione in quel momento.

Se l'operazione fallisce con un messaggio di errore simile a "dispositivo o risorsa occupata", è possibile che mdadm non abbia effettivamente registrato l'unità come completamente guasta. Per farlo, esegui questo comando (ricordati di sostituire i nomi dei dispositivi con i tuoi, se necessario):

Dopodiché dovresti essere in grado di rimuovere il dispositivo dall'array con il comando precedente.

Ora è il momento di sostituire effettivamente l'unità. Se sei davvero, davvero, davvero certo che la tua macchina e il controller supportino l'hot swapping, puoi farlo senza spegnere la macchina. Questa sarebbe la soluzione migliore per sistemi di produzione critici che girano su hardware server reale e di cui sei sicuro che possa gestirlo. Il mio file server domestico è basato su una scheda madre desktop di fascia consumer con un paio di controller SATA semi-noname negli slot PCIe per fornire più porte SATA.

Sebbene SATA in genere supporti la sostituzione a caldo, non avevo intenzione di rischiare nulla con questa configurazione, quindi ho optato per spegnere il computer durante la sostituzione dell'unità.

Prima di procedere, è consigliabile commentare il dispositivo RAID nel file /etc/fstab in modo che Ubuntu non tenti di montarlo automaticamente al successivo avvio, perché potrebbe bloccarsi e forzare l'utente a passare alla modalità di ripristino a causa del RAID degradato. Questo potrebbe non essere un grosso problema se si tratta di un sistema desktop, ma io eseguo questo server in modalità headless, senza monitor o tastiera collegati, quindi potrebbe essere un po' fastidioso.

Dopo aver avviato il computer con il nuovo disco installato, usa lsblk o un altro metodo per identificarlo. Se non hai modificato nient'altro, probabilmente (ma non necessariamente) avrà lo stesso nome del disco sostituito. Nel mio caso sì, quindi anche il nuovo disco si chiama /dev/sdf.

Poiché il mio array si basa su partizioni anziché su dispositivi fisici, ho dovuto copiare la tabella delle partizioni da un'unità funzionante a quella nuova per assicurarmi che fossero esattamente le stesse. Se invece esegui l'array su dispositivi fisici, puoi saltare questo passaggio.

A questo scopo ho utilizzato sgdisk, copiando la tabella delle partizioni da /dev/sdc a /dev/sdf. Assicuratevi di sostituire i nomi dei dispositivi con quelli corretti.

Nota l'ordine qui: inserisci prima l'unità "a"! Per me è un po' controintuitivo, ma assicurati di farlo correttamente per evitare un altro guasto dell'unità nell'array ;-)

Quindi, per evitare conflitti UUID, generare nuovi UUID per la nuova unità:

E ora è finalmente giunto il momento di aggiungere la nuova unità all'array e dare inizio alla ricostruzione! (Ok, non è proprio una festa, è in realtà un processo piuttosto lento e snervante, perché non vorrai di certo che un'altra unità si guasti in questo momento. Una birra potrebbe aiutare, però)

In ogni caso, per aggiungere la nuova unità all'array, emetti questo comando (assicurati di nuovo di sostituire i nomi dei dispositivi con i tuoi, se necessario):

Se tutto va bene, l'unità verrà aggiunta all'array senza intoppi. Credo che in realtà venga aggiunta come "hot spare" di default, ma poiché a questo array manca un disco (quello che si è rotto), viene immediatamente messo in uso e il processo di ricostruzione avrà inizio.

Puoi tenerlo d'occhio in questo modo:

Probabilmente ci vorrà un po' di tempo; sul mio modesto server (basato in gran parte su hardware di fascia consumer e unità desktop, badate bene) è riuscito a raggiungere poco meno di 100 MB/sec. Tenete presente che si tratta di un RAID-6, quindi la ricostruzione richiede molti calcoli di parità; un RAID-10 sarebbe stato molto più veloce. Questa macchina in particolare ha una CPU quad-core AMD A10 9700E (la "E" indica un modello a basso consumo energetico, ovvero non superveloce), giusto per darvi un'idea di cosa aspettarvi. Con i nove dischi da 8 TB nella mia configurazione, la ricostruzione completa ha richiesto poco più di 24 ore.

Durante la ricostruzione, è possibile montare il file system sull'array e utilizzarlo normalmente, se lo si desidera, ma io preferisco lasciare che sia la ricostruzione a occuparsene finché non è completata. Tenete presente che se un'unità si guasta, un'altra potrebbe presto seguire, quindi è opportuno che la ricostruzione venga eseguita il più rapidamente possibile, poiché non si desidera che un'altra unità si guasti durante la ricostruzione. Pertanto, non sovraccaricatela con altre operazioni di I/O che non siano strettamente necessarie.

Una volta fatto, aggiungilo nuovamente al tuo file /etc/fstab, riavvia e goditi i tuoi file :-)