Días de mucho calor, cortes y variaciones de tensión, son un cóctel mortal para los discos sobrecargados de los servidores. Un viernes por la madrugada, uno de los discos de nuestro servidor de backups falló.
Lo que sigue demuestra la flexibilidad de RAID5 por software, a la vez que su confiabilidad.
El servidor dispone de cinco discos, uno con el sistema operativo -Debian GNU/Linux Lenny- y archivos de download, y cuatro más de 500GB cada uno en RAID5. Eso totaliza una unidad md de 1,5TB.
Tanto smartd como mdadm enviaron los mensajes correspondientes informando que uno de los discos había salido de servicio. El disco estaba muerto por completo, ni un fdisk ni un smartctl mostraban información sobre él.
Cuando un disco falta en una unidad md, ésta sigue funcionando en modo degradado, es más lenta y los discos están más sobrecargados. Por lo tanto, es crucial actuar rápidamente recambiando el disco fallado por uno nuevo. En esta oportunidad, sin embargo, no vi los mensajes de aviso sino hasta el sábado, cuando otro disco de los discos falló también, y la unidad md salió de servicio.
El segundo disco dañado aparentemente no estaba tan mal como el primero, sino que tenía una serie de bad sectors y algún tipo de falla que provocaba largas faltas de respuesta a las peticiones del kernel, y que finalmente terminaron por sacarlo de línea.
Así de un momento a otro habíamos perdido 1,5TB de backups de clientes. Debido a que los backups de los clientes se realizan desde los servidores remotos a través de Internet utilizando rsync, hacía realmente importante que pudiésemos recuperar lo más posible de los datos de la unidad md.
Adquiridos los nuevos discos, decidimos intentar la recuperación. Para ello, copiamos con dd_rescue el disco que estaba en mejor estado al nuevo:
dd_rescue -v /dev/sdb /dev/sdc
Utilizamos para ello otra máquina, para evitar cualquier equivocación con los discos y su denominación, y poder trabajar tranquilos.
Hecho esto, operación que duró gran cantidad de horas por los defectos en el disco origen, recreamos la unidad md con el disco nuevo y uno missing (faltante), ya en el servidor definitivo. Cabe destacar que el sistema de archivos de la unidad nueva presentaba una gran cantidad de errores, y aunque era usable, por supuesto no estaba en condiciones de operar.
El siguiente paso fue agregar el disco faltante a la unidad, y esperar que sincronizara:
mdadm –manage -a /dev/md0 /dev/hdd1
Una vez sincronizada fue necesario realizar la reparación del sistema de archivos. Dado que usamos ReiserFS, ejecutamos un:
reiserfsck –rebuild-tree /dev/md0
y esperamos con santa paciencia a que terminase. Por supuesto fueron muchas horas.
A modo informativo para quien desee intentarlo, anotamos que todas estas operaciones y trabajos nos llevaron en total tres jornadas. Como resultado, se perdió un muy bajo número de archivos en las zonas con errores, recuperándose quizá más de un 99,99%. Incluso archivos de 40 o 50GB de tamaño no sufrieron daños, seguramente porque no tenían nodos en zonas con daños.
Como último paso, se sincronizaron con rsync los archivos de cada cliente, y el sistema volvió a la normalidad.