Recovering a deleted VM: re-sequencing .vmdk files?

[edburns]

VMware Fusion Version: 8.5.10 (7527438)

macOS version: 10.11.6

Guest os: Solaris 11 Nevada x64

I hope you can help me.  Through my own error in using Carbon Copy

Cloner, I deleted a very dear old VMware VM that was stored on an

external disk.  I may be able to use recovery software to get the .vmdk

files, and perhaps the .vmx, .plist, .nvram files as well.  However,

when I recover the .vmdk files I completely lose the sequencing and

filenames.  I had several VMs on that disk, and the recovery software

doesn't allow me to understand which .vmdk files go with which vms, and

what are the order of the files.

Is there some way to recover that information?  Is it encoded in the

.vmdk files somewhere?

Thanks,

Ed

[wila]

Hi,

Please give us a file list of what you recovered, preferably a file list from the command line with all details.

Eg. a "ls -alh" and a "ls -lisa"

Attach the output of those commands to a reply (the attach button is in the bottom right corner of the reply window".

Also attach any vmdk smaller than 2 kB in size.

To answer part of your question. The most important part of your VM is the vmdk file as it has the data. Depending on the configuration chosen this can be an "all in one" or split disks where the data is in disk slices and the meta data about those disks is in separate files.

When you say "I deleted a very old dear VM" was that just a filesystem delete or did you wipe the external disk?

What file system is the external disk using?

--

Wil

[continuum]

This is a tricky one.

I assume that you have a number of vmdk files now that were part of one or more split sparse vmdks.
Finding the first slice of a split sparse vmdk is quite easy. You would use a tool like scalpel and scan all the vmdk-files for a MBR or GPT.
If the VM used GPT finding the last slice is also quite easy - it should have a copy of the GPT.
But setting the order of the slices in between is very tricky.
If the VM is important you could try to check all variants - but that can easily become a nightmare the more slices the original vmdk used.
Do you have more than one Solaris VM on that disk ?