I hope you do not wait for a secret trick or something like that - there is none.
I use the data from the first 1500 Mb of the volume to guess the directory structure, rebuild the vmx-files and guess the vmdk descriptorfiles.
Then I use the same data to make a list of *flat.vmdks that are missing.
With that list I then also know which guest OS were involved. Once I know that I collect different search patterns for the different guest-filesystems.
When I have the search patterns I talk to the user to find out which vmdks are most important. After that I scan the volume for vmdk starting points. Such a scan runs a few hours - depending on the size of the LUN and the amount of different guest OS I want to find.
When the scan is done I have a list with thousands of possible start points. I sort out the improbable ones, calculate the size of the vmdks and then start a script that carves them out.
When i have the flat.vmdks carved out I write descriptorfiles for them.
The carved vmdks are then used inside a VM that boots from a LiveCD so that I can fix filesystem errors without messing up drive letters ...
In an ideal scenario desaster strikes at 12:00 - I collect the 1500 Mbs and analyse it at 13:00 - the scan starts at 16:00 - results are there at 22:00 - the extract-script starts at 0:00 - at 2:00 first recovered VMs can run on a different ESXi.
If possible I use sshfs to connect to a second ESXi - then the vmdks have to be copied only once.