Después de tanto batallar pudimos hallar la respuesta de este atascamiento que algunos lectores de este sitio web han tenido. Si deseas aportar algún detalle no dudes en aportar tu conocimiento.
Solución:
En primer lugar, no hagas nada mas en el disco (al menos nunca escribir lo). El disco no ser reconocido (a diferencia de “ser reconocido y encontrado vacío o con datos ilegibles”) parece indicar un disco completamente destruido, que chkdsk no es habitual, o hay algún problema con la tabla de particiones o la geometría del disco, o la forma en que lo maneja la caja USB. También es posible una falla de hardware.
Esto puede suceder y sucederá cuando los receptáculos USB intentan negociar entre el disco y la computadora a la que están conectados. Entonces, lo primero que debe hacer sería tomar una imagen del disco en un disco (obviamente más grande) en el nivel más cercano al físico posible, usando dd bajo Linux. Luego, puede jugar con una copia de la imagen al contenido de su corazón, sin riesgo de dañar más el disco real.
Actualización: reconocimiento de dispositivos en Linux
No tenemos menos de Tres entidades en nuestro “disco externo”. El hardware de la caja USB, que se expone como un dispositivo de bloque. El disco físico dentro del gabinete. El dispositivo físico, es decir, la secuencia de sectores LBA del primero al último. Y finalmente cero o más particiones de datos, alojando los sistemas de archivos. Para ser “reconocidos” y mostrados en un escritorio, todos los eslabones de las cadenas deben estar funcionando. Pero para tomar una imagen del dispositivo físico solo necesita los dos primeros. Si conecta el dispositivo y ejecuta la línea de comandos dmesg (como root), debería ver algo como esto:
[4984939.028491] usb 8-6: new high speed USB device using ehci_hcd and address 3
[4984939.166658] usb 8-6: configuration #1 chosen from 1 choice
[4984939.170660] scsi7 : SCSI emulation for USB Mass Storage devices
[4984939.172003] usb-storage: device found at 3
[4984939.172005] usb-storage: waiting for device to settle before scanning
… que es el gabinete que se reconoce y luego se identifica a sí mismo y a su contenido:
[4984939.170660] usb 8-6: New USB device found, idVendor=1058, idProduct=1021
[4984939.170660] usb 8-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4984939.170660] usb 8-6: Product: Ext HDD 1021
[4984939.170660] usb 8-6: Manufacturer: Western Digital
[4984939.170660] usb 8-6: SerialNumber: 574D43305431303831303734
[4984944.400970] usb-storage: device scan complete
A continuación, verá el controlador informando de su geometría, naturaleza e implícitamente su nodo de dispositivo, aquí sdd (para SCSI Disk Four, desde sda, sdb y sdc ya fueron tomadas):
[4984944.404739] scsi 7:0:0:0: Direct-Access WD Ext HDD 1021 2021 PQ: 0 ANSI: 4
[4984944.404739] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
[4984944.407367] sd 7:0:0:0: [sdd] Write Protect is off
[4984944.407369] sd 7:0:0:0: [sdd] Mode Sense: 17 00 10 08
[4984944.407371] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[4984944.408741] sd 7:0:0:0: [sdd] 1953519616 512-byte hardware sectors (1000202 MB)
Luego, el kernel reconoce que hay una partición (si no ve esto, la partición no está allí o no es válida):
[4984944.411497] sdd: sdd1
Ahora Linux tiene todo lo que necesita y reporta un adjunto exitoso:
[4984944.416739] sd 7:0:0:0: [sdd] Attached SCSI disk
[4984944.416739] sd 7:0:0:0: Attached scsi generic sg4 type 0
Y así comienza la búsqueda de la partición de datos, es decir, está bien, tenemos sdd1, pero ¿Qué hay ahí?, y la respuesta es:
[4984997.498613] NTFS driver 2.1.29 [Flags: R/W MODULE].
[4984997.554613] NTFS volume version 3.1.
[4984997.568859] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
[4985390.027808] NTFS-fs error (device sdd1): ntfs_remount(): Volume has errors and is read-only. Cannot remount read-write.
[4985442.423299] NTFS volume version 3.1.
[4985442.425032] NTFS-fs error (device sdd1): load_system_files(): $LogFile is not clean. Mounting read-only. Mount in Windows.
Este de arriba fue un “buen” montaje. Pero solo sabiendo que el dispositivo es sdd, o sdc o sdb, me permite hacer una copia binaria (suponiendo que tenga suficiente espacio libre en /mnt/backupdisk): fichero de entrada /dev/sdd, archivo de salida DiskImage.raw, tamaño de bloque 1 MB:
# dd if=/dev/sdd of=/mnt/backupdisk/DiskImage.raw bs=1M
Nota que el archivo de entrada es /dev/sddy no/dev/sdd1
(o cualquier otro número). Ahora, si quisiera, podría averiguar el desplazamiento de la partición de datos dentro DiskImage.rawy móntelo con la ayuda de un dispositivo de bucle. Aquí encontrarás los detalles sucios.
Primer intento de recuperación
La segunda cosa a hacer sería colocar el disco físico en otro gabinete, asegurando así que el gabinete sea bueno y tenga la oportunidad de que el nuevo gabinete interprete correctamente el disco. Si el disco vuelve a aparecer, es posible que se haya roto el gabinete anterior. Por si acaso, haga una copia de seguridad de todos los contenidos de la unidad recién descubiertos, verificar la copia de seguridad, ponga a cero el disco con una utilidad de sobrescritura de disco para que completamente tonto (no puede tener dos dispositivos con opiniones diferentes en una cadena de dispositivos), vuelva a formatearlo de forma nativa desde Windows y restaure los datos. Es un golpe de suerte, pero lo vi suceder; y el intento no es demasiado caro, los recintos buenos cuestan unos 19,99 dólares nuevos.
En caso de que la carcasa original fuera defectuosa, no podrá volver a formatear el disco o no se podrá acceder al mismo. Puede volver a intentar el nuevo gabinete y, si funciona, reemplace el gabinete antiguo o siga usando el nuevo (pero esto vale la pena si el nuevo gabinete es bastante mejor que un El Cheapo de US $ 19,99).
Recuperación profesional
Servicios de recuperación profesionales, los que puedes encontrar con Google. Una forma no demasiado honesta de hacerlo sería enviar el disco físico y, en caso de que recibas un “Sí, no hay daños en el hardware y podemos recuperar todos tus datos por solo $ $$$, $ $$! ” respuesta – bueno, entonces saber que los datos aún se podían recuperar. Por lo tanto, puede intentar hacerlo usted mismo de forma gratuita en la copia de seguridad de la imagen que tomó, y solo pagar por el diagnóstico y el envío y envío del disco. Si fallaba, la opción de toser la masa solicitada seguiría estando ahí. Sí hay es daños en el hardware, el servicio profesional es básicamente su solamente opción. Hay varios trucos de vudú que reactivarán (temporalmente) un disco “muerto”, a menudo el tiempo suficiente para recuperar al menos los datos más importantes, pero ninguno que está garantizado para funcionar cada vez (calentar el disco, enfriarlo, “girarlo”, incluso vi la sugerencia de golpearlo inteligentemente contra una superficie dura). Todos ellos harán más daño, es decir, debes asegurarte de usar el único truco que funcionará la primera vez, o habrás matado el disco para siempre. Acabo de agregar esto para explicar por qué verá historias de éxito sobre discos revividos: allí están tales historias. Pero si quieres estar (mayormente) seguro de que le sucederá ustedBueno, contrata a un profesional.
Si está seguro de que el hardware está bien: el disco gira, no se traquetea, no hay sonidos o zumbidos extraños, no hay recalibraciones de clics-clackety, entonces “todo” lo que sucedió es que chkdsk estropeó algunos datos.
Recuperación de bricolaje
La recuperación “de inicio” normalmente sería así (básicamente lo mismo que harían los profesionales una vez descontado el daño del hardware), trabajando en la copia de la imagen del disco:
-
compruebe si el primer sector de la imagen del disco es una tabla de particiones válida. De lo contrario, escanee la imagen del disco en busca de una tabla de particiones válida o un sector de arranque NTFS o FAT32 reconocible, dependiendo de qué FS había en la unidad (para una unidad de 1 TB, NTFS parece la única posibilidad lógica). De cualquier manera, debería encontrar algo dentro de los primeros megabytes.
-
si se encuentra la tabla de particiones, verifique que la partición de datos esté donde la tabla de particiones dice que debería estar. Si no es así, esta es una muy buena noticia: probablemente la tabla de particiones es todo lo que está mal. Arreglarlo es fácil (varios editores de particiones de Linux lo harán), y se puede esperar que el disco se recupere al 100%. Para estar seguro, intente montar la partición de datos en Linux con un dispositivo de bucle en modo de solo lectura para ver si es legible. Si es así, se confirma el borking de la partición y es posible que el disco se pronuncie en su camino hacia una recuperación segura y completa. Si no es así, posiblemente la partición sea correcta y una (parte de) una partición de datos haya sido reescrita. Esto es malo; ver más abajo bajo “las cosas se ponen feas”.
-
si se encuentra y es válido, compárelo con la geometría de la unidad y, si no coinciden, eso también es en realidad un bien cosa, ya que es posible que haya encontrado la causa raíz del problema. Puede forzar la geometría física al kernel (y obtenerla en el arranque de Linux). Vea si la nueva geometría hace que el disco sea reconocido en Linux. Si es así, haga una copia de seguridad de los datos, verifique que la copia de seguridad sea correcta y ponga a cero el disco con
dd(un par de megabytes de ceros al apropiadosddispositivo son suficientes). Apague la computadora (no solo reinicie; está bien, es paranoico, pero cuesta poco y puede lograr algo), luego inicie Windows y haga que formatee el disco ahora desorientado en lo que cree que es el mejor formato. Esto asegura que no haya conflictos con Windows. Restaurar datos en el disco. Disfrutar. -
si el truco de geometría no funciona, o no se puede encontrar la partición, o una vez que se encuentra parece estar vacía, las cosas se ponen feas. Necesita alguna herramienta de recuperación capaz de exploración la imagen del disco en busca de las áreas de datos (MFT, etc.) de los datos perdidos. Y una vez encontrados, interpretarlos para obtener los datos. Este es un trabajo difícil y no siempre se puede automatizar por completo. En un nivel más bajo y más desesperado, esto implica buscar las firmas del individual archivos, con la esperanza de que se encuentren en bloques contiguos en el disco. Sin embargo, este tipo de operación con mucho gusto dejaría a los profesionales. Lo hice varias veces, siempre con éxito, con viejos discos FAT. Lo hice de nuevo, con un 50% de éxito, con discos FAT32 más nuevos, más grandes y más fragmentados. I intentó un par de veces, con malos resultados (pero tenía copias de seguridad completas y realmente no lo estaba dando todo), en los mucho más complicados sistemas de archivos NTFS y ext4.
Recuperación manual desde Linux
Bien, entonces intentas montar la partición en Linux y obtienes errores (Darse cuenta de/dev/sdcy/dev/sdcNson cosas diferentes: la imagen se refiere a /dev/sdc).
# mount -t ntfs /dev/sdc1 /mnt/recovery
ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 1024 usa_ofs: 0 usa_count: 65535: Invalid argument
Record 1 has no FILE magic (0x0)
Failed to open inode $MFTMirr: Input/output error
… esto parece indicar que la partición, como el sistema cree que es, está mal o muy dañado. Veamos primero la primera opción:
# fdisk /dev/sdc
Obtienes algo como esto:
Disk /dev/sdc: 1000.2 GB, 1000204885504 bytes
1 heads, 63 sectors/track, 31008335 cylinders, total 1953525167 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d2b7596
Device Boot Start End Blocks Id System
/dev/sdc1 63 1953520127 976760032+ 7 HPFS/NTFS/exFAT
El siguiente paso será verificar el inicio real de la partición. Buscando en el archivo de imagen (o /dev/sdc) buscaremos la firma NTFS:
00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........
00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?...
00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J.......
# dd if=/dev/sdc bs=512 count=1 skip=63 2>/dev/null | hexdump -C | head -n 1
… con los datos anteriores, esperamos que el arranque NTFS esté en el sector 63, por eso configuramos skip. Además, intentaremos con cada sector en el primer (digamos) megabyte …
# dd if=/dev/sdc bs=512 count=2000000 2>/dev/null | hexdump -C | grep "00:EB 52 90 4E 54 46 53"
… solo para estar seguro de que hay sólo uno sector de arranque (me pasó esto. En un disco FAT32, pero todavía) y que no hay errores de lectura en ninguna parte.
Tu resultado
00007e00 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
es exactamente lo que esperaríamos: el sector 63 da un desplazamiento de 63 × 512 = 32256 = 7e00 hexadecimal. El sector de arranque NTFS está ahí y la tabla de particiones parece ser correcta.
Así que ahora podemos copiar una gran parte de /dev/sdc1 en, digamos, /tmp/mydisk.img e intentar arreglarlo desde Linux. Esto no dañará el disco físico, que seguirá estando disponible sin cambios para otros intentos. Y como ahora sabemos que el PT es correcto, podemos usar /dev/sdc1 para la copia y albergar esperanzas que antes no podíamos:
# dd if=/dev/sdc1 of=/tmp/mydisk.img bs=1G count=10
...after copying 10 gigabytes...
# ntfsfix /tmp/mydisk.img
Si NTFSfix no funciona, bueno, estamos en problemas. Sin embargo, hay utilidades más precisas que se pueden probar. Y si necesita recuperar archivos de imágenes JPEG y el sistema de archivos no está fragmentado, puede hacerlo automáticamente buscando los encabezados JPEG. Lo mismo, casi, se aplica a PDF, TIFF y Office documentos, excepto que I no sé cómo reconocerlos (para archivos JPEG, lo haría :-)). Como última opción, encontré a estos tipos: no los conozco, no estoy relacionado con ellos y no aceptaré ninguna culpa. Sin embargo, a medida que avanzan estas cosas, el precio es muy razonable.