[solved] How to recoved data off a masacred filesystem

Lockheed · 2013-11-30 14:25:40

I'm in trouble. I am trying to recover my main data partition. Here's how it happened:

sdb1 - 680gb primary partition, ext4, around 300gb of data on it
sdb2 - 60gb primary partition, ext4, for backing up system from sda1 with rsync

Yesterday, while doing rsync backup on sdb2, I run gparted, which indicated that it cannot read partition table on sdb and displayed the whole of it as unallocated. I know that when I run gparted 30 earlier, the partition was still vissible.
Nevertheless, I thought that's because of rsync and I thought reboot would fix that, because sdb1 was still mounted, and I was accessing all the data on it with no issues.

When rsync was done, I rebooted an that was the last time I saw my data.

Automounting during boot gives me:

superblock could not be read or does not describe correct ext2 filesystem...

So I tried to run

$ sudo fsck.ext4 -p -b 98304 -B 4096 /dev/sdb
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb
/dev/sdb: 
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>

$ sudo e2fsck -b 8193 /dev/sdb
[sudo] password for juha: 
e2fsck 1.42.8 (20-Jun-2013)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

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>

I tried the same command with all superblock backups that were listed.

$ sudo fsck -n /dev/sdb1
fsck from util-linux 2.24
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while using the backup blocksfsck.ext4: going back to original superblock
Superblock has an invalid journal (inode 8).
Clear? no

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sdb1

/dev/sdb1: ********** WARNING: Filesystem still has errors **********

I also run testdisk to see if it can find data from sdb1.
It finds the partition (partition type is automatically selected as None) but it finds no files on sdb1, even after deep search.
It does find data on sdb2, but that's just system partition backup I don't care about at this point.

Also, just now I run this

]$ sudo fsck.ext4 -v /dev/sdb1
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while using the backup blocksfsck.ext4: going back to original superblock
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***

Note: if several inode or block bitmap blocks or part
of the inode table require relocation, you may wish to try
running e2fsck with the '-b 32768' option first.  The problem
may lie only with the primary block group descriptors, and
the backup block group descriptors may be OK.

