[SOLVED] Corrupted ext4 partition image

Rollulp · 07-01-2015, 10:05 AM

Hello,
I had the good sense to back-up the /home partition just a few days before the HDD physically broke.
I just did not have the common sense to do it the right way, as i did:

Code:

$ sudo dd if=/dev/sda5 of=/mnt/1TB_external_drive/Backup.img bs=4M

when just a drag&drop of the folder would have sufficed.

Now I'm left with a ~110GB file that i cannot read.

Code:

$ mkdir mountpoint
$ sudo mount Backup.img mountpoint
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

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

and in dmesg shows up this:

Code:

[17926.346897] EXT4-fs (loop0): bad geometry: block count 84331008 exceeds size of device (28691352 blocks)

I did a backup of that backup and run fsck on it, getting tons of

Code:

Superblock has an invalid journal (inode 8).
Clear<y>?

Answering 'y' to all I get an image that mounts and works, but with just a little stuff in the directory lost+found, completely randomly organized in oddly-named subdirectories.

I'm sure that the data is still there, as I used grep -a pattern Backup.img to look for a bunch of strings and i recovered a couple text files that way, just I have no idea on how to get it out. Any suggestion is appreciated.

Thank you

rknichols · 07-01-2015, 11:25 AM

If that block count (84331008) in the dmesg output is correct, then the filesystem was originally about 345GB (330GiB). Your ~110GB image is missing most of it.

Please post the output from

Code:

tune2fs -l /path/to/Backup.img | grep -i block
ls -ls /path/to/Backup.img
file /path/to/Backup.img

Rollulp · 07-01-2015, 01:44 PM

Code:

$ tune2fs -l Backup_home_21may2015.img | grep -i block 
Block count:              84331008
Reserved block count:     4216550
Free blocks:              47421207
First block:              0
Block size:               4096
Reserved GDT blocks:      1003
Blocks per group:         32768
Inode blocks per group:   512
Flex block group size:    16
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
Journal backup:           inode blocks
$ ls -ls Backup_home_21may2015.img 
114765420 -rwxrwxr-x 1 rolando rolando 117519777792 lug  1 00:16 Backup_home_21may2015.img
$ file Backup_home_21may2015.img 
Backup_home_21may2015.img: Linux rev 1.0 ext4 filesystem data, UUID=12ea940e-4b1a-409d-94f0-efd39cda9ca7 (needs journal recovery) (extents) (large files) (huge files)

The filesystem was 345GB (330GiB). But it was for most part empty. seems like dd cut off unused space. Possible?
Here is all you requested. thanks for trying to help.

rknichols · 07-01-2015, 05:03 PM

Quote:

Originally Posted by Rollulp

The filesystem was 345GB (330GiB). But it was for most part empty. seems like dd cut off unused space. Possible?

No, dd most definitely does not eliminate unused space. It just copies raw bits, and is ignorant of the structure of what it is copying. The most it can do is make a sparse copy by skipping over all-zero blocks in its output, but that is not what happened here.

I don't know how it happened, perhaps an I/O error part way through the operation, but you have only about the first 1/3 of the filesystem in that image. If you can't coax that HDD back to life, the rest is gone unless you want to pay a pretty high price to a professional recovery company.

syg00 · 07-01-2015, 07:45 PM

Quote:

Originally Posted by Rollulp

The filesystem was 345GB (330GiB). But it was for most part empty.

In which case you might be lucky. Try PhotoRec on that copy - especially as it's /home, most of our files could be of known formats.

Rollulp · 07-02-2015, 10:30 AM

I'm afraid the files I'm looking for are not of known extension. Moreover, I need to keep the directory structure, as for thousands of directories it's impossible to fix by hand every path.
The broken HDD can still be read from, but at such low speed that it would take 715 days 11 hours to get the stuff form there. I could however verify that the occupied space in the partition I need is about 110GB. Curious how that number is also the size of Backup.img..
dd does not eliminate unused space, right about that, but somehow something else must have. Ideas?

rknichols · 07-02-2015, 12:50 PM

Quote:

Originally Posted by Rollulp

I could however verify that the occupied space in the partition I need is about 110GB. Curious how that number is also the size of Backup.img..
dd does not eliminate unused space, right about that, but somehow something else must have. Ideas?

From the block counts, I calculate a somewhat larger number

Code:

(block_count - (free_blocks + reserved_blocks)) * block_size = bytes_used
( 84331008   - ( 47421207   + 4216550 + 1003 )) * 4096       = 133907447808

That's about 134GB or 125GiB. If you've got a large number of small files, the slack space in the partially filled blocks might account for the difference between that and 110GB.

Without knowing what went on when you made that image, it's hard to account for the result. I hope it's not because you "knew" you needed only 110GB and had only that much space available for the image, or perhaps gave dd a count parameter that caused it to obediently stop after transferring that much data. Somehow, I doubt that.

Rollulp · 07-02-2015, 02:24 PM

I did not tell dd to stop, the command was a clean dd if=... of=.. bs=5M, i checked it recovering .bash_history, done by grepping though the binary.
Well, since it doesn't seep possible to find out what has happened I decided to close the thread. Thanks for helping