ibo
asked on
data recovery in an ext3 fs
My hard disk crashed and I can still see the disk info using "sudo fdisk -l" :
----------------------
Disk /dev/hdb: 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 65 36642 18434556 7 HPFS/NTFS
/dev/hdb3 57279 75576 9221310 83 Linux
/dev/hdb4 75512 77536 1020127+ 82 Linux swap / Solaris
--------------------------
I already deleted the partition /dev/hdb2 which contains a FAT32 that cause some errors when i do "lvmdiskscan".
-----------------
ibo@ubuntu:~$ sudo lvmdiskscan
/dev/hda1 [ 18.63 GB]
/dev/hda2 [ 18.63 GB]
/dev/hda3 [ 957.00 MB]
/dev/hda4 [ 36.33 GB]
/dev/hdb1 [ 17.58 GB]
/dev/hdb3 [ 8.79 GB]
/dev/hdb4 [ 996.22 MB]
0 disks
7 partitions
0 LVM physical volume whole disks
0 LVM physical volumes
--------------------------
Is there any way I can get at least my /home directory inside the /dev/hdb3?
Ive tried mounting it but failed :
ibo@ubuntu:~$ sudo mount -t ext3 /dev/hdb3 /mnt/hdb3
mount: wrong fs type, bad option, bad superblock on /dev/hdb3,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
ibo@ubuntu:~$ dmesg | tail
....
VFS: Can't find ext3 filesystem on dev hdb3.
---------------
Any Ideas? Ive tried dd_rescue (http://www.garloff.de/kurt/linux/ddrescue/) but couldnt figure out how to use it. Anyone have a clue? Thanks in advance!
Regards,
Stephen
----------------------
Disk /dev/hdb: 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 * 65 36642 18434556 7 HPFS/NTFS
/dev/hdb3 57279 75576 9221310 83 Linux
/dev/hdb4 75512 77536 1020127+ 82 Linux swap / Solaris
--------------------------
I already deleted the partition /dev/hdb2 which contains a FAT32 that cause some errors when i do "lvmdiskscan".
-----------------
ibo@ubuntu:~$ sudo lvmdiskscan
/dev/hda1 [ 18.63 GB]
/dev/hda2 [ 18.63 GB]
/dev/hda3 [ 957.00 MB]
/dev/hda4 [ 36.33 GB]
/dev/hdb1 [ 17.58 GB]
/dev/hdb3 [ 8.79 GB]
/dev/hdb4 [ 996.22 MB]
0 disks
7 partitions
0 LVM physical volume whole disks
0 LVM physical volumes
--------------------------
Is there any way I can get at least my /home directory inside the /dev/hdb3?
Ive tried mounting it but failed :
ibo@ubuntu:~$ sudo mount -t ext3 /dev/hdb3 /mnt/hdb3
mount: wrong fs type, bad option, bad superblock on /dev/hdb3,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
ibo@ubuntu:~$ dmesg | tail
....
VFS: Can't find ext3 filesystem on dev hdb3.
---------------
Any Ideas? Ive tried dd_rescue (http://www.garloff.de/kurt/linux/ddrescue/) but couldnt figure out how to use it. Anyone have a clue? Thanks in advance!
Regards,
Stephen
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ive tried:
>fsck.ext3 -vc -b 32768 /dev/hdb3
but I got the error :
fsck.ext3: Bad magic number in super-block while trying to open /dev/hdb3
>fsck.ext3 -vc -b 32768 /dev/hdb3
but I got the error :
fsck.ext3: Bad magic number in super-block while trying to open /dev/hdb3
ASKER
Ok I got some of my questions answered on MAN :)
--quoted--
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.
Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary superblock is updated appropriately upon completion of the filesystem check.
--quoted--
Using mke2fs -n, It listed all the superblock backups and tried them one by one using
e2fsck -b <superblock backup number> /dev/hdb3
but it always says Bad magic number.
--quoted--
Instead of using the normal superblock, use an alternative superblock specified by superblock. This option is normally used when the primary superblock has been corrupted. The location of the backup superblock is dependent on the filesystem's blocksize. For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k blocksizes, at block 32768.
Additional backup superblocks can be determined by using the mke2fs program using the -n option to print out where the superblocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate.
If an alternative superblock is specified and the filesystem is not opened read-only, e2fsck will make sure that the primary superblock is updated appropriately upon completion of the filesystem check.
--quoted--
Using mke2fs -n, It listed all the superblock backups and tried them one by one using
e2fsck -b <superblock backup number> /dev/hdb3
but it always says Bad magic number.
Well if you've tried all the superblocks then I guess the inode table is screwed (technical term), and the disk is totally corrupted. Had the same thing happen with reiserfs on a ATA disk once, needed to mkfs it to start to use it again, but it will wipe thew disk. The only option now is to use a data recovery program ,such as Ron_d suggested and pray you can get back some useful info. It also might be worth while eneabling S.M.A.R.T in the BIOS and smartd monitor in the OS, this should warn you if the disks are encountering many bad blocks, and will hopefully map around them, but if this is the case then you should look to replace the failing disk soon.
BTW, inthe satement above:
"Using mke2fs -n, It listed all the superblock backups and tried them one by one using
e2fsck -b <superblock backup number> /dev/hdb3
but it always says Bad magic number"
I assume you meant fsck.ext3 not fsck.ext2 and running the wrong type will always fail.
BTW, inthe satement above:
"Using mke2fs -n, It listed all the superblock backups and tried them one by one using
e2fsck -b <superblock backup number> /dev/hdb3
but it always says Bad magic number"
I assume you meant fsck.ext3 not fsck.ext2 and running the wrong type will always fail.
ASKER
FYI: stellar phoenix for windows solved my problem.
ASKER
Prof666,
>fsck.ext3 -vc -b 32768 /dev/hdb3
Im curious, how did u came up with this magic number: 32768?
>you need to recontruct the primary superblock from one of the secondary ones (in most cases the next available one is 32768).
What are these superblocks and how do you compute for the next available supeblock? Whats the diff between primary and secondary superblock?
Anyhow, I'll try your suggestion see what comes out.
Btw, I was able to use the dd_rescue to copy the whole /dev/hdb3 partition to another hard disk. But when Ive tried to mount
I got the same error, bad superblock. I guess Im faced with the same prob here but at least I already have a backup if ever the defective device totally collapsed.