Block bitmap for group 256 is not in group.  (block 1268396107)
Relocate<y>? yes
Inode bitmap for group 256 is not in group.  (block 1125246092)
Relocate<y>? yes
Inode table for group 256 is not in group.  (block 2088878841)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
One or more block group descriptor checksums are invalid.  Fix<y>? yes
Group descriptor 256 checksum is 0x6349, should be 0x9abd.  FIXED.
Inode bitmap for group 257 is not in group.  (block 2837529440)
Relocate<y>? yes
Inode table for group 257 is not in group.  (block 2199953455)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 257 checksum is 0x02d4, should be 0xd13d.  FIXED.
Block bitmap for group 258 is not in group.  (block 3896597355)
Relocate<y>? yes
Inode bitmap for group 258 is not in group.  (block 2097244160)
Relocate<y>? yes
Inode table for group 258 is not in group.  (block 2609271215)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 258 checksum is 0xee91, should be 0xc246.  FIXED.
Block bitmap for group 259 is not in group.  (block 805546298)
Relocate<y>? yes
Inode bitmap for group 259 is not in group.  (block 3538423854)
Relocate<y>? yes
Inode table for group 259 is not in group.  (block 2924444292)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 259 checksum is 0xc190, should be 0x4c0d.  FIXED.
Block bitmap for group 260 is not in group.  (block 338739984)
Relocate<y>? yes
Inode bitmap for group 260 is not in group.  (block 902864749)
Relocate<y>? yes
Inode table for group 260 is not in group.  (block 1901539298)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 260 checksum is 0xac76, should be 0xac63.  FIXED.
Block bitmap for group 261 is not in group.  (block 1660969779)
Relocate<y>? yes
Inode bitmap for group 261 is not in group.  (block 209743725)
Relocate<y>? yes
Inode table for group 261 is not in group.  (block 879935846)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 261 checksum is 0x800e, should be 0x8fa5.  FIXED.
Block bitmap for group 262 is not in group.  (block 1705519300)
Relocate<y>? yes
Inode bitmap for group 262 is not in group.  (block 1360743755)
Relocate<y>? yes
Inode table for group 262 is not in group.  (block 4107065764)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 262 checksum is 0xc00d, should be 0xe8f3.  FIXED.
Inode bitmap for group 263 is not in group.  (block 2205583287)
Relocate<y>? yes
Inode table for group 263 is not in group.  (block 3636737468)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? yes
Group descriptor 263 checksum is 0x69a9, should be 0xb9a9.  FIXED.
Block bitmap for group 264 is not in group.  (block 1471470759)
Relocate<y>? yes
Inode bitmap for group 264 is not in group.  (block 1725839977)
Relocate<y>? yes
Inode table for group 264 is not in group.  (block 2144458553)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 264 checksum is 0xcd09, should be 0xea3a.  FIXED.
Block bitmap for group 265 is not in group.  (block 3617231787)
Relocate<y>? yes
Inode bitmap for group 265 is not in group.  (block 2640198439)
Relocate<y>? yes
Inode table for group 265 is not in group.  (block 2725347176)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 265 checksum is 0xbbb8, should be 0xb870.  FIXED.
Block bitmap for group 266 is not in group.  (block 1840499818)
Relocate<y>? yes
Inode bitmap for group 266 is not in group.  (block 3698703324)
Relocate<y>? yes
Inode table for group 266 is not in group.  (block 2882301371)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 266 checksum is 0xb3c9, should be 0x72d5.  FIXED.
Block bitmap for group 267 is not in group.  (block 1968099309)
Relocate<y>? yes
Inode bitmap for group 267 is not in group.  (block 2125019324)
Relocate<y>? yes
Inode table for group 267 is not in group.  (block 2616321653)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 267 checksum is 0x72bb, should be 0xc66c.  FIXED.
Block bitmap for group 268 is not in group.  (block 3197564106)
Relocate<y>? yes
Inode bitmap for group 268 is not in group.  (block 1173679527)
Relocate<y>? yes
Inode table for group 268 is not in group.  (block 3081059840)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 268 checksum is 0xee4e, should be 0x6c67.  FIXED.
Block bitmap for group 269 is not in group.  (block 467880860)
Relocate<y>? yes
Inode bitmap for group 269 is not in group.  (block 3461842583)
Relocate<y>? yes
Inode table for group 269 is not in group.  (block 903401461)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 269 checksum is 0x701d, should be 0x1735.  FIXED.
Block bitmap for group 270 is not in group.  (block 1737084563)
Relocate<y>? yes
Inode bitmap for group 270 is not in group.  (block 1617385180)
Relocate<y>? yes
Inode table for group 270 is not in group.  (block 3944519733)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 270 checksum is 0x1c78, should be 0x9f4e.  FIXED.
Block bitmap for group 271 is not in group.  (block 3558332121)
Relocate<y>? yes
Inode bitmap for group 271 is not in group.  (block 1481837154)
Relocate<y>? yes
Inode table for group 271 is not in group.  (block 1108213120)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 271 checksum is 0x3066, should be 0xce01.  FIXED.
Block bitmap for group 272 is not in group.  (block 3294840462)
Relocate<y>? yes
Inode bitmap for group 272 is not in group.  (block 1680662834)
Relocate<y>? yes
Inode table for group 272 is not in group.  (block 747037043)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? no
Group descriptor 272 checksum is 0x7d96, should be 0xde7a.  FIXED.
Block bitmap for group 273 is not in group.  (block 805709209)
Relocate<y>? cancelled!
Inode bitmap for group 273 is not in group.  (block 220354588)
Relocate<y>? cancelled!
Inode table for group 273 is not in group.  (block 281430039)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? cancelled!
Group descriptor 273 checksum is 0xa378, should be 0x6f41.  FIXED.

/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sdb1: ********** WARNING: Filesystem still has errors **********

But as you can see, I chickened out on "SEVERE DATA LOSS POSSIBLE" warnings, and after few repeats, I just hit ctrl+c not sure if I should even touch that.

What should I do here?

Last edited by Lockheed (2013-12-19 17:27:12)

Spider.007 · 2013-11-30 14:38:31

Why oh why did you run e2fsck on the entire disk initially (there can never be a filesystem there)? Also, are you sure the partition-table is now correct? What is the output from `sudo parted /dev/sdb p`? If you care about this data; you should make a backup on an external medium (of the entire contents of /dev/sdb) before modifying anything.

