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?

# 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!

Open in new window

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

If you have a support licence/subscription with VMWare, maybe raise a job with them.
Sometimes they're good, other times you get the feeling that a fault will be an 'around to it'. fix.
projectsAuthor Commented:
No support, it's ESXi.
Andrew DavisManagerCommented:
try "e2fsck -y" to repair the super block.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

projectsAuthor Commented:
That will cause it to be fully recovered and ending up with hundreds/thousands of sub directories.
Joseph GanSystem AdminCommented:
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
projectsAuthor Commented:
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
Joseph GanSystem AdminCommented:
The command will tell whether it was corrupted or not, the one above looks good.
projectsAuthor Commented:
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.
Joseph GanSystem AdminCommented:
The command is:

# e2fsck -f -b 32768 -y /dev/sdb1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.