Recientemente tuve un amigo con un nuevo disco duro interno de escritorio Hitachi de 2 TB, 32 MB, 7200 RPM, 3,5" SATA 6,0 Gb/s con sistema operativo Win7 Pro que Windows informó que fallaba. Me pidió que lo recuperara y reemplazara el disco. Esto no era un unidad de arranque. Todavía tenía algunos días para devolverlo al proveedor.
No pude acceder a él con nada en una PC nueva (con diferentes controladores SATA que funcionan y cables de alimentación y datos SATA).
Curiosamente, el DFT de Hitachi informó que todo estaba bien: Estado SMART: Saludable
Registro de prueba
ReadErrStat : Done
Result : Pass
SMART QT : Done
Result : Pass
A pesar de 3 eventos de Windows que indican la misma falla SMART. Descripción: El controlador ha detectado que el dispositivo \Device\Harddisk3\DR3 ha predicho que fallará. Haga una copia de seguridad de sus datos inmediatamente y reemplace su unidad de disco duro. Una falla puede ser inminente.
Utilicé ddrescue 1.18.1 en el CD System Rescue.
Debido a que el disco duro era nuevo, esperaba que todos los datos/archivos estuvieran en el primer cuarto del disco. ddrescue tardó aproximadamente 25 horas en abrirse camino a través de la unidad de 2 TB y escribir en una nueva unidad de 2 TB (sospecho que algunos ahora saben cuál será mi problema). No tenía discos más grandes.
ddrescue -n -f /dev/sdb /dev/sdc resq.log
ddrescue recuperó todos los archivos excepto 347 (aproximadamente el 0,5%), pero informó que no pudo finalizar correctamente porque se quedó sin espacio en la unidad de destino. La lenta tasa de transferencia, así como el creciente número de archivos no recuperados, terminaron aproximadamente una cuarta parte del proceso de recuperación, lo que indica que ya no era donde estaban presentes (o al menos la mayoría) los archivos de datos y ahora estaba literalmente recuperando territorio virgen.
Ambos estaban formateados en NTFS, con una partición única de todas las unidades (la nueva era una nueva unidad de disco duro Toshiba de 2 TB).
En Linux, no puedo montar la unidad recuperada para copiarla ni verla. Sigue recibiendo error de formato NTFS.
No quiero ver si hay algo visible en un sistema operativo Windows debido a la propensión de estos a ofrecer arreglar cosas, lo cual no quiero que intente.
Para empeorar las cosas, compré y formateé GPT una unidad de 4 TB y comencé a repetir el ddrescue y el disco duro defectuoso falló por completo en menos del 10% del camino.
He estado leyendo el manual de ddrescue así como varios foros y no puedo encontrar ciertas instrucciones sobre cómo reparar la unidad de destino "completa" para que sea accesible. No quiero cometer ningún error que pueda corromper aún más los datos. ¿Alguien tiene alguna idea sobre rescate/reparación para poder hacer una copia y luego ver qué se recuperó y dónde están las cosas?
Respuesta1
Cuando dices "ddrescue recuperó todos los archivos byt 347", ¿qué quieres decir? ddrescue debería hacer una copia de bits del disco duro, por lo que no maneja archivos.
No está claro dónde está o estaba su registro de rescate. ¿Aún lo tiene?
Me inclinaría por hacer una copia pequeña de la unidad de 2 TB en buen estado a la de 4 TB.
Luego intentaría hacer un ddrescue nuevamente desde la unidad defectuosa de 2 TB a la buena unidad de 4 TB, pero esta vez agregando el modificador -R para que intente recuperarse desde el final del disco (porque creo que las unidades de 2 TB tenían tamaños ligeramente diferentes). por lo que no obtuvo el final). Si tiene acceso al archivo de registro, intente usarlo también, ya que probablemente le hará la vida un poco más fácil, pero supongo que no es crítico.
Luego vería si puedo acceder a los datos (desde la unidad de 4 gigas) en Linux, si no, y espero que no pueda hacerlo, lo intentaría en Windows y vería si podía leerlos.
Si esto falla, usaría Photorec en la buena unidad de 2 TB para lograr todo lo que pudiera, sin pasar por NTFS.