mazatl en coma, pronóstico reservado

La peor pesadilla de un sysadmin es encontrar un servidor en coma.

El sábado (09/01/24) a las 07:49 recibí un SMS indicando que MAZATL estaba muerta. Bueno, en realidad no lo estaba del todo: sólo rechazaba las conexiones que requerían authentificación (sic). No funcionaba el SSH, pero sí permitía conexiones HTTP. Programé un "reboot" en Red Hat Network y esperé. El lunes reiniciamos el equipo, y a partir de entonces estamos en DEFCON-5.

Tenemos un Dell PowerEdge 1900 con un RAID5 basado en el controlador PERC 5/i. El equipo está en coma, es decir, prende, pasa la POST, pero no arranca el sistema operativo. Es más, ni siquiera encuentra el disco duro. Inmediatemente pensé que se trataba de una falla en el arreglo de discos. Efectivamente, al entrar al BIOS del PERC 5/i encotraba el tercer disco MISSING y el cuarto OFFLINE.

Usando un adaptador {P,S}ATA/USB revisamos los cuatro discos, y encontramos dañado el tercer disco. Como el equipo tiene un contrato de servicio por tres años -y apenas lleva uno y medio- inmediatamente llamamos a DELL y el día de mañana nos enviarán el disco de reemplazo.

Me gran preocupación es la integridad de los datos. ¿Habrán sobrevivido al evento? ¿Se podrá reconstruir el arreglo al poner el disco nuevo si el cuarto disco está OFFLINE? Aún más: ¿por qué se presentó la falla en primer lugar? ¿Que no se supone que el RAID5 puede soportar la falla de un disco? ¿Acaso fallaron dos? ¿Acaso hemos perdido diez años de información? Me parece que estos arreglos vía hardware no son tan buenos como pensábamos y nos conviene seguir con los arreglos nativos de Linux.

En fin, mañana llegarán los del DELL, a ver que tanto aumenta la PH (Pura Histeria) de los usuarios.

Moraleja: Sólo existen dos tipos de discos duros. Los que ya fallaron y los que fallarán.
Corolario: ¿Para que corchos son los respaldos?