Recuperando datos de un disco roto

Buenas, y bienvenidos de nuevo a este blog. Sé que hace mucho que no escribo (y no por falta de ideas), pero hoy os traigo un caso que me ha pasado, y que es uno de los mayores sustos que me he llevado: ir a hacer backup y que el disco esté roto. Es la clase de sustos que esperas no llevarte nunca, pero que te pasan porque "lo vas dejando" y cuando quieres ponerle remedio ya estás en mitad del incendio.

La buena noticia es que he conseguido recuperar casi todos los datos perdidos, y lo que no he podido recuperar lo puedo conseguir de otros sitios, de modo que es una victoria, y me ha permitido investigar un poco, darme cuenta de que sé algo de discos duros, almacenamiento y sistemas operativos y que, muchas veces, importa más tener paciencia y mantener la calma que lanzarse a probar a lo loco y esperar que algo de en el clavo por casualidad.

Pero, para daros un poco más de contexto, dejad que os cuente cómo he llegado hasta este punto, qué me he encontrado, qué he hecho para solucionarlo y qué resultados he conseguido.

Como novedad, el post incluye banda sonora: hijos del Omnissiah, del videojuego Mechanicus, de Warhammer 40000, en versión extendida. Nada como un poco de ambiente oscuro para reflejar lo que para mí ha sido excavar en un misterio casi arcano.

Aviso: mientras redactaba esta entrada el disco ha fallado definitivamente, por lo que no puedo replicar y capturar cada paso. He podido capturar algunas cosas, pero otras las he tenido que sacar de internet. Pondré notas al pie de las imágenes indicando cuándo son originales y cuándo no.

Aviso 2: después de leerlo un par de veces, me doy cuenta de que hay conceptos técnicos de los que mucha gente no habrá oído hablar. Algunos los explico sin mucho detalle, intentando dar contexto más que una lección magistral sobre temas que conozco pero no domino, y en otros incluyo enlaces que lo explican mejor de lo que yo podría hacerlo.

Dicho esto, comenzamos.

Como todo informático que se precie tengo varios ordenadores en casa. Portátiles, sobremesa, los equipos del trabajo, algún equipo que me han dado para que arregle y que está ahí cogiendo polvo... Ya sabéis, lo que pasa cuando eres informático y cuesta decir que no. Pero el que más utilizo es mi ordenador de sobremesa, con un procesador potente, RAM abundante, varios discos duros y dos o tres pantallas para trabajar en un sitio especialmente pensado para ello.

Esta historia empieza hace un par de semanas, cuando Windows me avisa de que a) Windows 10 pierde soporte en octubre de este año (2025) y b) que puedo actualizar a Windows 11 sin problemas. Como me duele el alma de hacer esa migración en el trabajo y ya sé qué requisitos hay y qué puedo esperarme, pienso que, ya que estoy, aprovecho para organizar datos entre los distintos discos y hago un poco de limpieza. Y, de paso, resetear el sistema después de actualizar para empezar limpiamente. Hace ya años que no formateo ni reseteo, y empiezo a notar que algunas cosas... Empiezan a no ir demasiado bien.

Dicho de otra manera: aprovechar la actualización para organizar un poco.

Así que activo TPM en la placa, compruebo que Windows lo reconoce y me pongo a mover datos entre discos. Fotografías, documentos, archivos, programas... Es sorprendente el tiempo que tardas en organizar datos que igual llevaban ahí 5 ó 6 años a que les echaras un ojo, y la cantidad de cosas que dabas por perdidas y que realmente habías dejado en algún sitio pensando en organizarlo algún día.

Organizo los datos, muevo los archivos entre los discos, compruebo que son legibles una vez movidos, me doy por satisfecho, apago el ordenador y me voy a dormir. Esto fue la noche del domingo al lunes.

El lunes enciendo el ordenador pensando en cómo iba a organizar el día para formatear, y me da por comprobar un archivo de escritura que había encontrado y que daba por perdido. Cuando hago doble click para abrirlo, veo que el archivo tarda en cargar más de 1 minuto. "No puede ser, son pocos cientos de kilobytes de texto plano, esto debería volar" y, cuando por fin se abre el editor de texto, me encuentro lo siguiente:

Error de LibreOffice al abrir el archivo. Original.

Y se me encienden las alarmas: tengo el explorador de archivos abierto y veo el archivo frente a mí. ¿Cómo que no se puede leer el archivo?

Elijo otro archivo y hago click con el botón derecho del ratón para ver las propiedades del archivo. El menú no salta, el explorador de archivos se bloquea a los pocos segundos y, pasado un minuto, Windows me avisa de que el explorador de archivos se ha bloqueado y que necesita reiniciarse.