Try `dumpe2fs /dev/sdb1 | grep superblock` to find alternative superblock locations; try `mount sb=xxx /dev/sdb1 /mnt` to use those alternative superblocks directly and see if any data can be found

Lockheed · 2013-11-30 14:42:59

I run e2fsck on sdb1, too. I wasn't sure which one was the right way, and tutorials I found only mentioned ambiguous /dev/xxx

I assume that disk backup would take entire 650gb. I simply have no external disk big enough to accommodate it. I only have a 320gb and another one of 160gb

$ sudo parted /dev/sdb p
[sudo] password for juha: 
Model: ATA Hitachi HTS54757 (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type     File system  Flags
 1      1049kB  684GB  684GB   primary  ext4         boot
 2      684GB   750GB  66.0GB  primary  ext4

Spider.007 · 2013-11-30 14:50:09

Yes a backup would require the same diskspace. But with only 300 Gb of data it should also fit on a 320 disk if you use `dd if=/dev/sdb1 bs=10M|bzip2>backup.img`. Obviously you need to be sure the partition is correct but it seems pretty good looking at the parted output (as it matches the sizes in your opening-post)

Lockheed · 2013-11-30 15:06:12

Well, when I went into test disk and it found those partitions, I chose to write them into MBR, although I'm not sure if it changed anything.

Spider.007 · 2013-11-30 15:13:23

So did you try the dumpe2fs I suggested?

Lockheed · 2013-11-30 15:24:13

Yes, sorry. I missed that:

$ sudo dumpe2fs /dev/sdb1 | grep superblock
dumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: Invalid argument while reading journal super block

I already tried that before, but didn't mention in my first post because of this error.

Last edited by Lockheed (2013-11-30 15:24:28)

Lockheed · 2013-11-30 15:38:33

I should add that once I wrote the partition table in testdisk, gparted sees the partitions on sdb, but it sees sdb1 as empty, and with an exclamation.

Lockheed · 2013-12-01 17:24:43

dd if=/dev/sdb1 bs=10M|bzip2>backup.img has been running since 24 hours and so far the image file has 220GB. I hope it will complete before it gets to 300GB.

Do you have any suggestions related to the dumpe2fs error I posted above?

Lockheed · 2013-12-02 09:51:41

I tried mounting the partition, first as the compressed image, later the the disk itself. I got the same error:

# sudo mount /dev/loop1 -t ext4 -o ro,offset=32256  /home/juha/diskimage/
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.

Not sure if you meant /dev/sdb or /dev/sdb1, so I tried both.

$ sudo mount -t ext4 -o ro,offset=32256 /dev/sdb /mnt/Disk_D
mount: wrong fs type, bad option, bad superblock on /dev/loop0,1 /home/juha/diski
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

$ dmesg | tail
[  873.975814] loop: module loaded
[  902.247136] CE: hpet increased min_delta_ns to 20113 nsec
[ 1090.928745] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
[ 1224.940931] EXT4-fs (loop0): VFS: Can't find ext4 filesystem
[  477.255509] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem

Also, here is some output from testdisk while doing deepsearch on partition:

  Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63

     Partition                  Start        End    Size in sectors

   P ext4                     0  32 33 83175 145 42 1336213504
   P ext4                 83175 145 43 91201  52 51  128931840

Write isn't available because the partition table type "None" has been selected.

ext4                     0  32 33 83175 145 42 1336213504
  ext4                     0  32 31 83175 145 40 1336213504
  ext4                     0  32 33 83175 145 42 1336213504
Warning: number of heads/cylinder mismatches 64 (FAT) != 255 (HD)
Warning: number of sectors per track mismatches 32 (FAT) != 63 (HD)
  FAT12                   20  89  2    20 206 12       7382 [GParted-EFI]
  ext4                     0  32 31 83175 145 40 1336213504
  ext4                     0  32 33 83175 145 42 1336213504
  ext4                     0  32 31 83175 145 40 1336213504
  ext4                     0  32 33 83175 145 42 1336213504
  ext4                     0  32 31 83175 145 40 1336213504
  ext4                     0  32 33 83175 145 42 1336213504
  ext4                     0  32 31 83175 145 40 1336213504
  ext4                     0  32 33 83175 145 42 1336213504

I also run photorec just to have a look, and it seems to be finding all the files, but of course photorec recovery is a massive mess so I would only like to use it as a last resort.

Lockheed · 2013-12-03 09:04:07

Finally, I bit the bullet and I run

fsck -b 32768 /dev/sdb1 -y -C0

After 2 hours of fixing inodes and other things, it was done. It ended up saying that partition still contain errors, but I was able to mount it no normal way.

Data size went from 330GB to 190GB and all of it was in lost+found, out of which I copied off the disk ~80GB. The rest was a numerical mess.

So I now gonna restore the image backup back on the disk and go back to square one trying to retrieve at least part of the rest.

I look forward to your advices.

Spider.007 · 2013-12-04 14:54:27

I'm sorry but don't think I can help you any further due to my limited ext-recovery experience. I'd try the other alternative superblock locations to see if better files come from it

mr.MikyMaus · 2013-12-04 22:10:33

I can't help but wonder - why would you backup your system and not the data? Isn't it supposed to be the other way around?

Lockheed · 2013-12-04 22:21:01

I did backup some of the data, but there was too much of it to backup on online storage. Plus, I realised that when I was backup up one very important folder from the Data partition, apparently it did not register and is not present on my online backup service. Which means recovering data is even more crucial now, than before.

The drive seems fine, but my attempts to work on it rendered the rest of the data useless. So I am now uncompressing the bzip2 dd img I made earlier - as Spider.007 suggested - onto that drive and I will work on that image now.

Any advices welcome. I just wonder if doing dd if=/dev/sdb1 instead of dd if=/dev/sdb didn't screw thing up for me, because the Arch recovery wiki speaks only of mounting the image as disk, and then from that disk mounting a partition.
Not sure how that would work with a partition image.

mr.MikyMaus · 2013-12-04 23:24:45

Lockheed wrote:

I did backup some of the data, but there was too much of it to backup on online storage. Plus, I realised that when I was backup up one very important folder from the Data partition, apparently it did not register and is not present on my online backup service. Which means recovering data is even more crucial now, than before.

don't get me wrong, my point was not that you are not backing up your data (which is obvious, understandable and unfortunate at the same time ) but rather a suprise you take the trouble of backing up the system, which doesn't make much sense (save for /etc, /var and /root).

anyway..

Lockheed wrote:

Any advices welcome. I just wonder if doing dd if=/dev/sdb1 instead of dd if=/dev/sdb didn't screw thing up for me, because the Arch recovery wiki speaks only of mounting the image as disk, and then from that disk mounting a partition.
Not sure how that would work with a partition image.

You can mount an image of a partition directly as loopback. It is in fact much simpler than having an entire drive in the image. I didn't read the wiki, but afaik there is no such thing as "mounting the image as a disk" - it just doesn't make sense. You do not mount the disk, you don't even mount a partition. In fact you mount a filesystem which [usually] resides on a partition. So if there is only one partition in question, dd'ing /dev/sdb1 should be just fine and in fact even simpler. dd'ing the entire sdb would make things a bit more difficult but should have no real effect on the data.

Lockheed · 2013-12-04 23:29:44

Don't get me wrong. I do have /etc and /home backed up, with few more odd files. But my online backup storage is 21 GB only, so I need to be careful. However, once I lost this partition I discovered that I still have 10GB free space on the service which would serve so well to backup most of what I lost here. Damn.

Anyway, about the wiki - it says:

Mount the Entire Disk
To mount a complete diskimage to the next free loopdevice use the losetup command:
# losetup -f -P /path/to/image

and then

Mounting Partitions
In order to be able to mount a partiton of an whole diskimage you need to follow the steps above.
When the whole diskimage is mounted, you can use the normal mount command on the loopdevice:
# mount /dev/loop0p1 /mnt/temp

So it only says how to do that on whole disk image.

mr.MikyMaus · 2013-12-04 23:46:39

Lockheed wrote:

So it only says how to do that on whole disk image.

I see. Though it would be something like that. That's what I would call "the hard way".

Rest assured that if you do

dd if=/dev/sdb1 of=image

(assuming there is a filesystem on that partition)

then you can safely do

mount image /path/to/mount -o loop

without any hassle. If the filesystem is undamaged that is. If it is, you'd have to repair it somehow but you'd have to do that anyway even if you used the losetup method.

Guess I'd check the wiki after all and perhaps make some changes to make it simpler for less experienced users.

-m.

Lockheed · 2013-12-05 06:02:02

Thanks for the pointers.
However, I am unable to mount the image for much the same reason as the disk before:

mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop
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.
$  dmesg | tail
[49989.647394] loop: module loaded
[49989.852022] EXT4-fs (loop0): ext4_check_descriptors: Block bitmap for group 256 not in group (block 1268396107)!
[49989.852026] EXT4-fs (loop0): group descriptors corrupted!

so I tried different superblocks given by testdisk:

  ext4                     0   0  1 83175 113 10 1336213504
superblock 0, blocksize=4096 []
superblock 98304, blocksize=4096 []
superblock 163840, blocksize=4096 []
superblock 229376, blocksize=4096 []
superblock 294912, blocksize=4096 []
superblock 819200, blocksize=4096 []
superblock 884736, blocksize=4096 []
superblock 1605632, blocksize=4096 []
superblock 2654208, blocksize=4096 []
superblock 4096000, blocksize=4096 []

but every time I got this:

$ sudo mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop,ro,offset=1605632
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.


$  dmesg | tail
[50294.582964] UDF-fs: warning (device loop0): udf_fill_super: No partition found (2)

Last edited by Lockheed (2013-12-05 06:10:55)

mr.MikyMaus · 2013-12-05 11:20:40

just a quick and stupid question: isn't the backup.img compressed as you suggested in previous posts? Just run

file /mnt/Disk_D/backup.img

Also, the offset parameter has nothing to do with filesystem superblock - it is used in those situations where the image file contains multiple partitions to point mount to the beginning of a specified partition. If you want to use a different superblock, you must repair the filesystem with fsck giving it a -b parameter with another superblock.

Spider.007 · 2013-12-07 12:10:08

mr.MikyMaus wrote:

[...]
Also, the offset parameter has nothing to do with filesystem superblock - it is used in those situations where the image file contains multiple partitions to point mount to the beginning of a specified partition. If you want to use a different superblock, you must repair the filesystem with fsck giving it a -b parameter with another superblock.

I disagree, as described here you can actually pass the sb parameter to the mount command to directly use the alternative superblock. This allows you to view the data using that superblock directly, instead of needing to go through recoverys

@ts, I wouldn't use the offset parameter for the mount-loop command (your filesystem has no offset since it's a partition backup) but use the sb= parameter instead. The mount offset makes it impossible to access data before the offset-point; while you need that data but want a different location for the superblock.

