Discos de repuesto

Soy bastante paranoico, lo se. Quizás tenga razón. Así que al montaje que ya tenia en mi servidor he añadido recientemente otro disco duro más que actua como disco de repuesto (spare disk).

Previamente habian 3 discos de 300G y he añadido otro igual. Para hacer la partición idéntica he utilizado sfdisk. Con una orden para extraer la partición de un integrante actual del RAID:

sfdisk -d /dev/sda > sda

Y otra orden para aplicar el mismo esquema al nuevo disco (sdb):

sfdisk /dev/sdb <>

Y ahora tan sólo nos queda añadir las diferentes particiones. Se utiliza la misma orden siempre, tanto para añadir discos que reemplazan a defectuosos como en este caso discos de repuesto. El sistema mdadm conoce el tamaño del array y cualquier dispositivo adicional que se incluya se convierte automáticamente en un repuesto. Por tanto:

mdadm --add /dev/md0 /dev/sda1

El resultado final queda plasmado con la salida de /proc/mdstat:

Personalities : [raid5] [raid4] [raid1]
md0 : active raid1 sdb1[3](S) sda1[0] hdg1[2] hdc1[1]
96256 blocks [3/3] [UUU]

md1 : active raid5 sdb2[3](S) sda2[0] hdg2[2] hdc2[1]
979712 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md2 : active raid5 sdb3[3](S) sda3[0] hdg3[2] hdc3[1]
584926464 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices:

Crash test

Pese a que no tiene que ver con los temas que suelo tratar aquí, creo que este post merece la pena para quien quiera saber lo que pasa en los poco más de 100 milisegundos siguientes a un impacto con el coche.

El hilo entero es muy interesante y otros blogs ya se estan haciendo eco de él. Ahora no recuerdo ninguna referencia.

Y falló un disco

O... la prueba real de la configuración RAID de mi servidor.

Pues si, el primer disco (hda) de los tres que componen el RAID5 (hda,hdc,hdg) ha dicho que no quiere trabajar más. Sin problemas, recibo un email del monitor de RAID avisándome que el disco está fallando y lo saca del RAID.

Bien, el siguiente paso lógico es comprar un nuevo disco para sustituir al afectado. Voy a comprar otro disco de 300G pero sólo encuentro SATA. No importa, le enchufo una controlador SATA PCI, le conecto el nuevo disco (sda), quito el defectuoso (hda) y arranco de nuevo la máquina... y no arranca.

Momento de pánico...

Bien, no aparece nada en pantalla, o sea no carga ni el bootloader (GRUB). Así que sospecho que el problema está en que justamente ha fallado el disco principal (hda). Lo vuelvo a conectar y por suerte el disco no estaba totalmente irrecuperable y logro arrancar el sistema de nuevo.

Al parecer lo que indiqué en el artículo anterior no es del todo correcto. Curiosamente creí haberlo probado convenientemente. Al final mediante el wiki de Gentoo (aunque uso Debian) probé el mecanismo alternativo de configurar GRUB. Arranqué y funcionó.

Así que tengo dos teorias:

• El procedimiento que utilicé originalmente no es correcto y lo probé mal.
• El procedimiento original era correcto pero con los cambios de kernel y actualizaciones automáticas del GRUB se debería volver a ejecutar con cada actualización de kernel.

¿Alguna idea?

Actualización 25/2/09: Vaya, hace tiempo de esta entrada. Pero revisando el blog la he encontrado y queria actualizar este tema. El enlace a la web de Gentoo está roto porque hay una nueva versión que de paso tiene la solución correcta.

Los pasos serian así, os pongo un ejemplo en el que queremos actualizar el tercer disco (/dev/sdc) para que arranque (de la primera partición, /dev/sdc1):

• device (hd0) /dev/sdc
  
• root (hd0,0)
  
• setup (hd0)
  

Así que se trata de una variación del anterior haciendo "creer" al sistema que el disco /dev/sdc es el primero (en realidad si falla el otro y hay que cambiar el orden del RAID, así será). Como siempre, YMMV.