Restore a partition with a damaged superblock

HisDudeness · 2017-06-04 20:45:24

The biggest partition in my 2TB drive is at the present state unusable, because its superblock got damaged.

# mount /dev/sdb2 /media/Storage                       [0]
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
       missing codepage or helper program, or other error

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

# e2fsck /dev/sdb2                                        [8]
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

I've tried restoring the superblock

# mke2fs -n /dev/sdb2                                  [1]
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 480379925 4k blocks and 120102912 inodes
Filesystem UUID: b8e33f01-ae8e-47d1-b4fd-62863942bc03
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

But trying any of the aforementioned superblock backups give the same negative result, the same as running with no superblock specified

# e2fsck -b 11239424 /dev/sdb2                         [0]
e2fsck 1.43.4 (31-Jan-2017)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
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>
 or
    e2fsck -b 32768 <device>

I've used GNU ddrescue to dump a copy of that partition (but it looks like the whole disk got dumped)

# ddrescue -d -r3 /dev/sdb2 /media/Otto/test.img test.log
GNU ddrescue 1.21
Press Ctrl-C to interrupt
Initial status (read from mapfile)
  rescued:    1660 MB,     errsize:        0 B,  errors:       0

Current status
     ipos:    1967 GB, non-trimmed:        0 B,  current rate:  44195 kB/s
     opos:    1967 GB, non-scraped:        0 B,  average rate:  71393 kB/s
non-tried:        0 B,     errsize:        0 B,      run time:  7h 38m 57s
  rescued:    1967 GB,      errors:        0,  remaining time:         n/a
percent rescued: 100.00%      time since last successful read:          0s
Finished

And the resulting image behaves exactly as the original partition. testdisk also isn't helping me, I have not been able to make it recognise the partition's content due to the faulty superblock. I've tried dding the first block to 0 as suggested somewhere in case overwriting the superblock failed, but that didn't change anything. I'm now trying to use SleuthKit's Autopsy, but I'm essentially grasping at straws here. Any help?

If any other command output is needed, or even the story of how I ended up here in order to understand the possible cause and hence the problem, please just ask me.

HisDudeness · 2017-06-07 07:18:39

I have to correct a couple of things. I've found the output of mke2fs when I created the partition (I saved it in an usb key) and tried with all the backup superblocks stored there (some numbers where different as block size is 4096) and with some it gives me the bad magic number message, with others it says "e2fsck: invalid argument while trying to open /dev/sda2".

Sorry for bad formatting, but I'm on my phone, I'm at work. As soon as I get on my computer, I'll post some outputs too.

Anyway, I'm thinking about running mke2fs with the -S (capital s) option. Any reason I shouldn't? I've got a full GNU ddrescue backup.

frostschutz · 2017-06-07 07:27:11

Use snapshots, overlays. https://raid.wiki.kernel.org/index.php/ … erlay_file (not only for raid)

That way you can experimente without really writing to the affected disk / partition, and quickly revert when an experiment fails. (and not wait 10 hours for dd to make another copy)

How did the superblock get damaged? Is there a possibility you have the wrong partition table / partition offset?

Your ddrescue shows "1660MB rescued" which is a lot less than it should be... did you make that paste early in the process?

Also give testdisk and other tools a whirl. Always on the overlay.

HisDudeness · 2017-06-07 08:36:53

What is the difference between snapshots and ddrescue's dumps?

That line is the initial state. Below is the final one.

How I ended up like this is a long story. My laptop probably has a SATA problem somehow. If I physically move it, it completely loses awareness of the hard drive, being unable to even shutdown, and not finding any bootable device afterwards.
I even changed hard drive after this happened, but it recently resumed this behaviour.

In these days it got a lot worse, so I've decided to put my new HDD in its external tray. The system boots 100% of the times without any problem now, but on first USB boot its second partition got this superblock problem.

frostschutz · 2017-06-07 09:10:09

What is the difference between snapshots and ddrescue's dumps?

ddrescue takes 8+ hours to create and you have to re-do it when you botch it with fsck gone wrong. The overlay is instant. Gives you a /dev/mapper/thing device you can write to without actually writing to the original /dev/thing.

on first USB boot its second partition got this superblock problem

Some USB enclosures emulate a different sector size (512e for 4K drives or vice versa), causing partitions to point to the wrong offsets. So if this is a HDD you used internally and then migrated to an USB enclosure, it could be your problem.

HisDudeness · 2017-06-07 09:27:22

You gave me hope, as soon as I get home I'll get a screwdriver and try. Even if what I did a year ago was buying a Seagate Backup Plus Slim, which can be used internally, and swap the HDD inside with the one which was inside my laptop. This never gave me any problem with its second partition when used with that enclosure.

HisDudeness · 2017-06-07 15:25:03

Unfortunately I've just tried and the situation does not change. When I have time, I'll try with the overlay.

Overlay or ddrescue, is there something I should try before mke2fs -S?

Arch Linux

#1 2017-06-04 20:45:24

Restore a partition with a damaged superblock

#2 2017-06-07 07:18:39

Re: Restore a partition with a damaged superblock

#3 2017-06-07 07:27:11

Re: Restore a partition with a damaged superblock

#4 2017-06-07 08:36:53

Re: Restore a partition with a damaged superblock

#5 2017-06-07 09:10:09

Re: Restore a partition with a damaged superblock

#6 2017-06-07 09:27:22

Re: Restore a partition with a damaged superblock

#7 2017-06-07 15:25:03

Re: Restore a partition with a damaged superblock

Board footer