Last edited by Spider.007 (2013-12-07 12:12:26)

Lockheed · 2013-12-07 16:10:07

The image is decompressed and takes 650GB, which is as much as the partition was on the drive. But I had not enough free space, so I had to save that image on the drive which had the original partition on it.

I tried to check for locations of superblock:

$ dumpe2fs /mnt/Disk_D/backup.img | grep -i superblockdumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: Attempt to read block from filesystem resulted in short read while reading journal super block

No luck. So I tried this:

$ mke2fs -n /mnt/Disk_D/backup.img 
mke2fs 1.42.8 (20-Jun-2013)
/mnt/Disk_D/backup.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
41762816 inodes, 167026688 blocks
8351334 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
5098 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

Now, if I understand correctly, to use it in "sb=" parameter with mount, I need to multiply those numbers by 4.

So I tried the first one:

$ sudo mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop,ro,sb=131072
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.
$ dmesg | tail
[  413.993564] CE: hpet increased min_delta_ns to 20115 nsec
[  765.048697] loop: module loaded
[ 1291.820673] EXT4-fs (loop0): VFS: Can't find ext4 filesystem

But the second one went better, or should I say "different":

$ sudo mount /mnt/Disk_D/backup.img /mnt/arch_backup -o loop,ro,sb=393216
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.
$ dmesg | tail
[ 1354.694258] Buffer I/O error on device loop0, logical block 98304
[ 1354.694261] lost page write due to I/O error on loop0
[ 1354.694264] EXT4-fs error (device loop0): ext4_iget:4044: inode #8: comm mount: bad extra_isize (17818 != 256)
[ 1354.694271] EXT4-fs (loop0): no journal found

