$ fortune linuxcookie
----==-- _ / / \
---==---(_)__ __ ____ __ / / /\ \
--==---/ / _ \/ // /\ \/ / / /_/\ \ \
-=====/_/_//_/\_,_/ /_/\_\ /______\ \ \
A proud member of TeamLinux \_________\/
(By CHaley (HAC), haley@unm.edu, ch008cth@pi.lanl.gov)
jueves, 29 de enero de 2009
martes, 27 de enero de 2009
RAID5 two disk failure!
Es oficial: La falla de MAZATL es ¡una falla de dos discos!
Aunque el soporte técnico de DELL ya nos cambió el disco muerto, resultó ser que al momento de estar reconstruyendo el arreglo, el cuarto disco pasó al estado FAILED.
Seguimos en DEFCON-5.
Pero no todo está perdido: desactivando la reconstrucción automática del arreglo, y obligando al cuarto disco al estado ONLINE, se puede arrancar MAZATL en emergency mode y en single user mode.
Aplicando rsync he logrado recuperar (es decir, copiar en otra máquina) los volúmenes /var/www, /usr/local y hasta el momento 74GB (de 124GB) del volúmen /home. Al parecer, el daño está acotado al volúmen /var/spool/mail.
Esta historia continuará...
Aunque el soporte técnico de DELL ya nos cambió el disco muerto, resultó ser que al momento de estar reconstruyendo el arreglo, el cuarto disco pasó al estado FAILED.
Seguimos en DEFCON-5.
Pero no todo está perdido: desactivando la reconstrucción automática del arreglo, y obligando al cuarto disco al estado ONLINE, se puede arrancar MAZATL en emergency mode y en single user mode.
Aplicando rsync he logrado recuperar (es decir, copiar en otra máquina) los volúmenes /var/www, /usr/local y hasta el momento 74GB (de 124GB) del volúmen /home. Al parecer, el daño está acotado al volúmen /var/spool/mail.
Esta historia continuará...
lunes, 26 de enero de 2009
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?
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?
Suscribirse a:
Entradas (Atom)