Y entro en modo alarma: si explorer.exe necesita reiniciarse por algo como mirar las propiedades de un archivo, o he pillado un virus como un camión (improbable) o ha pasado algo con el disco duro. Intento reiniciar el equipo pero el arranque no pasa de POST. Apago el ordenador de un botonazo, espero unos segundos y vuelvo a encenderlo. Para mi alivio, el equipo enciende bien, llega al escritorio y parece que tengo todo funcionando. Pruebo a reiniciar de nuevo y se queda parado de nuevo en POST. Vuelvo a apagar, a encender y vuelve a funcionar, pero esta vez pido al ordenador que apague en lugar de reiniciar y, cuando lo enciendo de nuevo, arranca sin problemas.

En adelante, cuando diga "reiniciar" me refiero a que "apago y enciendo manualmente", lo que creo que ha tenido un papel importante en esta historia.

Tras este nuevo susto, una comprobación rápida me dice que el problema se limita a uno solo de los discos físicos del equipo: un Seagate Barracuda de 1500 GB a 7200 RPM de entre 10 y 15 años, con interfaz SATA. No se ha usado en servidores, ni montado en RAID ni usado para minería, y siempre que ha viajado lo ha hecho desconectado y adecuadamente protegido.

En resumen: un disco mécanico que ha almacenado datos domésticos. El equivalente en hardware de obtener una plaza como funcionario en un sitio tranquilo.

Mi siguiente paso es comprobar los datos SMART del disco. Para los que no sepan de qué hablo, SMART son las siglas de Self-Monitoring, Analysis and Reporting Technology, un sistema integrado en la mayoría (por no decir todos) los discos duros del mercado, cuya función es recopilar y ofrecer información del estado de salud del disco duro. Son datos interesantes que te indican qué puedes esperar del disco, si es muy viejo, si está muy dañado o si quien te lo ha querido vender como nuevo en realidad te está intentando colar un disco que lleva 5 años en un clúster de minería. No es un estándar absoluto, ya que algunas combinaciones de disco, placas base y software podrían no ofrecer esos datos, pero todavía no he encontrado esa situación.

Windows no ofrece acceso a esos datos nativamente, pero encontrar software para conseguirlo es muy sencillo. Personalmente he usado Crystal Disk Info o el módulo SMART de EaseUS en Windows, que funcionan bien con las licencias de prueba. Si estás en Linux, la utilidad de disco (gnome-disk-utility en Ubuntu) ofrece datos SMART sin necesitar software adicional, y aunque no puedo hablar por otras distribuciones, es bastante probable que las herramientas de administración de disco de esas distribuciones tengan esa funcionalidad ya integrada.

Volviendo al tema, tras instalar EaseUS, arranco el módulo SMART y me encuentro con lo siguiente:

Módulo SMART de EaseUS. Esta imagen ha sido editada para ejemplificar los resultados originales y censurada por privacidad.

SMART indica que el disco está deteriorado: 124 sectores reasignados, que supera con mucho el umbral de 40 que propone la aplicación y los 90 que vi hace un par de meses. No es una buena noticia, pero ese dato por sí solo no explicaría el comportamiento del disco ni lo que ha pasado con los reinicios.

Antes de seguir (sáltate los próximos 3 párrafos si sabes lo que es), explicar lo que es un "sector reasignado" es bastante sencillo: cada disco mecánico segmenta la superficie de los discos en sectores, y la tabla de partición y el sistema de archivos gestionan el dónde y cómo se almacenan los archivos en esos sectores. Si durante una lectura del disco la controladora detecta que el sector es ilegible porque está dañado, elige otro sector del disco y la controladora toma ese nuevo sector como si fuera el original. Ese sector pasa a estar reasignado y la controladora, cuando quiera acceder a la información del sector original, pasará a buscarla en el sector reasignado. Generalmente los discos reservan algunos sectores para estos casos, pero cada sector reasignado resta capacidad al disco, y cuantos más sectores se reasignan, más complicado es para el disco encontrar la información que necesita rápidamente.

Todo este proceso es transparente, incluso para el kernel del sistema, ya que estas gestiones son tarea de la controladora del disco duro. Piensa en la controladora del disco como en una bibliotecaria, que sabe dónde y cómo se ha almacenado la información, si un libro se ha guardado en otro sitio por alguna razón y que solamente avisará al kernel si el archivo no existe, es ilegible o está corrupto.

