I need to recover files off my 16gb Lexar flash drive. The pcb does not appear damaged in any way so I'm hoping recovery can be done. When I plug the usb into a Windows machine, it recognizes it as a drive, but prompts me to insert a disk. After a couple days trying to get this thing working, I decided to give it a shot on Ubuntu.
Running the lsusb
command:
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
The flash drive is recognized as Alcor Micro Corp. So far so good. However, when I run 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
The drive isn't recognized. Finally, I ran 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
Any ideas for recovering the data? Thanks in advance!
Best Answer
Make an image of the offending device with
ddrescue
- You will require enough storage space to hold the entire drive regardless of the amount of data you have (or had) stored on it in this case it appears you'll need 16GB to store a clone of /dev/sdb.ddrescue is the program that will be doing the work and if it's not installed we need to install it with
sudo apt-get install gddrescue
(not a typo, the g is short for GNU)Open a terminal with CtrlAltT and change to the directory that you will be storing the image file in and issue the command
sudo ddrescue -d /dev/sdb sdb.img sdb.logfile
the -d directs direct access to the drive (ignoring caching) /dev/sdb is the device we are using for input sdb.img is the file we are using for output sdb.logfile is keeping track of where we are and what our results are.
If for any reason the process is stopped before completion, the logfile allows picking up where we left off.
imaging will begin and you will see something like this:
Rescued indicates the amount of data successfully read, errsize indicates the size of unreadable data. As the process continues we hope to see the former increase and the latter approach zero. ddrescue uses a process called data carving as I recall in which failed blocks are halved and re-tried.
ddrescue is a very powerful tool and you can learn a great deal about it in the manual. Pay close attention to Chapter 3!! choosing the wrong file or device for output will definitely ruin your day.
After we have the resulting image we can run tests and recovery procedures on it without any further stress to the failing or failed device.
Eventually ddrescue will output "Finished" to the terminal screen. If the errsize is high and you feel like you might want to try to recover a little more you can re-run the command and apply switches to re-try failed blocks and even read in reverse (likely not helpful on a solid state device) by:
sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfile
or any other combination of switches you think might be helpful in the aforementioned manual. Once you've finished attempting to recover all the data, it's time to see what we have.Issue the command
fdisk -l sdb.img
or whatever you named your image. With any luck you'll get output similar to this indicating that the partition table is intact.Note the "Start" number This means the file system starts on sector 2048.
Armed with this information and some basic math skills or a calculator we can arrive at the offset that we need to try our processes on. 2048 sectors X 512 bytes per = 1048576
since we created this image due to failure we will first attempt to repair the filesystem
issue the command
sudo losetup --offset 1048576 /dev/loop2 sdb.img
to setup the image on a loop device.then issue the command
sudo fsck /dev/loop2
After we've repaired the system to the best of our ability we will create a mount point with
sudo mkdir /mnt/loop
and mount the previously setup loop device withsudo mount /dev/loop2 /mnt/loop
Now hopefully we have some data we can copy over to another drive. let's look:
It looks like I have some. Hopefully you do too! after finishing copying my files I unmount the loop device with
sudo umount /dev/loop2
If this approach has been less than successful I can also try testdisk with the command `sudo testdisk sdb.img (or whatever you named your image file). Press enter to select the image, then choose the partition type if a type is detected it will give you a hint on how to proceed. Note that this is usually Intel on flash drives.
You can choose Analyze to search for lost partitions or go directly to Advanced for the file system tools to select an already known or recovered partition. After selection of the partition you will be shown a file listing with instructions on how to select files for copying and etc. This part is fairly self-explanatory and is likely covered elsewhere so I'll stop here with the promise that if anything is unclear you can drop me a comment and I'll get back to you.