VMDK file corrupted

[WEVoyagr12]

I have corrupted vmdk files and have tried a few items to recover the data and so far have not had much luck.

I have downloaded the Virtual Disk Development Kit and ran the vmware-vdiskmanager.exe on main vmdk file.  All I get is that the file is corrupted and cannot be repaired.  I tried installing the trial of the Workstation Pro...gladly pay for it if it fixed my disk...and that did not help much.

I then attempted to use Stellar Phoenix Virtual Machine Data Recovery ...which actually was able to see the files..most of them at least...but to recover them I need to pay $300.  I would rather pay money for Workstation Pro so I have something to use later than $300 for recovery that I will hopefully only need this one time.  So...Are there any additional options?  IS there a data recovery built into Workstation Pro somehow like what Stellar is using?

Thanks!

[a_p_]

What you may try is to contact continuum‌ who is a data recovery expert. Maybe he can help, or at least has some hints for you.

André

[continuum · Accepted solution]

Getting WS 12 will very likely not help.
I need some details - call me via skype if you want

Ulli

[WEVoyagr12]

Sure.  What is your skype id? 

[WEVoyagr12]

continuum was able to solve the issue for me.

We created a new blank VM.

Copied of of the blank files contained within that blank VM folder.

Paste that file into my corrupted VM folder

Renamed/removed the corrupted vmdk file as shown in the log.

Renamed the blank file to that of the corrupted vmdk file.

Started the corrupted VM. 

We also ran a chkdsk once we were able to boot up.

Contiuum is great and greatly appreciate your support and advice!

Thanks!

[continuum]

Or to be precise ...
- we had a split sparse vmdk that has been expanded several times - different chunk-sizes
- only s034.vmdk was affected with thousands of GT errors
- s034.vmdk was still only a few kbs in size as it had been just recently added during last expand
- as I regarded the chances for a real repair with vdiskmanager -R as almost zero we simply agreed to discard that few kbs
The actual fix then required to replace s034.vmdk with an unused slice that was created with the same nominal size.

It would have been almost impossible if a monolithic sparse vmdk had been used instead of the split format.
Luicky conditions - so all is well after a pleasant chat

Ulli