Miklix

Reemplazo de una unidad defectuosa en una matriz mdadm en Ubuntu

Publicado: 15 de febrero de 2025, 22:02:16 UTC

Si se encuentra en la temida situación de tener una falla en la unidad en una matriz RAID mdadm, este artículo explica cómo reemplazarla correctamente en un sistema Ubuntu.


Esta página ha sido traducida automáticamente del inglés para hacerla accesible al mayor número de personas posible. Lamentablemente, la traducción automática no es todavía una tecnología perfeccionada, por lo que pueden producirse errores. Si lo prefiere, puede consultar la versión original en inglés aquí:

Replacing a Failed Drive in an mdadm Array on Ubuntu

La información de este post está basada en Ubuntu 18.04 y la versión de mdadm incluida en sus repositorios; al momento de escribir este artículo v4.1-rc1. Puede o no ser válida para otras versiones.

Recientemente, tuve una falla repentina en el disco de mi servidor de archivos doméstico, que consta de nueve unidades en una matriz RAID-6 mdadm. Eso siempre da miedo, pero afortunadamente pude conseguir rápidamente una unidad de reemplazo que me entregaron al día siguiente para poder comenzar con la reconstrucción.

Admito que fui un poco tacaño cuando configuré originalmente el servidor de archivos; solo dos de las unidades son unidades NAS reales (Seagate IronWolf), mientras que el resto son unidades de escritorio (Seagate Barracuda). No es de sorprender que fuera una de las unidades de escritorio la que se había rendido (después de casi tres años de servicio, sin embargo). Estaba completamente muerta; después de moverla a una carcasa USB de escritorio, todo lo que obtuve de ella fue un sonido de clic desconcertante y ni Ubuntu 20.04 ni Windows 10 pudieron detectarla.

Bueno, pasemos a la pieza de repuesto (y sí, la nueva unidad que compré era una IronWolf, lección aprendida). Por más aterrador que sea perder una unidad en una matriz en funcionamiento, es aún más aterrador si no conoce el procedimiento correcto para reemplazarla. No es la primera vez que he tenido que reemplazar una unidad defectuosa en una matriz mdadm, pero afortunadamente es tan poco frecuente que generalmente tengo que buscar los comandos adecuados. Esta vez decidí preparar mi propia pequeña guía para futuras referencias.

Entonces, en primer lugar, cuando recibes el temido correo electrónico de evento de error de mdadm, necesitas identificar qué unidad ha fallado. Por supuesto, te dirá el nombre del dispositivo (en mi caso /dev/sdf), pero probablemente no sea obvio qué unidad física es en realidad, ya que esos nombres pueden cambiar cuando se inicia la máquina.

Si ni siquiera está seguro de qué nombre de dispositivo ha fallado, puede usar el siguiente comando para averiguarlo (reemplace /dev/md0 con su dispositivo RAID):

mdadm -–query -–detail /dev/md0

Como mencioné, en mi caso era /dev/sdf, así que continuemos con eso.

Luego, puede intentar encontrar el número de serie de la unidad defectuosa emitiendo este comando:

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

(Si no se encuentra smartctl, debe instalar el paquete smartmontools en Ubuntu)

Luego, el número de serie se puede comparar con los números de serie de la etiqueta física de las unidades para determinar cuál ha fallado.

Pero esta vez no tuve tanta suerte. La unidad estaba completamente muerta e incluso se negó a proporcionar datos SMART u otros, incluido el número de serie.

Como tenía acceso físico al servidor (algo que realmente necesitas si vas a reemplazar un disco físico tú mismo, supongo ;-)) y el servidor estaba funcionando cuando falló el disco (y siguió funcionando bien gracias a la redundancia RAID-6), opté por el método realmente primitivo, pero en realidad muy efectivo y obvio, de simplemente copiar un archivo grande al servidor y observar qué luz del disco duro no parpadeaba. En unos pocos segundos identifiqué al culpable.

Ahora, antes de extraer la unidad física, es una buena idea informar formalmente a mdadm de esta intención emitiendo este comando (reemplace los nombres de los dispositivos con los suyos según corresponda):

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

En caso de éxito, mdadm responderá con un mensaje que indica que "eliminó en caliente" la unidad, aparentemente porque el dispositivo RAID virtual está realmente ejecutándose en ese momento.

Si falla con un mensaje de error similar a "dispositivo o recurso ocupado", es posible que mdadm no haya registrado la unidad como si hubiera fallado por completo. Para que lo haga, ejecute este comando (nuevamente, recuerde reemplazar los nombres de los dispositivos con los suyos propios según corresponda):

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

Después de eso, deberías poder eliminar el dispositivo de la matriz con el comando anterior.

