Mounting ddrescue image after recovery (in over my head)

Question

I'm having problems mounting the recovery image. I've tried to mount the image multiple ways.

quark@DS9 ~ $ sudo mount -t ext4 /media/jump1/1recover/sdb1.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so


quark@DS9 ~ $ sudo mount -r -o loop /media/jump1/1recover/sdb1.img recover
mount: you must specify the filesystem type

quark@DS9 ~ $ sudo mount /media/jump1/1recover/sdb1.img mnt
mount: you must specify the filesystem type

It doesn't even give me detailed information on the file I just made, nautilus says it's 160gb.

quark@DS9 ~ $ file /media/jump1/1recover/sdb1.img
/media/jump1/1recover/sdb1.img: data


quark@DS9 ~ $ mmls /media/jump1/1recover/sdb1.img
        Cannot determine partition type

I'm not sure what I'm doing wrong or if I started this process incorrectly from the beginning. I've outlined what I've done so far below. I'm clueless, I'd appreciate if someone had some input for me.

What I have done from the beginning

My laptop has two hard drives.

One has the dual boot Win7 / Linux Mint system files. Secondary one contained my /home folder.

The laptop was jarred and the /home disk was broken. I tried a LiveCD recovery, it failed. Wouldn't even load a Live session with the disk installed. So I turned to ddrescue.

quark@DS9 ~ $ sudo fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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: 0x0009fc18

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048   112642047    56320000    7  HPFS/NTFS/exFAT
/dev/sda2       138033152   312580095    87273472   83  Linux
/dev/sda3       112644094   138033151    12694529    5  Extended
/dev/sda5       112644096   132173823     9764864   83  Linux
/dev/sda6       132175872   138033151     2928640   82  Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 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: 0x0002a8ea

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *          63   312576704   156288321   83  Linux

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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: 0xed6d054b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              63  1953520064   976760001    7  HPFS/NTFS/exFAT

sda - 160g internal, holds all system files and all computer functions.
sdb - 160g internal, BROKEN, contains about 140g of data I'd like to recover.
sdc - 1T external, contains recovery image. Only place that has space to do all this.

From this site, https://apps.education.ucsb.edu/wiki/Ddrescue

I used this script to create an image of the broken hard drive. I changed the destination to the external USB drive.

#!/bin/sh 

prt=sdb1
src=/dev/$prt
dst=/media/jump1/1recover/$prt.img
log=$dst.log

sudo time ddrescue --no-split $src $dst $log
sudo time ddrescue --direct --max-retries=3 $src $dst $log
sudo time ddrescue --direct --retrim --max-retries=3 $src $dst $log

Everything looked like it came off without a hitch:

quark@DS9 ~ $ sudo bash recover1 


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:   160039 MB,  errsize:    4096 B,  current rate:    35588 B/s
   ipos:      3584 B,   errors:       1,    average rate:   22859 kB/s
   opos:      3584 B,     time from last successful read:       0 s
Finished                   
12.78user 1060.42system 1:56:41elapsed 15%CPU (0avgtext+0avgdata 4944maxresident)k
312580958inputs+0outputs (1major+601minor)pagefaults 0swaps


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   160039 MB,  errsize:    4096 B,  errors:       1
Current status
rescued:   160039 MB,  errsize:    1024 B,  current rate:        0 B/s
   ipos:      1536 B,   errors:       1,    average rate:       13 B/s
   opos:      1536 B,     time from last successful read:     1.3 m
Finished                       
0.00user 0.00system 3:43.95elapsed 0%CPU (0avgtext+0avgdata 4944maxresident)k
238inputs+0outputs (3major+374minor)pagefaults 0swaps


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   160039 MB,  errsize:    1024 B,  errors:       1
Current status
rescued:   160039 MB,  errsize:    1024 B,  current rate:        0 B/s
   ipos:      1536 B,   errors:       1,    average rate:        0 B/s
   opos:      1536 B,     time from last successful read:     3.7 m
Finished                       
0.00user 0.00system 3:43.56elapsed 0%CPU (0avgtext+0avgdata 4944maxresident)k
8inputs+0outputs (0major+376minor)pagefaults 0swaps

It looks like, from where I'm standing it worked perfectly. Here's the log:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue --direct --retrim --max-retries=3 /dev/sdb1 /media/jump1/1recover/sdb1.img /media/jump1/1recover/sdb1.img.log
# current_pos  current_status
0x00000600     +
#      pos        size  status
0x00000000  0x00000400  +
0x00000400  0x00000400  -
0x00000800  0x254314FC00  +

I'm not sure how to proceed. Does this mean all of my data is lost????????

Appreciate ANY input!

+1 for providing lots of detailed relevant information presented in a clear, easy to read manner. — Scott Severance, Oct 01 '12 at 07:30
The Ubuntu wiki has a very good page on data recovery: https://help.ubuntu.com/community/DataRecovery — Wilf, May 29 '16 at 06:56

score 10 · Answer 1 · answered Oct 01 '12 at 21:11

I found the solution, and feel kind of foolish for missing this. Thank you guys so much for your responses!

I checked the image for errors and then it mounted with no problem!

sudo fsck -y /dev/sda2/backup.img

It fixed the errrors then it mounted no problem with:

sudo mount /dev/sda2/backup.img /mnt/recoverydata

score 5 · Answer 2 · edited Apr 13 '17 at 12:24

5

The image you created will contain all the faults your original disk has. Therefore you likely can't mount or read it. The way to proceed is to load this image into your favourite data recovery tool.

We have good experience with Testdisk/PhotoRec but there are other tools worth mentioning, e.g. Foremost.

See also:

edited Apr 13 '17 at 12:24

Community

1

answered Oct 01 '12 at 07:17

Takkat

142,284

score 5 · Answer 3 · answered Oct 21 '13 at 19:13

Here's what I had to do in a similar situation - in case someone stumbles upon this question like I did.

My image also wouldn't mount, generating the same error (bad superblock). However, fsck also failed with the following error:

fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /mnt/download/rescue.img

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

After reading through DataRecovery (link provided by Takkat, thanks!), I tried the following and it worked:

apt-get install sleuthkit
mmls /path/to/image

This produced the following output:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000062   0000000063   Unallocated
02:  00:00   0000000063   2930272064   2930272002   Linux (0x83)
03:  -----   2930272065   2930277167   0000005103   Unallocated

I then multiplied 63 by 512 to get 32256 and mounted the image like this:

mount -o loop,offset=32256 /path/to/image /mnt/temp

I hope this helps someone else too.

score 2 · Answer 4 · answered Oct 01 '12 at 07:42

In addition to Takkat's answer, I'd like to suggest another possible approach. Considering that your image is almost certainly damaged, there may be some data that data recovery tools can't adequately recover.

SpinRite addresses this problem in a different way. Rather than operating off an image, it exercises the disk in order to get more data off it than normal tools can recover. I've used it to significantly increase the amount of recoverable data. If you're lucky, you'll be able to mount your disk normally afterward for long enough to make a proper backup.

SpinRite does come with a major disadvantage, though. It costs a fair amount of money. If the other tools work for you, than save your money. But if you need more, SpinRite is definitely worth a try.

I wrote this answer years ago and haven't had to restore lost data in even longer. I no longer remember whether I've tried ddrescue. These days, I depend on backup and regard disks as expendable. — Scott Severance, Mar 10 '20 at 16:36

Mounting ddrescue image after recovery (in over my head)

What I have done from the beginning

4 Answers4

Linked