projects
asked on
Recovering corrupted vmdk disk
A raid5 storage crashed leaving all of the vms unable to boot.
I ssh'ed into the host and ran the following commands to recover what ever I could after trying a number of other things.
# vmkfstools --fix check disk-s001.vmdk
# vmkfstools --fix repair disk-s001.vmdk
Created new disk image from old one
# vmkfstools -i disk-s001.vmdk disk-new.vmdk
Now trying to add these disks to an existing vm as a second disk but having all kinds of problems. I was able to recover one disk by using fsck but it basically broke everything down into thousands of small directories making recovery useless. Now I'm trying to find a way of mounting the disks without having to rebuild this time.
Why you ask? This is why.
Once installed as a second disk on a test vm, I only see what appears to be 'Journal superblock magic number invalid!' leading me to believe (HOPE) that I just need to fix the superblock and might be able to mount the disk.
Any way of recovering the data that you know of?
I ssh'ed into the host and ran the following commands to recover what ever I could after trying a number of other things.
# vmkfstools --fix check disk-s001.vmdk
# vmkfstools --fix repair disk-s001.vmdk
Created new disk image from old one
# vmkfstools -i disk-s001.vmdk disk-new.vmdk
Now trying to add these disks to an existing vm as a second disk but having all kinds of problems. I was able to recover one disk by using fsck but it basically broke everything down into thousands of small directories making recovery useless. Now I'm trying to find a way of mounting the disks without having to rebuild this time.
Why you ask? This is why.
Once installed as a second disk on a test vm, I only see what appears to be 'Journal superblock magic number invalid!' leading me to believe (HOPE) that I just need to fix the superblock and might be able to mount the disk.
Any way of recovering the data that you know of?
# dumpe2fs /dev/sdb1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: d1fd0004-ec67-4e4e-b9c5-6492cbbb039c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 786432
Block count: 3145724
Reserved block count: 157286
Free blocks: 2772463
Free inodes: 785446
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 767
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Tue Apr 22 12:19:19 2014
Last mount time: Thu Aug 6 13:15:59 2015
Last write time: Thu Aug 6 13:15:59 2015
Mount count: 35
Maximum mount count: 38
Last checked: Tue Apr 22 12:19:19 2014
Check interval: 15552000 (6 months)
Next check after: Sun Oct 19 12:19:19 2014
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: d5ff043a-e227-4a0f-b239-e1ac8c51f98a
Journal backup: inode blocks
Journal superblock magic number invalid!ASKER
No support, it's ESXi.
try "e2fsck -y" to repair the super block.
ASKER
That will cause it to be fully recovered and ending up with hundreds/thousands of sub directories.
Find out where is the superblock
# mke2fs -n /dev/xxxx
You should see a list of superblock backups
Restore the superblock from the backup
# e2fsck -b block_number /dev/xxxx
# mke2fs -n /dev/xxxx
You should see a list of superblock backups
Restore the superblock from the backup
# e2fsck -b block_number /dev/xxxx
ASKER
How do I know which one is good? What if I use one that's corrupted or does the tool know not to list a corrupted one?
# mke2fs -n /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
786432 inodes, 3145724 blocks
157286 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3221225472
96 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
# mke2fs -n /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
786432 inodes, 3145724 blocks
157286 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3221225472
96 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
The command will tell whether it was corrupted or not, the one above looks good.
ASKER
So, pick any of these, such as the first, 32768
# e2fsck -b 32768 /dev/sdb1
e2fsck 1.41.12 (17-May-2010)
Superblock has an invalid journal (inode 8).
Same thing. Running this tries to fix the entire disk.
# e2fsck -b 32768 /dev/sdb1
e2fsck 1.41.12 (17-May-2010)
Superblock has an invalid journal (inode 8).
Same thing. Running this tries to fix the entire disk.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sometimes they're good, other times you get the feeling that a fault will be an 'around to it'. fix.