Miklix

Substitució d'una unitat fallida en una matriu mdadm a Ubuntu

Publicat: 5 de març del 2025, a les 19:29:11 UTC
Última actualització: 12 de gener del 2026, a les 8:50:24 UTC

Si us trobeu en la temuda situació de tenir un error de disc en una matriu RAID mdadm, aquest article explica com substituir-lo correctament en un sistema Ubuntu.


Aquesta pàgina es va traduir automàticament de l'anglès per tal de fer-la accessible al màxim de persones possible. Malauradament, la traducció automàtica encara no és una tecnologia perfeccionada, de manera que es poden produir errors. Si ho prefereixes, pots veure la versió original en anglès aquí:

Replacing a Failed Drive in an mdadm Array on Ubuntu

La informació d'aquesta publicació es basa en Ubuntu 18.04 i la versió de mdadm inclosa als seus repositoris; en el moment d'escriure això, v4.1-rc1. Pot ser vàlida o no per a altres versions.

Recentment he tingut una fallada sobtada d'unitat al servidor de fitxers de casa meva, que consta de nou unitats en una matriu RAID-6 mdadm. Això sempre fa por, però per sort vaig poder aconseguir ràpidament una unitat de recanvi que em van lliurar l'endemà per poder començar la reconstrucció.

He d'admetre que vaig ser una mica massa garrepa quan vaig configurar originalment el servidor de fitxers; només dues de les unitats són unitats NAS reals (Seagate IronWolf), mentre que la resta són unitats d'escriptori (Seagate Barracuda). No és sorprenent que fos una de les unitats d'escriptori que havia fallat (després de gairebé tres anys de servei, però). Estava completament morta; després de traslladar-la a una caixa USB d'escriptori, tot el que vaig sentir va ser un so de clic inquietant i ni Ubuntu 20.04 ni Windows 10 van ser capaços de detectar-ho.

Bé, doncs, parlem de la peça de recanvi (i sí, el disc nou que vaig comprar era un IronWolf, lliçó apresa): per molt espantós que sigui perdre un disc en una matriu en funcionament, encara fa més por si no coneixes el procediment correcte per substituir-lo. No és la primera vegada que he hagut de substituir un disc avariat en una matriu mdadm, però afortunadament és tan estrany que normalment he de buscar les ordres correctes. Aquesta vegada he decidit crear la meva pròpia petita guia per a futures consultes.

Així doncs, en primer lloc, quan rebeu el temut correu electrònic d'esdeveniment d'error de mdadm, heu d'identificar quina unitat ha fallat. Segur, us indicarà el nom del dispositiu (en el meu cas /dev/sdf), però probablement no és obvi quina unitat física és realment, ja que aquests noms poden canviar quan s'inicia la màquina.

Si ni tan sols esteu segurs de quin nom de dispositiu ha fallat, podeu utilitzar l'ordre següent per esbrinar-ho (substituïu /dev/md0 pel vostre dispositiu RAID):

mdadm -–query -–detail /dev/md0

Com s'ha esmentat, en el meu cas era /dev/sdf, així que continuem amb això.

A continuació, podeu intentar trobar el número de sèrie de la unitat que ha fallat executant aquesta ordre:

smartctl -–all /dev/sdf | grep -i 'Serial'

(si no es troba smartctl, cal instal·lar el paquet smartmontools a Ubuntu)

El número de sèrie es pot comparar amb els números de sèrie de l'etiqueta física de les unitats per esbrinar quin ha fallat.

Aquesta vegada, però, no vaig tenir tanta sort. El disc dur estava completament mort i fins i tot es negava a proporcionar dades SMART o d'altra mena, inclòs el número de sèrie.

Com que tenia accés físic al servidor (cosa que realment necessites si vols substituir una unitat física tu mateix, suposo ;-)) i el servidor estava funcionant quan el disc va fallar (i va continuar funcionant correctament gràcies a la redundància RAID-6), vaig optar pel mètode realment primitiu, però en realitat molt eficaç i obvi, de simplement copiar un fitxer gran al servidor i observar quin llum del disc dur no parpellejava. En pocs segons vaig identificar el culpable.

Ara, abans de treure la unitat física, és una bona idea informar formalment a mdadm d'aquesta intenció, executant aquesta ordre (substituïu els noms de dispositiu pels vostres segons correspongui):

mdadm -–manage /dev/md0 -–remove /dev/sdf1

Si l'operació té èxit, mdadm respondrà amb un missatge dient que ha "eliminat en calent" la unitat, aparentment perquè el dispositiu RAID virtual està funcionant en aquell moment.

Si falla amb un missatge d'error similar a "dispositiu o recurs ocupat", pot ser que mdadm no hagi registrat que la unitat hagi fallat completament. Per fer-ho, executeu aquesta ordre (de nou, recordeu substituir els noms de dispositiu pels vostres segons correspongui):

mdadm --manage /dev/md0 --fail /dev/sdf

Després d'això, hauríeu de poder eliminar el dispositiu de la matriu amb l'ordre anterior.

