Necesito recuperar archivos de mi unidad flash Lexar de 16 GB. La PCB no parece dañada de ninguna manera, así que espero que se pueda recuperar. Cuando conecto el USB a una máquina con Windows, lo reconoce como una unidad, pero me solicita que inserte un disco. Después de un par de días intentando que esto funcionara, decidí intentarlo en Ubuntu.
Ejecutando el lsusbcomando:
Bus 002 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 8086:0186 Intel Corp. WiMAX Connection 2400m
Bus 001 Device 003: ID 0bda:5801 Realtek Semiconductor Corp.
Bus 001 Device 007: ID 058f:1234 Alcor Micro Corp. Flash Drive
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
La unidad flash se reconoce como Alcor Micro Corp. Hasta ahora todo bien. Sin embargo, cuando ejecuto sudo fdisk -l:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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: 0xb43778ae
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 3074047 1536000 27 Hidden NTFS WinRE
/dev/sda2 3074048 921657343 459291648 7 HPFS/NTFS/exFAT
/dev/sda3 954587136 976773119 11092992 17 Hidden HPFS/NTFS
/dev/sda4 921659390 954587135 16463873 5 Extended
/dev/sda5 921659392 954587135 16463872 83 Linux
Partition table entries are not in disk order
La unidad no se reconoce. Finalmente, corrí tail -f:
==> /var/log/syslog <==
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.398762] usb 1-1.2: new high-speed USB device number 9 using ehci-pci
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644599] usb 1-1.2: New USB device found, idVendor=058f, idProduct=1234
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644610] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644616] usb 1-1.2: Product: Mass Storage Device
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644621] usb 1-1.2: Manufacturer: Alcor Micro
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645100] usb-storage 1-1.2:1.0: USB Mass Storage device detected
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645183] scsi13 : usb-storage 1-1.2:1.0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.642812] scsi 13:0:0:0: Direct-Access Generic USB Flash Disk 7.76 PQ: 0 ANSI: 4
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.643071] sd 13:0:0:0: Attached scsi generic sg2 type 0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.647022] sd 13:0:0:0: [sdb] Attached SCSI removable disk
¿Alguna idea para recuperar los datos? ¡Gracias de antemano!
Respuesta1
Haga una imagen del dispositivo infractor con ddrescue: necesitará suficiente espacio de almacenamiento para contener todo el disco, independientemente de la cantidad de datos que tenga (o haya tenido) almacenados en él; en este caso, parece que necesitará 16 GB para almacenar un clon de /dev/sdb.
ddrescue es el programa que hará el trabajo y, si no está instalado, debemos instalarlo sudo apt-get install gddrescue(no es un error tipográfico, la g es la abreviatura de GNU)
Abra una terminal CtrlAltTy cambie al directorio en el que almacenará el archivo de imagen y emita el comandosudo ddrescue -d /dev/sdb sdb.img sdb.logfile
el -d dirige el acceso directo a la unidad (ignorando el almacenamiento en caché) /dev/sdb es el dispositivo que estamos usando para la entrada sdb.img es el archivo que estamos usando para la salida sdb.logfile realiza un seguimiento de dónde estamos y cuáles son nuestros resultados son.
Si por algún motivo el proceso se detiene antes de completarse, el archivo de registro permite continuar donde lo dejamos.
Comenzarán las imágenes y verá algo como esto:
Rescatado indica la cantidad de datos leídos correctamente, errsize indica el tamaño de los datos ilegibles. A medida que el proceso continúa, esperamos ver que los primeros aumenten y los segundos se acerquen a cero. ddrescue utiliza un proceso llamado tallado de datos, según recuerdo, en el que los bloques fallidos se dividen a la mitad y se vuelven a intentar.
ddrescue es una herramienta muy poderosa y puedes aprender mucho sobre ella en elmanual. ¡¡Presta mucha atención al Capítulo 3!!Elegir el archivo o dispositivo incorrecto para la salida definitivamente arruinará tu día.
Una vez que tengamos la imagen resultante, podemos ejecutar pruebas y procedimientos de recuperación en ella sin causar más estrés al dispositivo defectuoso o defectuoso.
Eventualmente, ddrescue mostrará "Finalizado" en la pantalla del terminal. Si el tamaño del error es alto y cree que es posible que desee intentar recuperarse un poco más, puede volver a ejecutar el comando y aplicar interruptores para volver a intentar los bloques fallidos e incluso leer al revés (probablemente no sea útil en un dispositivo de estado sólido). por: sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfileo cualquier otra combinación de interruptores que crea que podría ser útil en el manual antes mencionado. Una vez que hayas terminado de intentar recuperar todos los datos, es hora de ver qué tenemos.
Emita el comando fdisk -l sdb.imgo el nombre que le haya dado a su imagen. Con un poco de suerte, obtendrás un resultado similar a este que indica que la tabla de particiones está intacta.
Disk sdb.img: 4013 MB, 4013948928 bytes
1 heads, 24 sectors/track, 326656 cylinders, total 7839744 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: 0x000174fe
Device Boot Start End Blocks Id System
sdb.img1 * 2048 7839743 3918848 b W95 FAT32
Tenga en cuenta el número de "Inicio". Esto significa que el sistema de archivos comienza en el sector 2048.
Armados con esta información y algunas habilidades matemáticas básicas o una calculadora, podemos llegar a la compensación que necesitamos para probar nuestros procesos. 2048 sectores X 512 bytes por = 1048576
Dado que creamos esta imagen debido a una falla, primero intentaremos reparar el sistema de archivos.
emita el comando sudo losetup --offset 1048576 /dev/loop2 sdb.imgpara configurar la imagen en un dispositivo de bucle.
luego emite el comandosudo fsck /dev/loop2
Después de haber reparado el sistema lo mejor que podamos, crearemos un punto de montaje sudo mkdir /mnt/loopy montaremos el dispositivo de bucle previamente configurado consudo mount /dev/loop2 /mnt/loop
Ahora, con suerte, tenemos algunos datos que podemos copiar a otra unidad. miremos:
ls /mnt/loop
autorun.inf casper-rw ldlinux.sys pool smart-fail.txt
boot dists md5sum.txt preseed syslinux
casper install pics README.diskdefines wubi.exe
Parece que tengo algunos. ¡Ojalá tú también lo hagas! Después de terminar de copiar mis archivos, desmonto el dispositivo de bucle consudo umount /dev/loop2
Si este enfoque no ha tenido éxito, también puedo probar testdisk con el comando `sudo testdisk sdb.img (o como le hayas puesto el nombre a tu archivo de imagen). Presione Intro para seleccionar la imagen, luego elija el tipo de partición. Si se detecta un tipo, le dará una pista sobre cómo proceder. Tenga en cuenta que suele ser Intel en unidades flash.
Puede elegir Analizar para buscar particiones perdidas o ir directamente a Avanzado para que las herramientas del sistema de archivos seleccionen una partición ya conocida o recuperada. Después de seleccionar la partición, se le mostrará una lista de archivos con instrucciones sobre cómo seleccionar archivos para copiar, etc. Esta parte se explica por sí misma y probablemente esté cubierta en otra parte, así que me detendré aquí con la promesa de que si algo no está claro puedes dejarme un comentario y me comunicaré contigo.