Si quieres saber más, la arquitectura de almacenamiento de datos en discos mecánicos es un tema interesante, especialmente los conceptos de contigüidad y fragmentación de archivos. Con el auge de los SSD empiezan a quedarse anticuados, pero son muy interesantes si te gusta la historia o trabajas en almacenamiento de información o recuperación de datos.

Mi siguiente paso me lleva a una herramienta de Windows que muchos hemos visto y utilizado, pero que no parece muy útil hasta que la usas para lo que es: CHKDSK.

CHKDSK (siglas de Check Disk) es una herramienta de terminal en Windows pensada para comprobación de metadatos y errores físicos y lógicos en discos duros. Aunque no te arregla un disco roto, es capaz de reparar bastantes de los errores lógicos que pueden aparecer por uso y, en algunos casos, devolver el disco a un estado funcional el tiempo suficiente para averiguar qué ha pasado o sacar datos del mismo.

Ejemplo de ejecución de chkdsk. Fuente

Debes saber que chkdsk NO hace una verificación de integridad de los archivos dentro del disco. Se limita a comprobar la tabla de particiones y el sistema de archivos e información de auditoría del disco, y a intentar reparar discrepancias. Si hay un archivo dañado porque el programa que lo ha generado ha cometido algún error o el sector que lo almacena está estropeado, chkdsk no podrá solucionarlo.

Sin embargo, si hay un problema en el sistema de archivos y hay que reconstruirlo (como sospechaba), chkdsk es quien puede hacerlo.

Abro terminal, ejecuto el comando y...

El susto. Fuente

Lo que es una noticia terrible: todos mis datos están dentro, y de una partición RAW sólo se sacan datos después de formatear, con herramientas de recuperación y haciendo sacrificios a múltiples deidades (o a todos los panteones conocidos si es un SSD).

Pero pasado el susto inicial, empiezo a extrañarme: ¿por qué chkdsk me dice que la partición no tiene formato (o no es legible) si el explorador puede ver archivos en su interior? Es cierto que se bloqueaba inmediatamente si abría algunos archivos y tardaba un poco en otros, pero el sistema veía el contenido.

Si la partición no tuviera formato o estuviera corrupto, el sistema no podría montarla y los archivos no serían accesibles en ningún momento. El disco no podía estar sin formatear. Al menos, no todo el tiempo, y los discos no pierden el formato espontáneamente para recuperarlo en el siguiente reinicio.

Mi confusión aumenta al abrir el administrador de disco (diskmgmt.msc) y comprobar que el disco estaba ahí, que se reconocían las particiones y que tenían formato. Y mi cordura se pone a prueba cuando, sin reiniciar, vuelvo a abrir el administrador de disco 5 minutos más tarde y las particiones han perdido el formato, pero vuelven a aparecer en el siguiente reinicio.

Entre seguir investigando y recuperar los datos, opto por la segunda opción. Compro un disco nuevo, lo dejo listo para conectar al equipo y empiezo a ver si puedo sacar datos del disco dañado, y cómo.

Una decisión que creo que ha salvado los datos.

Descargo e instalo DiskGenius, que tiene herramientas de recuperación de datos y clonación de particiones. Al abrirlo, veo que reconoce el disco físico, pero que es incapaz de ver más allá del número de serie y la velocidad en RPM del disco.

Usando las herramientas de análisis y recuperación, veo que las cabeceras del disco no son legibles. Refresco el explorador de archivos y ahí sigue el disco, accesible, así que pruebo a lanzar el analizador de disco, que comprueba los sectores del disco. Y mientras explorer.exe me dice que el disco sigue ahí, DiskGenius me dice que no hay un solo sector sano en los primeros 2-3GB del disco.

¿Qué está pasando para que el sistema operativo reconozca el disco al arranque pero que cualquier software que inicie después sea incapaz de leerlo a casi ningún nivel? ¿Cómo puede ser que el espacio donde se almacenan las tablas de partición y el sistema de archivos sean ilegibles, pero que las particiones sean legibles justo durante el reinicio?

Reinicio nuevamente, entro al administrador de disco e intento formatear una de las particiones del disco, que contenía datos que no necesitaba. El asistente funciona bien, pido formato rápido manteniendo el tamaño de asignación de la partición, pero tras casi dos minutos...

El disco no puede formatearse.

Al siguiente reinicio, las particiones del disco no cargan y el administrador de disco me dice que todas las particiones han pasado a formato RAW, manteniendo la etiqueta del volumen. Reinicio nuevamente y vuelven a aparecer las particiones, con su formato y sus archivos.

Y me quedo mirando a la pantalla sin saber qué demonios está pasando.