Ara és el moment de substituir realment la unitat. Si esteu realment, realment, realment segurs que la vostra màquina i controladora admeten l'intercanvi en calent, podeu fer-ho sense apagar la màquina. Aquest seria el camí a seguir en sistemes de producció crítics que s'executin en maquinari de servidor real i adequat que sabeu del cert que ho pot gestionar. El meu servidor de fitxers domèstic està basat en una placa base d'escriptori de consum amb un parell de controladores SATA semi-sense nom a les ranures PCIe per proporcionar més ports SATA.

Tot i que SATA generalment hauria de ser compatible amb l'intercanvi en calent, no anava a arriscar res en aquesta configuració, així que vaig optar per apagar la màquina mentre substituïa la unitat.

Abans de fer això, és una bona idea comentar el dispositiu RAID al fitxer /etc/fstab perquè Ubuntu no intenti muntar-lo automàticament a la propera arrencada, ja que es podria penjar i forçar-vos a entrar en mode de recuperació a causa de la matriu RAID degradada. Potser això no és un gran problema si es tracta d'un sistema d'escriptori, però jo faig funcionar aquest servidor sense cap header sense monitor ni teclat connectats, així que això seria una mica complicat.

Després d'arrencar la màquina amb el disc nou instal·lat, feu servir lsblk o algun altre mitjà per identificar-lo. Si no heu canviat res més, probablement (però no necessàriament) tindrà el mateix nom que el disc que heu substituït. En el meu cas sí que ho va fer, així que el nou també s'anomena /dev/sdf.

Com que la meva matriu es basa en particions en lloc de dispositius físics, necessitava copiar la taula de particions d'una unitat que funcionava a la nova unitat per assegurar-me que són exactament iguals. Si executeu la vostra matriu en dispositius físics, podeu ometre aquest pas.

He fet servir sgdisk per a aquest propòsit, copiant la taula de particions de /dev/sdc a /dev/sdf. Assegureu-vos de substituir els noms dels dispositius perquè coincideixin amb els vostres segons correspongui.

Fixeu-vos en l'ordre aquí: primer heu d'indicar la unitat "a"! Això és una mica contraintuïtiu per a mi, però assegureu-vos de fer-ho bé per evitar que es produeixi un altre error de la unitat de la matriu ;-)

sgdisk -R /dev/sdf /dev/sdc

Aleshores, per evitar conflictes d'UUID, genereu nous UUID per a la nova unitat:

sgdisk -G /dev/sdf

I ara finalment ha arribat el moment d'afegir el nou disc dur a la matriu i començar la festa de reconstrucció! (D'acord, no és realment una festa, en realitat és un procés força lent i inquietant, ja que realment no vols que falli un altre disc en aquest moment. La cervesa potser ajudarà, però)

De totes maneres, per afegir la nova unitat a la matriu, executeu aquesta ordre (de nou, assegureu-vos de substituir els noms de dispositiu pels vostres segons correspongui):

mdadm -–manage /dev/md0 -–add /dev/sdf1

Si tot va bé, la unitat s'afegirà a la matriu sense problemes. Crec que en realitat s'afegeix com a "recanvi en calent" per defecte, però com que a aquesta matriu li falta un disc (el que va fallar), es posa en ús immediatament i s'iniciarà el procés de reconstrucció.

Pots vigilar-ho així:

watch cat /proc/mdstat

Probablement això trigarà una mica; al meu servidor (basat principalment en maquinari de consum i unitats d'escriptori, fixeu-vos-hi) va poder arribar a poc menys de 100 MB/s. Tingueu en compte que aquest és RAID-6, per la qual cosa hi ha molts càlculs de paritat implicats en una reconstrucció; un RAID-10 hauria estat molt més ràpid. Aquesta màquina en particular té una CPU de quatre nuclis AMD A10 9700E (la "E" significa que és un model amb poca velocitat d'eficiència energètica, és a dir, no és súper ràpid), només per donar-vos una idea del que podeu esperar. Amb les nou unitats de 8 TB de la meva configuració, la reconstrucció completa va trigar poc més de 24 hores.

Durant la reconstrucció, podeu muntar el sistema de fitxers a la matriu i utilitzar-lo com de costum si voleu, però prefereixo deixar-ho per a la reconstrucció fins que estigui acabat. Tingueu en compte que si un disc falla, un altre pot seguir aviat, així que voleu que la reconstrucció es faci el més ràpid possible, ja que realment no voleu que un altre disc falli durant això. Per tant, no el carregueu amb altres E/S que no siguin estrictament necessàries.

Un cop fet, torna-ho a afegir al fitxer /etc/fstab, reinicia i gaudeix dels teus fitxers :-)

Comparteix a BlueskyComparteix a FacebookComparteix a LinkedInComparteix a TumblrComparteix a XComparteix a LinkedInPin a Pinterest

Mikkel Christensen

Sobre l'autor

Mikkel Christensen
Mikkel és el creador i propietari de miklix.com. Té més de 20 anys d'experiència com a programador/desenvolupador de programari informàtic professional i actualment treballa a temps complet per a una gran corporació informàtica europea. Quan no fa blocs, dedica el seu temps lliure a una gran varietat d'interessos, aficions i activitats, que fins a cert punt es poden reflectir en la varietat de temes tractats en aquest lloc web.