Cómo sustituir un disco defectuoso en Raid1 SW

Los problemas de discos, aunque tengas backups, te causan mucho respeto, por eso escribo este artículo, para ilustrar paso a paso cómo sustituir un disco defectuoso en Raid1 SW, un proceso que puede ser más largo de lo deseado si no se conoce con exactitud.

La mayor parte de las veces los problemas se resuelven con cierta solvencia y rapidez, pero cuando lidias con hardware tiende a complicarse, y los logs del Servidor apuntaban en esta dirección:

Cambio del Disco Fallido

Tras algunos minutos intentando encontrar más información en los logs, no conseguía recuperar la accesibilidad al disco, no había forma de enderezar la situación. Aunque todo apuntaba a un problema de hardware intenté pensar que podría haberse desconfigurado el raid y quizás un reinicio podía ayudar a re-leer la información de la configuración inicial. Arranqué KVM over IP para ver el arranque tras su reinicio, pero esto más lejos de mejorar… dejó la sesión de ssh innacesible y además con un kernel-panic, vamos que todo fue a peor.

Sólo quedaba pensar que al estar en espejo (raid1) podíamos quitar el disco dañado y arrancara el Sistema desde el segundo disco (/dev/sdb). Así lo pedí a nuestro proveedor del CPD y he de agradecer que fue una intervención muy rápida y efectiva:

Debemos indicar al gestor de Meta Devices (mdadm) que falla un disco y que no queremos que forme parte del array, después paramos el servidor y sustituimos el disco estropeado:

mdadm — manage /dev/md2 — fail /dev/sda2 mdadm — manage /dev/md2 — remove /dev/sda2

Repetimos este proceso por todos los Meta Devices (/dev/md’x’) afectados a causa de la no disponibilidad del disco defectuoso.

Recreamos la tabla de particiones en el disco nuevo

La documentación consultada nos indica que necesitamos el siguiente comando para replicar la tabla de contenidos desde el disco activo (sdb) al nuevo, que obviamente está ahora sin datos (sda):

Lamentablemente el anterior comando no me funcionó porque el instalador del sistema me configuró una tabla de particiones GPT, entonces hay que instalar el paquete gdisk y manipular la tabla de particiones usando estas dos alternativas:

Una vez replicada la tabla de particiones al nuevo disco (sda) quedará algo así como:

Añadimos las nuevas particiones a sus Meta Devices

Ahora añadimos las nuevas particiones, que están en blanco pero tienen distribución idéntica, al disco activo para que se sincronicen y recuperen los datos. Esta parte es muy sencilla:

Si todo ha ido bien veremos que los discos empiezan a sincronizar, las particiones que hay en blanco empiezan a recuperar los datos desde el disco activo, y cuando termine el proceso -que puede llevar horas dependiendo del tamaño- tendremos de nuevo la configuración en espejo como antes del fallo de hardware

[root@node01 ~]# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] md2 : active raid1 sda2[2] sdb2[1] 83884992 blocks [2/1] [_U] [==>………………] recovery = 10.2% (8589312/83884992) finish=1001.9min speed=1252K/sec md4 : active raid1 sdb4[1] 1865429952 blocks [2/1] [_U]

Ahora solo queda comprobar que tenemos GRUB loader bien configurado en el nuevo disco y actualizar la configuración de /etc/mdadm.conf

He de admitir que no me preocupó realizar esta operación, sino más bien pensar que teníamos varios servicios de Clientes parados, y presionarme para realizar esta operación en el menor tiempo posible, creo recordar que todo el proceso, incluida la intervención del técnico del CPD, fue de una 1h:30m aproximadamente, una hora y pico que se puede hacer larga si te sucede en hora punta.