LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 12-01-2013, 03:47 PM   #1
impact0r
LQ Newbie
 
Registered: Jun 2010
Posts: 24

Rep: Reputation: 0
Question 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:
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

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.
 
Old 12-01-2013, 05:02 PM   #2
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 18,496

Rep: Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099Reputation: 3099
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.
 
Old 12-02-2013, 12:30 PM   #3
CincinnatiKid
Member
 
Registered: Jul 2010
Posts: 454

Rep: Reputation: 47
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.
 
1 members found this post helpful.
Old 12-02-2013, 12:32 PM   #4
impact0r
LQ Newbie
 
Registered: Jun 2010
Posts: 24

Original Poster
Rep: Reputation: 0
I have already done the copy, and tried mounting it, but it failed with the same error, as mounting the pertition:
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.
 
Old 12-02-2013, 02:55 PM   #5
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590
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...
 
Old 12-02-2013, 03:01 PM   #6
impact0r
LQ Newbie
 
Registered: Jun 2010
Posts: 24

Original Poster
Rep: Reputation: 0
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
 
Old 12-02-2013, 03:22 PM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590
Quote:
Originally Posted by impact0r View Post
- how exactly did I ignore warnings of superblocks?
Reading this:
Code:
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.
...should be followed by a ^C?...


Quote:
Originally Posted by impact0r View Post
That may well be, but that's not exactly like that
Thanks for clarifying.


Quote:
Originally Posted by impact0r View Post
The dd copy of the disk was done after testdisk
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.
 
Old 12-02-2013, 03:35 PM   #8
impact0r
LQ Newbie
 
Registered: Jun 2010
Posts: 24

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by unSpawn View Post
Reading this:
...should be followed by a ^C?...
You may notice that I already did earlier what this message suggested, so I proceeding seemed logical.

Quote:
Originally Posted by unSpawn View Post
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.
I will give you values from /dev/sdb, because the image is compressed and it is more complicated to work on it
Code:
fdisk -l /dev/sdb

Disk /dev/sdb: 698.7 GiB, 750156374016 bytes, 1465149168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x5dd72774

Device    Boot      Start        End    Blocks  Id System
/dev/sdb1 *          2048 1336215551 668106752  83 Linux
/dev/sdb2      1336215552 1465147391  64465920  83 Linux
Code:
/dev/sdb: LBA, HPA, LBA48, DCO support
/dev/sdb: size       1465149168 sectors
/dev/sdb: user_max   1465149168 sectors
/dev/sdb: native_max 1465149168 sectors
/dev/sdb: dco        1465149168 sectors
Using locale 'en_GB.UTF-8'.


Mon Dec  2 21:28:56 2013
Command line: TestDisk /debug /log /dev/sdb

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.11.4-pf (#1 SMP PREEMPT Thu Nov 7 16:29:08 CET 2013) x86_64
Compiler: GCC 4.8
Compilation date: 2013-08-06T08:42:31
ext2fs lib: 1.42.8, ntfs lib: libntfs-3g, reiserfs lib: 0.3.0.5, ewf lib: none
Hard disk list
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63, sector size=512 - Hitachi HTS547575A9E384, S/N:J2190020D4N8HC, FW:JE4OA60A

Partition table type (auto): None
Disk /dev/sdb - 750 GB / 698 GiB - Hitachi HTS547575A9E384
Partition table type: None

TestDisk exited normally.
[juha@panzor ~]$
Code:
kpartx -lv /dev/sdb
sdb1 : 0 1336213504 /dev/sdb 2048
sdb2 : 0 128931840 /dev/sdb 1336215552
 
Old 12-02-2013, 08:26 PM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590Reputation: 3590
Quote:
Originally Posted by impact0r View Post
I will give you values from /dev/sdb
Then you have more admin, forensics and practical recovery skills than I have.
Which means you don't need my help.
Good luck!
 
Old 12-03-2013, 04:01 AM   #10
impact0r
LQ Newbie
 
Registered: Jun 2010
Posts: 24

Original Poster
Rep: Reputation: 0
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
Code:
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.
 
Old 12-03-2013, 12:12 PM   #11
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,362

Rep: Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001Reputation: 2001
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Recovery of data from encrypted partition Phorize Slackware 27 05-13-2013 02:42 AM
ext3 Data Recovery, Old Partition anonymous_noob_01 Linux - Hardware 1 02-07-2008 08:30 PM
data recovery of ext3 partition awalp Linux - Software 14 09-04-2007 06:07 PM
partition data recovery rlg Linux - Newbie 5 04-22-2005 01:27 AM
Data Recovery from former NTFS partition exark237 Linux - Hardware 3 07-21-2004 07:27 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 04:35 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration