A friend asked me for help. He has a USB thumbdrive that he used for backup and when he plugged it into his Windows system, Windows wanted to re-format the drive (and therefore erase his backups). Obviously a sub-optimal solution, so he asked me for help.
At least these were backups. Once, in the 1980’s, I was asked to recover someone’s PhD thesis from a floppy. They knew disks weren’t reliable, so they stored their thesis on a floppy – one well-used 5 1/4″ floppy – re-writing it over and over – without ever saving it to the “unreliable” hard disk. And in case you are wondering, the victim wasn’t trying for a PhD in science. I will refrain from commenting on the other majors.
It’s the first time I’ve tried this. I first tried booting up a DVD with a fresh copy of the SystemRescue CD. I first tried to mount the thumb drive using Linux commands.
I plugged-in in the USB drive and used dmesg to see any errors. It reported
[64351.134159] print_req_error: critical medium error, dev sdb, sector 8606965
[64351.158797] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[64351.158807] sd 6:0:0:0: [sdb] tag#0 Sense Key : Medium Error [current]
[64351.158812] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Unrecovered read error
[64351.158819] sd 6:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 83 54 f6 00 00 01 00
[64351.158824] print_req_error: critical medium error, dev sdb, sector 8606966
This identified the disk as sdb. I tried using fsck
fsck -t vfat /dev/sdb1
fsck from util-linux 2.31.1
fsck.fat 4.1 (2017-01-24)
Read 512 bytes at 0:Input/output error
No luck, I was getting an error. I then looked at the documentation, and it seemed ddrescue was the best way to go.
I typed
ddrescue /dev/sdb1 disk.img
I then checked the output file with the file command, and it hinted I did this wrong:
file disk.img
disk.img: data
This wasn’t a good sign. I was unable to mount this file system.
I figured the idiot’s approach to data recover wasn’t optimum, so I decided to do some more research on the Internet – like reading the instructions and following guides.
Well, the guides weren’t too helpful. They mostly covered hard drives. I also read that there was a documentation problem with ddrescue and the term logfile. Turns out logfile is a misnomer. The latest version refers it as a mapfile. A mapfile lets you restart an old unfinished session. You can therefore try several times to recover files. A logfile is usually a debug aid to track down errors in execution, So I decided to download the most recent version of ddrescue. I looked on github and found this repository. It compiled with no problems on my Ubuntu machine.
I tried again, and this is the result:
ddrescue -d -r3 /dev/sdb hdimage mapfile GNU ddrescue 1.25-rc1 Press Ctrl-C to interrupt Initial status (read from mapfile) rescued: 51997 kB, tried: 431616 B, bad-sector: 431616 B, bad areas: 743 Current status ipos: 15702 MB, non-trimmed: 0 B, current rate: 1536 B/s opos: 15702 MB, non-scraped: 0 B, average rate: 295 kB/s non-tried: 0 B, bad-sector: 190344 kB, error rate: 18944 B/s rescued: 15818 MB, bad areas: 92292, run time: 14h 48m 58s pct rescued: 98.81%, read errors: 1770736, remaining time: 20h 48m time since last successful read: n/a Finished
Notice it took 14 hours to run. Did it work? I tried the file command on hdimage:
file hdimage hdimage: DOS/MBR boot sector; partition 1 : ID=0xc, start-CHS (0x0,0,33), end-CHS (0x3ff,254,63), startsector 32, 31266784 sectors, extended partition table (last)
Much better. So I tried to mount the device. I made some mistakes, as you shall see.
I wanted to use the losetup command tto create a loopback file system, which allows me to use a file as a file system. I typed “ls /dev/loop*” to find an unused filename. (I could also use “losetup -l”). /dev/loop25 wasn’t used, so I typed the following.
% sudo # losetup /dev/loop25 hdimage # mkdir /tmp/mnt # mount /dev/loop25 /tmp/mnt mount: /tmp/mnt: wrong fs type, bad option, bad superblock on /dev/loop25, missing codepage or helper program, or other error. ## oops. I'm doing something wrong. Let's try fdisk # fdisk /dev/loop25 Welcome to fdisk (util-linux 2.31.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/loop25: 14.9 GiB, 16008609792 bytes, 31266816 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 Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/loop25p1 32 31266815 31266784 14.9G c W95 FAT32 (LBA) Command (m for help): q
Aha! Obviously, I tried to mount the boot partition as a filesystem, and fdisk complained. This link helped me out. losetup has an option to skip over the book block. Fdisk provided me with two pieces of information – the size of a sector (512 bytes) and the start of the FAT32 partition (32). 32*512 is 16384, so I first removed the old loopback device:
losetup -d /dev/loop25
and then I re-created it:
# losetup /dev/loop25 hdimage -o 16384 # mount /dev/loop25 /tmp/mnt
Success! I asked my friend to get a new thumbdrive, and I will copy the files over. I could either copy the files using a drag and drop, or try to reproduce the entire drive using ddrescue. dd, or some other disk cloning software..
I own a copy of Steve Gibson’s SpinRight, and I could have used this commercial program instead of ddrescue. Why did I use ddrescue?
Some people think SpinRite is only for hard drives. This isn’t quite accurate. SpinRite has multiple modes of operations. Level 2 is read-only, and level 4 does a full read/write test of the disk. Level 4 would be a terrible choice because the drive is failing, and there is a danger of causing the drive to die . The read-only option could work. But according to some of the comments Steve Gibson has made, I believe it could modify files during level 2.
But I have another concern. When I recover files from a failing drive, I never want to write to it. Instead, I want to do a read–only recovery. Some of the articles I read state that SpinRite can fill blocks with corrupted data. While I am not a forensics expert, I appreciale the approach that I never try to modify the data on a failing disk drive. If all else fails, I can still use SpinRite, or any other recovery program.