I tried it with every following superblock, but the result was identical.

What should I do now?
I found here a similar error, and the advice was to delete journal and recreate it:
http://tipsaboutmywork.blogspot.com/

Remove the journal feature from the file system (downgrade to ext2)
tune2fs -O ^has_journal /dev/sda8
fsck to delete the journal:
e2fsck -f /dev/sda8
recreate the journal (change back to ext3)
tune2fs -j /dev/sda8
and finally, remount it.

Does that have the potential to trash my data (like fsck did earlier) or does it just get rid of the journal, and not touching data?
And if the later is the case, would that result in loss of filenames and folders like photorec recovery?

Should I do that, or should I try something else first?

Last edited by Lockheed (2013-12-07 16:13:40)

mr.MikyMaus · 2013-12-16 17:00:16

It's likely the filesystem is pretty screwed up unless you're doing another mistake I overlooked. It's not necessary the delete the journal as it can be just ignored. Try to mount the filesystem as EXT2 (mount -t ext2), that should ignore the journal entirely (or find a proper switch for mount command for EXT3).

It would be best to have yet another backup copy of the filesystem image or doing all the test read-only. Is the new partition on which the image file is a part of LVM by any chance?

Btw, Spider: offset is related to the partition while superblock is related to filesystem. These two terms are not to be confused as each of them operates on a different storage layer. You're right that you can also mount a filesystem directly using a different superblock by using the sb option but that's still something completely different from the offset parameter.