Me siento a pensar en las posibilidades y a priorizar en qué datos quiero sacar del disco si es que consigo sacar algo. Llegados a este punto, el disco duro tiene que estar a punto de no arrancar más (como así ha pasado), de modo que voy contrarreloj.

Conecto el disco nuevo, me aseguro de que esté bien, formateado, que haya espacio suficiente para volcar datos y copio una carpeta con menos de 200MB de contenido. Todo el proceso me lleva unos 2-3 minutos, pero el explorador de archivos se cuelga y reinicio después de anotar la hora a la que se ha colgado.

Tras reiniciar, acudo al Visor de Eventos del sistema, y busco lo que ha pasado en ese momento. Encuentro lo que busco, pero no es lo que esperaba.

Error al intentar copiar un archivo dentro del disco dañado, indicando la dirección del bloque afectado. Original.

El sistema intenta restablecer un disco RAID en el puerto 0. Es el disco dañado. Original.

Error de paginación en el disco duro dañado. Original.

 Tras decenas de errores idénticos a este último, encuentro un error diferente y relacionado:

Error al leer o escribir un archivo dentro del disco. Original.

Error en el registro transaccional del sistema de archivos. Especifica el ID del disco y que éste no existe. Original.

Pop-up notificando el error al usuario (yo). Original.

 

Casi se me escapa: error al vaciar el registro transaccional del disco afectado. Original.

Retrocedo en el tiempo y encuentro una secuencia similar en cada intento de acceder a los datos:

1. Error al acceder a un bloque del disco.
2. Restablecimiento del puerto.
3. Decenas o cientos de errores en paginación del disco.
4. Error (timeout) al intentar leer un archivo o carpeta.
5. Notificación de que el disco ha desaparecido.
6. Notificación al usuario.
7. Error al vaciar el registro transaccional del disco desconectado. 

Y esta secuencia, o muy similar, está en cada intento de extraer datos de ese disco.

Tras pensar en ello, me doy cuenta de que hay algo que no debería haber en ese disco: paginación. ¿Por qué Windows iba a paginar con la RAM por debajo del 25%? ¿Por qué usar paginación en un disco mecánico que no es el de sistema, cuando el de sistema es un SSD? Y aunque la usara, ¿por qué la paginación iba a caer siempre cerca de un sector dañado del disco, como veo en cada secuencia de errores?

Desactivo la paginación del disco, reinicio y trato de copiar una carpeta. Y consigo copiar datos.

Mi alegría no dura al ver que ha copiado solamente 1 de cada 3 archivos aproximadamente. Repito el proceso, y veo que hay más archivos y más espacio ocupado, pero que faltan archivos de nuevo. Repito la operación dos veces más y tanto el tamaño como el número de archivos de ambas carpetas coincide. Abro varios archivos al azar y los recorro, y compruebo que los datos se han copiado correctamente.

Sin embargo, al ir a copiar otra carpeta, el explorador vuelve a fallar. Reinicio y vuelvo a intentarlo, y esta vez la copia empieza, pero se interrumpe por completo al llevar un 20-25%. Veo muchos menos eventos nuevos en el Visor de Eventos y que las referencias a la paginación han desaparecido. Reinicio y lo intento de nuevo, y se copian más archivos.

Por no alargarlo, tras muchas iteraciones he conseguido rescatar casi todos los datos que quería. No estoy 100% seguro de haberlo copiado todo, pero lo más importante sí ha salido del disco, está a salvo y es accesible, y lo poco que he echado de menos puedo sacarlo de otros sitios.

Así que, con la quest principal completada, es hora de ver qué ha pasado con el desastre.

Lamentablemente, el ordenador ha dejado de reconocer las particiones del disco, por lo que no puedo replicar el proceso de nuevo. Lo que sí puedo hacer es analizar los logs que tengo y tratar de averiguar qué ha pasado.

Y tras pensarlo un poco, tengo una teoría sobre lo que puede haber pasado.

Durante estos años, el disco duro ha reasignado sectores a medida que han ido fallando pero, en algún momento de la última semana, ha intentado reasignar un sector que ha dañado la controladora de alguna forma. Durante el reinicio del equipo (a diferencia de un apagado usando Fast Boot) el equipo intentaba arrancar la controladora del disco duro desde cero. Al estar dañada detenía el proceso de arranque del equipo en POST o justo después, por lo que solamente cargando la imagen almacenada por Fast Boot era posible arrancar correctamente el disco, al devolver la controladora a un estado anterior funcional.

Las controladoras no se reinician, sino que se restauran durante el arranque con Fast Boot (fuente).

