En esta ocasión, esto es lo que me sucedió con un disco de 500Gb.

Primeros síntomas de avería

El ordenador comenzó a demorarse bastante durante el arranque, aunque no mostraba ningún mensaje de error alarmante. Como no suelo apagar este ordenador, no se cuantos días estuvo progresando la avería del disco.

El disco era nuevo (menos de 2.000 horas de funcionamiento), así que al principio no se me ocurrió pensar que estuviese estropeado. Sin embargo, un día eché un vistazo a los logs de Windows, y observé una larga serie de entradas que se referían a un error de disco; esto sucedía durante el arranque.

El disco tenía 3 particiones:

1. La primera partición contenía sowftare de diagnóstico de la marca que fabrica la máquina.

2. La segunda partición contenía Windows XP Professional, y todas mis aplicaciones y datos de interés.

3. La tercera partición estaba formateada, pero (afortunadamente) no contenía datos.

Recursos disponibles

Mi ordenador tiene un formato ultra pequeño, y sólo admite una unidad de disco. Es un inconveniente, porque no se puede conectar otro disco y volcar la información en él. Mis otros ordenadores son bastante antiguos, y no admiten discos SATA.

Casualmente, tenía por allí unas máquinas con Linux instalado.

El disco que falló reemplazaba a otro disco más pequeño, de 250Gb, que conservé sin modificar en un cajón del escritorio, por si acaso. En el disco de 250Gb se encontraba instalado Windows XP y todas mis aplicaciones de usuario y datos de utilidad, aunque algo atrasados.

Recuperar los datos

Así que, mientras me conseguía otro disco nuevo igual que el estropeado, desmonté el disco antiguo y lo coloqué en mi ordenador personal, ese que sólo admite un disco SATA.

El disco estropeado lo coloqué en la máquina Linux, y lo monte con la orden mount:

Esto me permitió acceder al disco para copiar en bruto, los datos de interés: las bases de datos de MySQL, los espacios de trabajo de Eclipse, los sitios web alojados en mi servidor, etc.

Temporalmente copié estos datos en una carpeta de la máquina Linux, que a su vez está publicada en la ethernet local con Samba.

Desde la máquina Windows copié los datos a través de la red local al disco antiguo, e intenté la restauración (tomando la precaución de conservar los datos orginales). Aquí encontré alguna dificultad con MySQL y Eclipse.

Restaurar MySQL data

Antes de restaurar la copia de los datos de MySQL, detuve el servicio y renombré la carpeta original a algo así como Copia de MySQL data, o algo por el estilo. Entonces copié la carpeta desde la máquina Linux e intenté reiniciar el servicio MySQL, sin éxito. Anduve probando algunas utilidades de MySQL para reparar archivos dañados, como myisamchk y mysqlcheck, tras leer cómo usarlas en algunos artículos que encontré por la red, también sin éxito.

Por último, se me ocurrió copiar los archivos ib_logfileX, ibdataX y server.pid desde la carpeta original y el servicio consiguió iniciarse, pero no se podía escribir nada en las bases de datos.

Lo comprobé al iniciar uno de los sitios web, que usa Joomla! para publicar el contenido. Al visitar el sitio web con el navegador, se mostraba correctamente; sin embargo, al intentar seguir cualquier enlace, aparecía un mensaje de error indicando que no se podía registrar la información de sesión en la base de datos de sólo lectura (la clave del problema).

Tras dar un vistazo a los atributos de los archivos de una de las bases de datos, comprobé que todos estaban marcados como sólo lectura.

Modifiqué los atributos para quitar el atributo de sólo lectura en la máquina Windows, con la orden:

Y el problema quedó resuelto.

Restaurar espacios de trabajo de Eclipse

Algo parecido sucedió con los espacios de trabajo de Eclipse. Con la carpeta de los espacios de trabajo de Eclipse, hice lo mismo que con MySQL: renombrar la original para mantenerla en caso de dificultades, y copiar la otra desde Samba. Eclipse se negaba a arrancar, protestando por algún problema con el espacio de trabajo.

Eclipse utiliza algunos ficheros de configuración para organizar y mantener el espacio de trabajo. Oculto en la carpeta siempre hay una subcarpeta especial, que Eclipse utiliza y comprueba durante el arranque: la carpeta .metada.