Ahora es el momento de reemplazar la unidad. Si está realmente seguro de que su máquina y su controlador admiten el intercambio en caliente, puede hacerlo sin apagar la máquina. Esa sería la forma de proceder en sistemas de producción críticos que se ejecutan en hardware de servidor real y adecuado que sabe a ciencia cierta que puede manejarlo. Sin embargo, mi servidor de archivos doméstico se basa en una placa base de escritorio de nivel de consumidor con un par de controladores SATA de marca desconocida en las ranuras PCIe para proporcionar más puertos SATA.

Aunque generalmente SATA debería admitir el intercambio en caliente, no estaba dispuesto a arriesgar nada en esta configuración, así que opté por apagar la máquina mientras reemplazaba la unidad.

Antes de hacer eso, es una buena idea comentar el dispositivo RAID en el archivo /etc/fstab para que Ubuntu no intente montarlo automáticamente en el próximo arranque, ya que podría bloquearse y obligarlo a entrar en modo de recuperación debido a la matriz RAID degradada. Esto puede no ser un gran problema si se trata de un sistema de escritorio, pero ejecuto este servidor sin monitor ni teclado conectado, por lo que esto sería un poco complicado.

Después de arrancar la máquina con la nueva unidad instalada, utilice lsblk o algún otro método para identificarla. Si no ha cambiado nada más, probablemente (pero no necesariamente ) tendrá el mismo nombre que la unidad que reemplazó. En mi caso, así fue, por lo que la nueva también se llama /dev/sdf.

Como mi matriz se basa en particiones en lugar de dispositivos físicos, necesitaba copiar la tabla de particiones de una unidad que funcionaba a la nueva unidad para asegurarme de que fueran exactamente iguales. Si ejecuta su matriz en dispositivos físicos, puede omitir este paso.

Para ello, utilicé sgdisk y copié la tabla de particiones de /dev/sdc a /dev/sdf. Asegúrese de reemplazar los nombres de los dispositivos para que coincidan con los suyos según corresponda.

Tenga en cuenta el orden aquí: ¡primero debe indicar la unidad "a"! Esto es un poco contraintuitivo para mí, pero asegúrese de hacerlo bien para que no se produzca otra falla de unidad en la matriz ;-)

sgdisk -R /dev/sdf /dev/sdc

Luego, para evitar conflictos de UUID, genere nuevos UUID para la nueva unidad:

sgdisk -G /dev/sdf

Y ahora finalmente ha llegado el momento de agregar la nueva unidad a la matriz y comenzar la fiesta de reconstrucción (bueno, en realidad no es una fiesta, en realidad es un proceso bastante lento y desconcertante, ya que realmente no quieres que otra unidad falle en este momento. Sin embargo, la cerveza podría ayudar).

De todos modos, para agregar la nueva unidad a la matriz, emita este comando (nuevamente, asegúrese de reemplazar los nombres de los dispositivos con los suyos según corresponda):

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

Si todo va bien, la unidad se agregará a la matriz sin problemas. Creo que, en realidad, se agrega como "repuesto activo" de manera predeterminada, pero como a esta matriz le falta un disco (el que falló), se pone en uso de inmediato y comenzará el proceso de reconstrucción.

Puedes vigilarlo de la siguiente manera:

watch cat /proc/mdstat

Probablemente esto llevará un tiempo; en mi humilde servidor (basado principalmente en hardware de consumo y unidades de escritorio, ojo) fue capaz de alcanzar poco menos de 100 MB/seg. Ten en cuenta que se trata de RAID-6, por lo que hay muchos cálculos de paridad involucrados con una reconstrucción; un RAID-10 habría sido mucho más rápido. Esta máquina en particular tiene una CPU de cuatro núcleos AMD A10 9700E (la "E" significa que es un modelo de bajo consumo de energía, es decir, no súper rápido), solo para darte una idea de qué esperar. Con las nueve unidades de 8 TB en mi configuración, la reconstrucción completa tomó poco más de 24 horas.

Durante la reconstrucción, puedes montar el sistema de archivos en la matriz y usarlo de manera normal si lo deseas, pero yo prefiero dejar que la reconstrucción termine. Ten en cuenta que si falla una unidad, puede que pronto le siga otra, por lo que es conveniente que la reconstrucción se realice lo más rápido posible, ya que no quieres que otra unidad falle durante la misma. Por lo tanto, no la sobrecargues con otras operaciones de E/S que no sean estrictamente necesarias.

Una vez hecho esto, agréguelo nuevamente a su archivo /etc/fstab, reinicie y disfrute de sus archivos :-)

Compartir en BlueskyCompartir en FacebookCompartir en LinkedInCompartir en TumblrCompartir en XCompartir en LinkedInPin en Pinterest

Mikkel Bang Christensen

Sobre el autor

Mikkel Bang Christensen
Mikkel es el creador y propietario de miklix.com. Tiene más de 20 años de experiencia como programador informático profesional y desarrollador de software, y actualmente trabaja a tiempo completo para una gran empresa europea de TI. Cuando no está escribiendo en su blog, dedica su tiempo libre a una gran variedad de intereses, aficiones y actividades, que en cierta medida pueden verse reflejados en la variedad de temas tratados en este sitio web.