Partition recovery - help me retrieve my data
 

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:
So I tried to run

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:

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

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.

Looks like you've done your best - may be beyond the skills of us mere mortals.
Maybe try photorec (same people as testdisk) - you may get a bunch of fragments you'll need to post-process. May be better than nothing. Make sure you recover to a different disk.

One tip when attempting to recover data is to not use the original copy to do the data recovery. Put the hard disk in a different machine and use dd to create an image of the partitions that you need to recover. Do all of your work on the image, that way you don't damage the contents of the partition more when trying to work with it.

I have already done the copy, and tried mounting it, but it failed with the same error, as mounting the pertition:

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


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'm sorry but there's no other way to put it: you fscked up royally:
- you deliberately ran gparted completely unnecessarily and on a disk with pending write ops,
- you then ran fsck on a disk instead of a partition, then
- you ran e2fsck on an ext4 (!), then
- you let testdisk write data to disk and then
- you completely ignored the warning about super blocks and reallocated meta data!
*On top of that you don't tell us exactly at which stage you decided to copy the disk.

Now I don't know your definition of "a last resort" but I'd say you've reached that point...

That may well be, but that's not exactly like that:
- I run gparted, to check partition info of another disk. It did not write anything
- I run fsck as I found it in the internet
- same goes for e2fsck
- testdisk wrote data to partition table, not the disk itself
- how exactly did I ignore warnings of superblocks?

The dd copy of the disk was done after testdisk

Reading this:
...should be followed by a ^C?...


Thanks for clarifying.


What does 'fdisk -l /path/to/diskimage; testdisk /debug /log /path/to/diskimage; kpartx -lv /path/to/diskimage' return?
*For testdisk attach or post the log file.

You may notice that I already did earlier what this message suggested, so I proceeding seemed logical.

I will give you values from /dev/sdb, because the image is compressed and it is more complicated to work on it

Then you have more admin, forensics and practical recovery skills than I have.
Which means you don't need my help.
Good luck!

I suppose that was sarcasm. I have to work on sdb(1) because the image is compressed and all I can do with it is to restore it back. I have not enough free space anywhere to be able to work on a 670GB uncompressed partition image.

Anyway, I bit the bullet and I run 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.

You might have some success restoring the image and using debugfs to dump files. You might also be able to use that to look inside the tattered remains of directories to associate inode numbers that e2fsck used as names in lost+found with their original file names. You will almost certainly have to copy one of the backup super blocks to the primary super block position first.

Note that the objection to using e2fsck on an ext4 file system was unfounded. fsck.ext4, fsck.ext3, fsck.ext2, and e2fsck are all hard links to the same program. But, every time you said "yes" to e2fsck you were compounding the problem and making recovery less likely.