Supuse que el problema era similar, e intenté la misma solución con attrib, pero no funcionó. El motivo es que las carpetas y los archivos que tienen activo el atributo de sólo lectura, además están ocultos, y attrib no actúa sobre archivos ocultos, salvo para retirar ese atributo. Así la solución tiene dos pasos:

De nuevo, Eclipse arrancó sin protestar con los espacios de trabajo recuperados. Hay otra solución (la que recomienda Eclipse y he leído por la red) que consiste en importar los espacios de trabajo desde otra carpeta; la he usado en el pasado, pero tarda demasiado en realizarse. La solución alternativa sólo se demora unos segundos.

Otros datos de interés

El resto de datos, incluído un pequeño repositorio CVS, simplemente se copiaron desde Samba a sus ubicaciones habituales.

Recuperar todo el disco

Bien, esto resolvió la parte potencialmente grave de la situación, pero quedaba intentar el rescate de todo el disco, porque no me gusta andar haciendo inventario de lo que tiene desperdigado (ya sé que es una mala práctica, pero soy humano después de todo).

Así que compré un disco nuevo, para poder devolver el disco pequeño al cajón con los datos actualizados.

Copia en bruto de dispositivos en Linux

Monté el disco nuevo en la máquina Linux, junto al disco estropeado, e intenté la copia sector a sector con la orden dd (manejar con cuidado esta utilidad). Sin embargo comencé a observar errores durante la copia cuando ya se había copiado más del 50% del disco, y me pregunté si no sería posible usar algo mejor. Leyendo por la red encontre una referencia a ddrescue (lo mismo que dd, pero ignora los errores de lectura).

Aborté la copia dd y en su lugar intenté ddrescue:

Hubiese sido de utilidad especificar la opción que copia la salida de la consola a un fichero log, para tener un mapa de defectos del disco, pero no lo hice.

Pensé, durante las largas horas del rescate, que si encontrase un utilitario capaz de identificar el nombre de los archivos afectados por sectores defectuosos en el disco, sería posible copiarlos desde el disco pequeño para sustituirlos por copias funcionales. Sorprendentemente, no conseguí encontrar ninguno para ntfs, aunque es muy fácil construir uno para sistemas de archivo fat.

El disco estaba tan estropeado que no conseguí terminar la copia transcurridas 12 horas. Aborté la copia una vez que estuve seguro de haber duplicado las dos primeras particiones (algo más del 50% del disco).

Recuperación del sistema Windows

No estaba seguro si la copia quedaría utilizable o no, pero monté el disco rescatado en su ordenador, reemplazando al pequeño, y lo arranqué. Windows comenzó a cargarse, e inmediatamente se inició chkdsk, advirtiendo de inconsistencias y errores en el disco (que el original enmascaraba).

Milagrosamente, Windows consiguió iniciarse, y realicé una verificación del sistema:

Esta utilidad solicitó el disco original de Windows XP, del que copió algo que seguramente estaba estropeado, y el problema quedó definitivamente resuelto.

Esta recuperación funcionó porque apenas había unos sectores dañados al pricipio del disco (32 sectores, unos 48Kb), y al parecer ningún problema con la estructura de carpetas.

Windows consiguió iniciarse porque ningún archivo vital para el arranque resultó estropeado. Si esto hubiese sucedido, se complicaría notablemente la restauración del sistema operativo, sin la ayuda de la utilidad que reconoce archivos en sectores defectuosos, ya que sfc sólo funciona sobre el sistema de Windows iniciado.

Diagnóstico y conclusiones

Tras ejecutar el test del fabricante sobre el disco, se observó que la lectura no conseguía progresar más allá del 61% del tamaño de la unidad (lo pasé varias veces, recuperando errores).

Afortunadamente, las particiones 2 y 3 eran de igual tamaño, y la 1 muy pequeña, por lo que todos los datos de interés se encontraban antes de ese límite y se pudo acceder a ellos para recuperarlos.

Resulta desconcertante comprobar que aquellos mecanismos en los que confiamos para avisar los fallos de los discos, no funcionan, o contribuyen a agravar el problema: SMART no avisó en la máquina Windows, el sistema de reasignación de sectores defectuosos del disco evitó las alertas de chkdsk.

Sólo la observación del equipo, la demora en el inicio, indicó el síntoma de la avería. La revisión de los sucesos del sistema de Windows lo confirmaron.