Al estar habilitado Fast Boot, sabemos que la controladora volvía al estado previo al fallo que tenía anteriormente. Desconozco qué fallo tenía la controladora, pero podría ser un desbordamiento de la memoria integrada o de alguna de sus cachés por fallo de alguno de los chips integrados. Sabiendo que Fast Boot no sólo restablece procesos en RAM sino estados de las controladoras, es bastante probable que las direcciones de memoria del disco paginado persistieran al reinicio. Esto, unido a que Windows estaba usando el disco para paginación, significaba que (probablemente) intentaba paginar en el mismo punto del disco que antes del reinicio. Si dichas direcciones contenían o estaban cerca de sectores dañados, y ni Windows ni la controladora del disco podían reasignarlas, el disco volvería una y otra vez a un estado cercano al fallo. Si la escritura de la paginación es secuencial y contigua (lo que no es descabellado en un disco mecánico), podían bastar unos pocos megas de datos o unas pocas instrucciones sobre los archivos para llegar a esa sección errónea y provocar el fallo del disco.

Si a esto sumamos que la controladora estaba en un estado cercano al fallo, es posible que la paginación forzase a la controladora a reasignar un sector o a buscar un sector reasignado (considero más probable la primera opción), precipitando el fallo. Al desaparecer la paginación, la controladora no se veía obligada a realizar la transacción, operación o asignación que estaba causando el fallo, o a reducir el número de operaciones que debía realizar. Si el fallo estaba en un desbordamiento de memoria por fallo de un chip integrado, al reducir el número de operaciones y/o hacerlas más pequeñas (no es comparable el tamaño de la copia de un archivo con la escritura de un archivo de paginación) era posible realizar un número mayor de operaciones en el mismo tiempo antes de un fallo de la controladora.

Esto viene reforzado por varios hechos: primero, que la mayoría de los archivos eran legibles durante un tiempo breve tras el reinicio; segundo, que una vez deshabilitada la paginación fue posible copiar cientos o miles de archivos antes de un fallo, frente a los pocos archivos o propiedades antes de deshabilitarla; tercero, que sólo unos pocos archivos no han podido ser copiados, seguramente por fallo del disco en esos sectores en concreto; cuarto, el fallo del disco era total una vez alcanzado cierto número de operaciones, lo que hacía que los programas de análisis de disco fallaran ante análisis exhaustivos (como puede ser un escaneado profundo de archivos o una reconstrucción de la tabla de partición).

Existe el contraargumento de que si se trataba de un desbordamiento de memoria, cada ciclo de apagado iría acercando el límite de operaciones que la controladora realizaría antes de fallar. Sólo puedo especular sobre el motivo, pero mi teoría es que, al restaurar el driver durante el arranque, aunque se restaurasen las memorias integradas, si el chip dañado se encontraba al final de las direcciones de memoria de la controladora, y si el número de operaciones por unidad de tiempo se mantenía por debajo de un umbral, esas direcciones de memoria no serían necesarias y, por tanto, la controladora no llegaría a fallar. Considero que es una buena explicación dado que se han copiado bloques de miles de archivos, sin fallar en archivos grandes (>100MB) y con volúmenes que superaban los 20GB por bloque, y que los fallos que he encontrado se han dado cuando he intentado copiar decenas de archivos pequeños (~4KB) en poco tiempo o cuando he pedido copia simultánea de dos carpetas diferentes, ya que al repetir la copia de los archivos el sistema operativo reconocía los archivos ya copiados y daba la opción de omitir esos archivos y continuar con el siguiente bloque.

Por lo que he visto, si cada ciclo de apagado reducía el límite de operaciones, la reducción no ha sido notable.

En definitiva, una controladora dañada ha estado a punto de borrarme casi 15 años de datos.

Llegados a este punto, sólo queda preguntarse qué se puede hacer para evitar que vuelva a suceder. La realidad es que sólo hay una solución: hacer backup más a menudo. Habrá quien proponga montar discos en RAID o almacenamiento en nube, pero tengo un NAS con 4 discos en RAID 5 y creo que con eso es suficiente. Es cierto que tendría que hacer backup más a menudo, y es algo que voy a ver cómo me organizo para hacer.

En fin, esto ha sido todo. Como veis, ha sido un susto bastante serio y he tenido MUCHA suerte. Normalmente, cuando te encuentras estos problemas ya es tarde para hacer nada, pero esta vez he podido actuar a tiempo y evitar una tragedia.

Ahora, me voy a echar la lotería, a ver si tengo la misma suerte que con el disco duro.

¡Hasta la próxima!