Lockheed · 2013-12-16 22:40:31

Thanks but no LVM, and the image can't be mounted as EXT2. Already tried that.

Lockheed · 2013-12-19 17:24:15

EPILOGUE:

I recovered almost all the data. Here is how:

1. I re-checked superblock backup locations with

sudo mke2fs -n backup.img

2. I run

e2fsck -b <one_of_the_middle_superblock_numbers> backup.img

3. After quick run, all the data (90%, but everything important) was found in lost+found folder, with proper filenames and folder structure.

Well, that was one informative experience I don't intend to re-live any time soon.

Last edited by Lockheed (2013-12-19 17:25:57)

Arch Linux

#1 2013-11-30 14:25:40

[solved] How to recoved data off a masacred filesystem

#2 2013-11-30 14:38:31

Re: [solved] How to recoved data off a masacred filesystem

#3 2013-11-30 14:42:59

Re: [solved] How to recoved data off a masacred filesystem

#4 2013-11-30 14:50:09

Re: [solved] How to recoved data off a masacred filesystem

#5 2013-11-30 15:06:12

Re: [solved] How to recoved data off a masacred filesystem

#6 2013-11-30 15:13:23

Re: [solved] How to recoved data off a masacred filesystem

#7 2013-11-30 15:24:13

Re: [solved] How to recoved data off a masacred filesystem

#8 2013-11-30 15:38:33

Re: [solved] How to recoved data off a masacred filesystem

#9 2013-12-01 17:24:43

Re: [solved] How to recoved data off a masacred filesystem

#10 2013-12-02 09:51:41

Re: [solved] How to recoved data off a masacred filesystem

#11 2013-12-03 09:04:07

Re: [solved] How to recoved data off a masacred filesystem

#12 2013-12-04 14:54:27

Re: [solved] How to recoved data off a masacred filesystem

#13 2013-12-04 22:10:33

Re: [solved] How to recoved data off a masacred filesystem

#14 2013-12-04 22:21:01

Re: [solved] How to recoved data off a masacred filesystem

#15 2013-12-04 23:24:45

Re: [solved] How to recoved data off a masacred filesystem

#16 2013-12-04 23:29:44

Re: [solved] How to recoved data off a masacred filesystem

#17 2013-12-04 23:46:39

Re: [solved] How to recoved data off a masacred filesystem

#18 2013-12-05 06:02:02

Re: [solved] How to recoved data off a masacred filesystem

#19 2013-12-05 11:20:40

Re: [solved] How to recoved data off a masacred filesystem

#20 2013-12-07 12:10:08

Re: [solved] How to recoved data off a masacred filesystem

#21 2013-12-07 16:10:07

Re: [solved] How to recoved data off a masacred filesystem

#22 2013-12-16 17:00:16

Re: [solved] How to recoved data off a masacred filesystem

#23 2013-12-16 22:40:31

Re: [solved] How to recoved data off a masacred filesystem

#24 2013-12-19 17:24:15

Re: [solved] How to recoved data off a masacred filesystem

Board footer