Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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!

share|improve this question
2  
+1 for providing lots of detailed relevant information presented in a clear, easy to read manner. –  Scott Severance Oct 1 '12 at 7:30
add comment

4 Answers 4

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
add comment

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:

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.