Cannot mount USB (ddrescue) disk image

Question

I was trying to recover some data from a faulty USB stick (NTFS) but before i tested on another USB stick. the Virtualbox VM detected the USB stick which was unmounted in order to make a ddrescue image.

I managed to do this once but now it doesn't seem to work anymore as fdisk thinks that there are several partitions when there's only one in the USB stick???

Anyone has any ideas/suggestions?

Steps:

1. Check file system of usb stick to assign the right FS when mounting the img
2. dd the usb stick
3. check img partition properties. This is to mount the partition with the appropriate offset value (starting block).
4. mount img with mount FAILED
5. mount img with kpartx (not familiar with this tool) FAILED

Rosa recover_disk # fdisk -l /dev/sdb

Disk /dev/sdb: 1014 MB, 1014497280 bytes 17 heads, 32 sectors/track, 3642 cylinders, total 1981440 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: 0xc3072e18

Device Boot Start End Blocks Id System /dev/sdb1 * 32 1981439 990704 7 HPFS/NTFS/exFAT

Rosa recover_disk # ddrescue /dev/sdb1 dd_resc.img

GNU ddrescue 1.17 Press Ctrl-C to interrupt rescued: 1014 MB, errsize: 0 B, current rate: 704 kB/s ipos: 1014 MB, errors: 0, average rate: 14492 kB/s opos: 1014 MB, time since last successful read: 0 s Finished

Rosa recover_disk # fdisk -l dd_resc.img

Disk dd_resc.img: 1014 MB, 1014480896 bytes 255 heads, 63 sectors/track, 123 cylinders, total 1981408 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: 0x4d544f4f

This doesn't look like a partition table Probably you selected the wrong device.

 Device Boot      Start         End      Blocks   Id  System

dd_resc.img1 ? 218137203 2138359164 960110981 70 DiskSecure Multi-Boot dd_resc.img2 ? 544370800 2464669663 960149432 74 Unknown dd_resc.img3 ? 225600882 769746299 272072709 82 Linux swap / Solaris dd_resc.img4 ? 2760638474 2760690110 25818+ 61 SpeedStor

Partition table entries are not in disk order

Rosa recover_disk # mkdir /media/ddmount Rosa recover_disk # echo $(( 32*512 ))

16384

Rosa recover_disk # mount dd_resc.img /media/ddmount -o loop,offset=16384 -t ntfs

NTFS signature is missing. Failed to mount '/dev/loop0': Invalid argument The device '/dev/loop0' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Rosa recover_disk # kpartx -a -v dd_resc.img

device-mapper: resume ioctl on loop0p1 failed: Invalid argument create/reload failed on loop0p1 add map loop0p1 (0:0): 0 1920221962 linear /dev/loop0 218137203 device-mapper: resume ioctl on loop0p2 failed: Invalid argument create/reload failed on loop0p2 add map loop0p2 (0:0): 0 1920298864 linear /dev/loop0 544370800 device-mapper: resume ioctl on loop0p3 failed: Invalid argument create/reload failed on loop0p3 add map loop0p3 (0:0): 0 544145418 linear /dev/loop0 225600882 device-mapper: resume ioctl on loop0p4 failed: Invalid argument create/reload failed on loop0p4 add map loop0p4 (0:0): 0 51637 linear /dev/loop0 2760638474

---- 2017-03-01 UPDATE -------

The mystery remains but i manage to mount with no offset options which is a relief but not satisfying as i don't understand why which will be helpful for future reference.

Answer 1

It seems you have cloned the partition /dev/sdb1 rather than the whole drive /dev/sdb.

ddrescue is a very powerful tool to rescue what it possible to read (also difficult to read due to failing hardware). But it is dangerous (like standard dd), because it does what you tell it to do without questions.

So it is important to double-check and triple-check that you understand what you are doing, and that there is no typing error. Otherwise you might overwrite the family pictures or some other important data in another drive, which 'should not be involved' in the cloning and recovery processes.

• That said, it is a good idea to start by cloning the damaged drive and to do the recovery attempts on a cloned copy. And ddrescue is a good cloning tool.

• It is more straight-forward to clone from the damaged drive (source) to another drive of at least the same size (target) compared to what you tried (to work with an image file).

Text after the character # is a comment (not used).

sudo ddrescue source-drive target-drive log-file  # generic command line
sudo ddrescue /dev/sdx /dev/sdy sdx2sdy.log       # example

where x and y are drive letters, for example b and c. It is very important to get these drive letter correct (and in the right order). Otherwise you can detroy important data.

---

You can get help to identify the drives with the following commands

df
sudo lsblk -f
sudo lsblk -m
sudo parted -ls

The info page

info ddrescue

contains a very good tutorial. Please read it carefully before you use ddrescue again.

---

If only the file systems are damaged (not the memory cells or internal data management in the USB drive), you can use mkusb to clone the drive. It is installed from a PPA, and will help you identify the target drive, which will reduce the risk. mkusb version 12 alias dus can be used like this,

dus /dev/sdx   # where x is the drive letter of the source (for example b)

---

Finally, see the following link for more tips about repairing a USB drive or recovering data from it,

Repair the partition table and file system of a pendrive