Hace dos días comencé la recuperación de un disco duro defectuoso de 1 TB que me entregaron con la esperanza de poder recuperar la mayor parte por un precio económico.
Al principio se comportaba de forma errática, a menudo se desconectaba repentinamente y hacía ruidos aterradores, con una velocidad de copia que variaba entre unos pocos KB por segundo y unos 50 MB por segundo (era un día caluroso, intenté evitar que se sobrecalentara con una almohadilla de enfriamiento para computadora portátil). debajo y un bloque de enfriamiento encima, que cambié aproximadamente cada hora). Luego, durante la primera noche, se volvió más estable, pero la velocidad de copia promedio disminuyó significativamente, a alrededor de 3-4 MB/s. Ahora, después de haber recuperado 250 GB, he bajado a unos 400 KB/s en promedio, lo cual es tremendamente lento (al menos no parece disminuir más).
Entonces mis preguntas son:
- Estoy haciendo esa recuperación en una partición NTFS, que, por lo que leí bastante tarde en el proceso (enesta guía francesa), no se recomienda ya que podría ralentizar considerablemente la recuperación. ¿Es (todavía) cierto y, de ser así, por qué?
- ¿O es cosa del pasado, cuando el controlador NTFS para Linux no era lo suficientemente maduro? (Estoy usando el último DVD en vivo de Knoppix, copiado a una tarjeta de memoria, ya que no arrancaba correctamente desde un DVD-RW).
- ¿Valdría la pena convertir la partición a un formato nativo de Linux como Ext4 en esta etapa? Quiero decir, ¿mejoraría significativamente la velocidad de copia?
- ¿O es normal experimentar tal desaceleración con un disco defectuoso, después de la primera pasada donde ya se han recuperado la mayoría de los sectores "saludables"? (Los parámetros SMART están empeorando, el “resultado de la prueba de autoevaluación de salud general” pasó de “APROBADO” a “FALLADO”, el número de sectores reasignados pasó de 144 a 1360.)
- ¿Hay algo más que pueda hacer para mejorar el índice de recuperación y/o la velocidad de recuperación?
- ¿Existen opciones
ddrescueque pueda probar con algún beneficio real?
Hice las primeras ejecuciones con este comando:
ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log
(Los interruptores -n& -Nsupuestamente omiten las fases de raspado y recorte, aunque no estoy seguro de en qué punto del proceso el programa intenta realizar esas acciones y si eso es realmente útil para omitirlas. Luego especifiqué una velocidad de copia mínima de 500000 bytes por segundo y un valor de 1 MB para "tamaño inicial a omitir en caso de error de lectura", intentando copiar lo más rápido posible las áreas que aún están en buen estado o son de fácil acceso. El -ues para "unidireccional": en una recuperación anterior con. otro HDD, copiar en sentido inverso con el -Rinterruptor pareció mejorar las cosas, pero con este parece causar estragos, y aparentemente es más estable con ese interruptor).
Ahora, después de completar una pasada, eliminé la mayoría de estos parámetros y solo conservé el archivo -u. Probé el -dcambio en algún momento (“usar acceso directo al disco”), pero luego no se copió nada, el “tamaño del error” creció muy rápidamente.
Respuesta1
Para completar mis comentarios anteriores (perdón por los inconvenientes/inconsistencias formales): diría que valió la pena, aunque no entiendo muy bien por qué. El segundo intento, recuperar en una partición Ext4, tuvo una velocidad de copia significativamente mayor al principio (alrededor de 90 MB/s en promedio, mientras que solo tuve alrededor de 50 MB/s en el mejor de los casos para el primer intento, recuperando en una partición NTFS) , y sin errores ni ralentizaciones. Pero luego, después de copiar unos 165 GB (antes que antes), se volvió muy inestable y se ralentizó, volvió a hacer clics y zumbidos (fue un período muy caluroso que no ayudó; traté de enfriarlo). hacia abajo tanto como sea posible, usando una almohadilla de enfriamiento para computadora portátil debajo y una bolsa de congelación encima, que se cambia aproximadamente cada hora); Lo intenté una y otra vez (a veces volvía a una velocidad de 120 MB/s durante unos segundos y luego volvía a 0), pero tuve que abandonarlo después de un tiempo.
Aquí hay un ddrescueviewmapa de la primera recuperación:
Hay un patrón interesante, con franjas de datos fácilmente recuperables que se alternan con datos muy lentos o ilegibles.[Por lo que sé, parece indicar que una cabeza entró en contacto con un plato, dañando la superficie y liberando polvo magnético, que luego se extendió con la fuerza centrífuga. Y dado que la pista del servo (que contiene información esencial para el proceso de inicio) está ubicada en el borde exterior del disco duro (es un Hitachi de 3,5" y 1 TB), es posible que parte de ese polvo haya llegado hasta él, dificultando el acceso. lo que podría explicar los frecuentes ruidos de clic al inicio.](Corríjame si me equivoco.) => [EDITAR 20200501] Eso estuvo mal; en realidad, este patrón generalmente indica que un cabezal de la unidad ha fallado por completo y ya no lee nada, es posible que los datos en los platos aún sean legibles. en este punto, pero requeriría el reemplazo del ensamblaje del cabezal, algo que solo un laboratorio especializado en recuperación de datos puede realizar de manera segura.
Aquí hay un ddrescueviewmapa de la segunda recuperación:
Así que el disco duro se volvió muy inestable y la recuperación cada vez más difícil después de unos 165 GB, pero antes de eso la velocidad de copia era consistentemente alta, sin áreas omitidas. Más tarde utilicé el ddru_ntfsbitmapmétodo, en los últimos intentos, por lo que la mayor parte del espacio no asignado se omitió.
Aquí hay un ddrescueviewmapa del archivo de registro creado con ddru_ntfsbitmap, que muestra las áreas del disco duro que contienen datos reales en verde y el espacio libre en gris:
Afortunadamente, la mayoría de los datos reales se localizaron en el primer trimestre y se recuperaron con éxito. Ahora todavía tengo que combinar las partes buenas de esas dos imágenes y extraer los archivos reales, probablemente con R-Studio (el mejor software de recuperación de datos que he probado).
Una cosa que descubrí más tarde que es interesante y peculiar, con respecto a mi pregunta inicial (supongo que debería haber puesto esto como un comentario, según las reglas formales, pero habría sido demasiado largo y no podría haber proporcionado capturas de pantalla). .
Intenté copiar las áreas rescatadas de la imagen 2, en la partición Ext4, que faltaban en la imagen 1, a esa imagen 1, en la partición NTFS {1} , lo que debería haberse hecho a una velocidad muy alta (entrada y salida). estando en un disco duro de 2 TB en buen estado), sin embargo, obtuve una velocidad promedio de solo 660 KB/s, por lo tanto, muy cerca de la velocidad de la recuperación inicial en una etapa posterior, cuando me preocupé lo suficiente como para hacer esta pregunta en primer lugar. ..
Comando utilizado (archivo de registro para la imagen 2 utilizado como archivo de registro de dominio):
ddrescue -m [image2.log] [image2] [image1] [image1.log]
Captura de pantalla:
Entonces me detuve e hice lo contrario: copié las áreas rescatadas en la imagen 1 (NTFS) que faltaban en la imagen 2 (Ext4), en esa imagen 2, y ahora la velocidad de copia fue de aproximadamente 43000 KB/s o 43 MB/s. en promedio (tal vez un poco más lento de lo que se debería esperar para una copia en el mismo disco duro, para un Seagate de 2 TB que tiene una velocidad máxima de escritura cercana a los 200 MB/s, por lo que debería poder alcanzar unos 100 MB/s para un copiar de una partición a otra, pero aún así casi 100 veces mejor que el primer intento). ¿Cuál sería la explicación para tan tremenda discrepancia?
Comando utilizado (archivo de registro para la imagen 1 utilizado como archivo de registro de dominio):
ddrescue -m [image1.log] [image1] [image2] [image2.log]
Captura de pantalla:
Noté que los archivos de imagen en ambas particiones tenían un “tamaño en disco” {2} correspondiente a la cantidad de datos que realmente se habían escrito, muy lejos del tamaño total (1 TB o 931,5 GB), aunque no lo hice. No use el -Sinterruptor (“use escrituras dispersas para archivos de salida”). La imagen 2 (después de completarse con áreas rescatadas adicionales de la imagen 1) tiene un "tamaño en disco" de 308,5 GB, mientras que la imagen 1 tiene un "tamaño en disco" de 259,8 GB. ¿Podría estar relacionado con la velocidad de copia lenta, si el controlador NTFS de Linux de alguna manera tiene problemas para manejar escrituras escasas? ¿Y por qué no se asignó todo el tamaño tan pronto como se escribieron los sectores al final, considerando que no usé ese -Sinterruptor?
Intenté usar el -pinterruptor (“preasignación”) al comienzo del proceso, pensando que sería “más limpio”, más sencillo, más fácil de manejar en caso de que algo saliera mal (si es necesario recuperar la recuperación). ..), pero tuve que detenerme porque era demasiado largo y quería comenzar lo antes posible (aparentemente, en realidad escribe datos vacíos en lugar de simplemente asignar los sectores requeridos). Luego pensé que al usar el -Rinterruptor (“reverse”) temporalmente, escribiría los últimos sectores en el archivo de salida, asignando así el tamaño completo como pretendía; De hecho, resultó en un aumento del tamaño del archivo de salida a 931,5 GB, pero el "tamaño en el disco" era de hecho mucho menor (lo noté más tarde cuando accedí al disco duro utilizado para esa recuperación en Windows y vi la cantidad anormalmente alta de archivos libres). espacio).
________________
{1} Todavía no entiendo cómo el segundo intento de recuperación pudo producir un resultado mucho mejor para los primeros 100 GB aproximadamente, a pesar de que el estado de salud del disco duro había empeorado mientras tanto. [EDITAR 20200501] => Posiblemente se deba al a500000parámetro utilizado al principio, que omitía áreas cuya velocidad de lectura estaba por debajo del umbral de 500 KB/s. Sin esa opción, la segunda vez, lee las áreas más lentas de inmediato. De hecho, esas áreas más lentas estaban asociadas con un cabezal débil, por lo que sigue siendo desconcertante que este cabezal defectuoso haya logrado obtener tantos datos la segunda vez, aunque ya había mostrado signos de mal funcionamiento. Todavía estoy aprendiendo...
{2} Por cierto, la palabra “disco” debería reemplazarse, tanto en sistemas Windows como Linux, ya que hay unidades de almacenamiento de datos que no son “discos”...
Respuesta2
Es posible que desee copiar primero la imagen del disco condddominio
sudo dd bs=[tamaño_bloque] count=[NofBlocks] if=[archivo_entrada] de=[archivo_salida]
dónde
[in_file] - puede ser el disco roto, digamos /dev/sdd2
[out_file]: ubicación del archivo de imagen de salida.
- Monta la imagen e intenta recuperarla.