Recover Flash Drive Files

Question

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!

Answer 1

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.

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

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 with sudo mount /dev/loop2 /mnt/loop

Now hopefully we have some data we can copy over to another drive. let's look:

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

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.