Lost partition - help me recover data

[lockheed]

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

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:

Code:

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

So I tried to run

Code:

$ 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>

Code:

$ 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.


I then went into testdisk and as I saw it detected sdb1 and sdb2 correctly, I selected "Write" on the partition table. Since then on, gparted sees both partitions, but it sees sdb1 as empty.

I then did this:

Code:

$ 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

Code:

]$ 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.

And some other commands I tried:

Code:

$ 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

Code:

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

Code:

# 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.

I also tried mounting it without help of partition table (not sure if I should use /dev/sdb or /dev/sdb1, so I tried both):

Code:

$ 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.

Code:

$ 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

Here is some output from testdisk while doing deepsearch on partition:

Code:

  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.


Code:

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.

I would really appreciate some help here.

I had online backup of ~10 GB of the most important data of it, but there still is on this lost partition at least another 10-20 GB of really vital data, the loss of which would be quite a blow.

[lockheed]

I see no edit option. Anyway, one more output:

Code:

e2fsck -C0 -p -f -v /dev/sdb1
[sudo] password for juha:
/dev/sdb1: 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.

/dev/sdb1: Block bitmap for group 256 is not in group.  (block 1268396107)


/dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
   (i.e., without -a or -p options)

[mindfulness]

You do not want to attempt recovery on a failing hard drive(or a good ome). Best practices would make an image of the drive using ddrescue. Then run recovery software on the image only. For a paid program try rstudio. If you want to try a free program try testdisk

[Alkzndr]

I would reccomend you to make a copy of lost partition and do any experiments there. Also you can try different datarecovery software on copy. It'll be easier to speak about your data, if you'll upload some part of it (about 1Gb) from lost partition.

[lcoughey]

You are certainly determined to kill your drive, aren't you? Get a clone with ddrescue...if you can. If it fights at all, you might want to outsource to a data recovery professional before there is zero chance to recover your files.

[lockheed]

I am unable to mount the partition image for much the same reason as the partition before:

Code:

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:

Code:

  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:

Code:

$ 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)


[mindfulness]

run testdisk on the image to see if it can find your files

$sudo testdisk /mnt/Disk_D/backup.img

hopefully testdisk can find the partitions and or files for you.

[lockheed]

I did that. Testdisks find about 10 mln partitions, but all of them are with no files. I did run Deep search on 1 or two, no results.

[mindfulness]

How complete of an image did ddrescue do? Did it have lots of missing data? My manual file structure repair skills are minimal, if it was me I would try rstudio on that image file. It is much more polished than testdisk. It does have a cost.

[lockheed]

The dd image is of the whole partition (not disk), and is 650gb in size. While making the image, there was ~330gb data on the partition.

I took a look at R-studio, but it looks like a windows tool and I don't think it can handle dd images and/or read them from ext2 partitions.

[fzabkar]

R-Studio for Linux:
http://www.r-tt.com/data_recovery_linux/Download.shtml

[mindfulness]

dd is different from ddrescue. ddrescue will do a more complete recovery of a disc if it has media damage. I think, but am not sure, if dd completed without error, it probably did get a complete recovery. As to images, r-studio can handle image files and ext2/ext3. If it was me, I would make a whole image of the drive as opposed to the partition and let r-studio(or testdisk) try and sort it all out for you.

[lockheed]

testdisk did nothing useful. I am now trying r-studio.