La alerta suele tener un asunto aburrido: un evento DegradedArray en /dev/md0. Un disco de un RAID por software de Linux ha salido del arreglo, el servidor sigue funcionando y es tentador dejarlo para la semana próxima. No lo haga. Un arreglo RAID degradado ya no tiene redundancia para los datos que contiene, y los discos restantes suelen tener la misma edad y modelo que el que acaba de fallar. Esta guía muestra cómo reemplazar un disco fallido en mdadm con calma, en un arreglo típico RAID 1, 5, 6 o 10, sin convertir una falla de disco en pérdida de datos.
Paso 1: verifique el estado de RAID en Linux antes de tocar nada
Comience leyendo lo que informa el sistema. El archivo /proc/mdstat da un resumen breve de cada arreglo; un espejo sano de dos discos muestra [UU] y uno degradado [U_]. Para ver más detalle, mdadm --detail /dev/md0 enumera cada dispositivo miembro con su estado (active, faulty, removed o spare) y muestra si hay una resincronización o recuperación en curso. Anote qué particiones pertenecen a qué arreglo, porque muchos servidores tienen arreglos separados para /boot, swap y datos en los mismos discos.
A continuación, confirme las copias de seguridad. Una reconstrucción lee todos los bloques de los discos sobrevivientes, y ese es justo el momento en que suele fallar un segundo disco débil. Si la última copia de seguridad es antigua o nunca se ha probado, copie primero los datos importantes a un lugar seguro.
Paso 2: identifique el disco fallido por número de serie
Los nombres de dispositivo como /dev/sdb pueden cambiar entre reinicios, y sacar el disco equivocado de un espejo degradado termina mal. Identifique siempre el disco fallido por su número de serie. Los enlaces en /dev/disk/by-id incluyen el modelo y la serie, y smartctl -i /dev/sdb, de smartmontools, también muestra la serie. Anótela y compárela con la etiqueta del disco físico o con la información de la bahía que le dé su proveedor de hosting.
Mientras tiene smartctl abierto, revise los discos sobrevivientes con smartctl -a. Los sectores reasignados o pendientes en un sobreviviente cambian el plan: copie los datos antes de la reconstrucción en lugar de confiar en que esta termine.
Paso 3: retire el miembro fallido
Si mdadm ya marcó el disco como faulty, retírelo del arreglo. Si el disco está fallando pero sigue activo, márquelo primero como faulty. Para cada arreglo que use el disco:
- mdadm /dev/md0 --fail /dev/sdb1, solo si aún no está marcado como faulty
- mdadm /dev/md0 --remove /dev/sdb1
Repita esto con cada partición de ese disco en otros arreglos, como /dev/md1. Entonces se puede reemplazar el disco: en caliente si el hardware lo permite, o tras un apagado planificado. En servidores rentados, abra un ticket con el número de serie y pida al proveedor que reemplace exactamente ese disco.
Mejor aún: cambie un disco que está fallando con mdadm --replace
Si un disco solo muestra advertencias, puede evitar por completo la ventana de degradación. Añada el disco nuevo al arreglo como repuesto y luego ejecute mdadm /dev/md0 --replace /dev/sdb1 --with /dev/sdc1. mdadm copia los datos al disco nuevo mientras el viejo sigue en el arreglo y solo después marca el viejo como faulty. La redundancia se mantiene todo el tiempo, lo que convierte a mdadm --replace en la vía preferida siempre que el servidor tenga espacio para un disco más.
Paso 4: reemplace un disco fallido en mdadm e inicie la reconstrucción
El reemplazo debe ser al menos tan grande como el disco que sustituye. Copie la distribución de particiones de un miembro sano en lugar de crearla a mano:
- Discos GPT: sgdisk --replicate=/dev/sdb /dev/sda copia la tabla de particiones de sda al nuevo sdb, y sgdisk --randomize-guids /dev/sdb le da después al disco nuevo sus propios identificadores.
- Discos MBR más antiguos: sfdisk -d /dev/sda | sfdisk /dev/sdb hace el mismo trabajo.
Verifique dos veces el sentido de la copia antes de pulsar Enter, porque invertir los dos dispositivos sobrescribe la tabla de particiones del disco bueno. Luego añada cada partición nueva a su arreglo con mdadm /dev/md0 --add /dev/sdb1, y la reconstrucción de mdadm comienza sola.
Paso 5: vigile la reconstrucción y repare el cargador de arranque
cat /proc/mdstat muestra el avance de la recuperación y una hora estimada de término. El tiempo de reconstrucción de RAID depende sobre todo del tamaño del disco y de lo ocupado que esté el servidor, porque el kernel limita la reconstrucción para dejar espacio al trabajo normal; los límites están en /proc/sys/dev/raid/speed_limit_min y speed_limit_max. En discos grandes una reconstrucción puede durar muchas horas, así que posponga tareas pesadas como las copias de seguridad completas si puede.
Si el servidor arranca desde el arreglo, el disco nuevo también necesita un cargador de arranque. De lo contrario, el servidor no arrancará la próxima vez que falle el otro disco. En sistemas BIOS eso significa ejecutar grub-install en el disco nuevo; en sistemas UEFI, recree la partición del sistema EFI en el disco nuevo, copie su contenido y añada una entrada de arranque en el firmware. Por último, compruebe que el monitoreo siga vigilando el arreglo y que los correos de alerta lleguen a una persona real.
Errores comunes en la administración de RAID por software
- Volver a crear el arreglo con mdadm --create para "arreglarlo". En un arreglo que contiene datos esto puede destruirlos; ensamblar el arreglo a partir de sus miembros existentes es casi siempre el comando correcto.
- Sacar el disco equivocado por confiar en los nombres de dispositivo en lugar de los números de serie.
- Olvidar los otros arreglos del mismo disco, lo que deja swap o /boot degradados.
- Sin disco de repuesto ni alertas, de modo que la primera falla pasa inadvertida hasta que ocurre una segunda. Un disco de repuesto permite que mdadm comience a reconstruir en el momento en que falla un miembro.
La mayoría de estos errores se remontan a la configuración de RAID en Linux original. Las alertas, un cargador de arranque en cada disco y una nota escrita con la distribución, todo parte de una configuración cuidadosa de RAID con mdadm, convierten un reemplazo de disco en mantenimiento rutinario.
Preguntas frecuentes: reemplazar un disco fallido en mdadm
¿Puedo seguir usando el servidor mientras se reconstruye el arreglo?
Sí. El arreglo permanece en línea todo el tiempo, solo que más lento. El riesgo está del lado de los datos: hasta que termine la reconstrucción, la falla de otro miembro puede tumbar el arreglo, y por eso primero va una copia de seguridad actualizada.
La reconstrucción se reinicia una y otra vez o se detiene con errores de lectura. ¿Qué hago?
Un error de lectura en un disco sobreviviente significa que el origen de la reconstrucción también está fallando. Deje de escribir en el arreglo, copie los datos o genere imágenes de los discos y planifique la recuperación desde ahí, en lugar de forzar la reconstrucción.
¿El disco nuevo tiene que ser del mismo modelo?
No, pero debe ser al menos igual de grande. Mezclar tipos de unidad muy distintos en un mismo arreglo puede limitar todo el arreglo a la velocidad de su miembro más lento.
¿Tiene un arreglo degradado en un servidor en Los Ángeles o en otra parte de California? Nuestro servicio de creación y administración de RAID por software cubre reemplazos de disco, reconstrucciones y recuperación, y la mayor parte del trabajo se hace de forma remota una vez que usted o su proveedor de hosting han instalado el disco de reemplazo. Si una reconstrucción muestra que también hay que revisar las copias de seguridad, consulte nuestro servicio de copia de seguridad de datos y recuperación ante desastres. Contáctenos con la salida de mdadm --detail de cada arreglo y revisaremos con usted el siguiente paso seguro.
