The system cannot find the file specified.

[vimay]

André,

I have a problem that is similar to what's described in the original post.

in my case, the VM starts successfully when Snapshot #5 is selected; however, any attempts to select #6 (mdServer-000006.vmdk) or #7 (mdServer-000007.vmdk) result in the same "The system cannot find the file specified" message.

I would really appreciate if you could help me in recovering the latest snapshots.

The attached zip contains all files assembled per your instructions.

Thanks,

Vitaly

Moderator note by a.p.: Branched reply from Re: The system cannot find the file specified. VMware `12.5​ into a new discussion.

[a_p_]

Welcome to the Community,

first, and foremost - unless already done - backup the VM's folder/files, and then disable "AutoProtect" in the VM's settings. This feature makes users think that they are save, but in a lot of cases it rather causes issues. Instead of using "AutoProtect" do regular backups!

From the information that you've provided it looks like the .vmsd file is incomplete, which is likely a result of a lost .vmdk file.

The file that's missing is "mdServer-000006-s022.vmdk", which may have contained up to about 4GB user data. Do you have a backup of this file with a time stamp of 07/30/18?

Unless you have a backup, replace the missing file with a copy of e.g. "mdServer-000007-s022.vmdk". Since the missing data definitely causes a file system corruption, and data loss in the guest OS, I'd recommend that you don't power on the VM, but rather use the "Map Virtual Disk ..:" feature, and try to extract/backup important data this way.

Once you've backed up everything you need, you can then try to power on the VM.

Due to the incomplete .vmsd file, you may not be able to set the VM to the state where "mdServer-000006.vmdk" was the current virtual disk. This is something that you would need to do manually, i.e. by carefully editing the VM's configuration (.vmx) file while VMware Workstation, or at least the VM's tab is closed. Another option - since you've got plenty of free disk space - is to clone the virtual disk, and to attach the clone to a newly create "dummy" VM. To clone the disk from the corrupted (unless you had a backup of the missing file) state, run.

vmware-vdiskmanager -r mdServer-000006.vmdk -t 1 mdServer-Clone.vmdk

This command will consolidate the snapshot chain into a new base virtual disk, i.e. clean up the "AutoProtect" snapshots.

André

[vimay]

André,

Thanks for your  quick response!

following you advice, I tried to clone the disk and while cloning of "mdServer-000006.vmdk" came back with an error, "mdServer-000007.vmdk" worked.

Moreover, I was even able to start the clone with its own OS.

Unfortunately, the clone (most likely) represents the machine state as of 7/30, and of course, I would need something closer to the last known state (9/12).

Based on the file listing, do you think any recent information is recoverable?

Thanks,

Vitaly

[a_p_]

... cloning of "mdServer-000006.vmdk" came back with an error, ...

Did you replace the missing file prior to starting the cloning process?

If you did, please provide details about the error.

Unless the missing file can be restored from a backup, the data that was stored in this file is fone (~4GB).

However, it should at least be possible to create the mentioned clone, so that most of the data can be restored.

From what I saw in the file that you've provided, the important snapshot chain is:

base.vmdk -> 000002.vmdk -> 000007.vmdk -> 000001.vmdk -> 000003.vmdk -> 000006.vmdk

It looks like you reverted to snapshot 000003.vmdk (mybe while troubleshooting the issue), and that's why you also have a snapshot 000005.vmdk, which also has 000003.vmdk as it's parent.

A clone of 000006.vmdk will contain all of it's own, as well as it's parent's data (except for the data in the missing file).

André

[vimay]

I created 'mdServer-000006-s022.vmdk' by copying 'mdServer-000007-s022.vmdk' and attempted to clone 'mdServer-000006.vmdk'.

The process almost immediately returns:  "Failed to convert disk: The specified virtual disk needs repair (0x3e86)."

If 000003.vmdk is more recent than 000007.vmdk, should I copy-paste 000003-s022.vmdk to 000006-s022.vmdk instead of 000007?

Thanks!

[a_p_]

It's most likely not an issue with the replaced file, but with another .vmdk file.

To find out which of the files has/have issues, please extract the metadata from these files.

To do this, download dsfok.zip from http://faq.sanbarrow.com/index.php?action=artikel&cat=47&id=111&artlang=en, extract the executables, run the below mentioned command in the VM's folder, then compress/zip all the "xxx-....bin" files and attach them to a reply post

for %i in (*-s???.vmdk) do @dsfo.exe "%i" 0 1536 "xxx-%~ni.bin"

To make live easier, and reduce the search time for me, please start the following cloning commands, and let me know which of them throws the mentioned error.

vmware-vdiskmanager -r mdServer-000006.vmdk -t 1 mdServer-Clone6.vmdk

vmware-vdiskmanager -r mdServer-000003.vmdk -t 1 mdServer-Clone3.vmdk

vmware-vdiskmanager -r mdServer-000001.vmdk -t 1 mdServer-Clone1.vmdk

vmware-vdiskmanager -r mdServer-000007.vmdk -t 1 mdServer-Clone7.vmdk

vmware-vdiskmanager -r mdServer-000002.vmdk -t 1 mdServer-Clone2.vmdk

André

[vimay]

All clones completed successfully with the only exception for mdServer-000006.vmdk.

Please see that attached zip that I assembled per your instructions.

Thanks!

[a_p_]

I'm sorry, but I made a mistake. I didn't provided an correct number of bytes to extract from the .vmdk files.

Please delete the "xxx*.bin" files, and run:

for %i in (mdServer-000006-s???.vmdk) do @dsfo.exe "%i" 0 524288 "xxx-%~ni.bin"

then - since "mdServer-000006-s026.vmdk" is smaller than the other files - delete "xxx-mdServer-000006-s026.bin", and run

for %i in (mdServer-000006-s026.vmdk) do @dsfo.exe "%i" 0 131072 "xxx-%~ni.bin"

to ensure that the .bin file only contains metadata, i.e. no user data.

Then compress/zip the newly create .bin files, and attach them to a reply post.

André

[vimay]

André,

if making an extra set of bin files will help in any way, I am ready!

Please see the attached.

Thanks!

[a_p_]

That's strange, I can't find errors in the metadata of these files!?

What we can try next, is to:

1. close VMware Workstation, or at least the VM's tab
2. set scsi0:0.fileName = "mdServer-000006.vmdk" in the VM's configuration (.vmx) file
3. create another snapshot, to ensure that the current .vmdk files won't get modified
4. try to power on the VM

This should report the issues in the vmware.log in the VM's folder.

André

[vimay]

Followed you instructions. Cloning of the disk did not work - I got 'Disk needs repair' message. However, that was not a big problem as I've got copies of the entire VM folder.

Then, a miracle happened - the machine started on her own!!!!

It is unclear whether I'll be able to recover the database from this machine but the first attempts look promising.

The log file (please see the attached) shows a lot of errors but I am certainly not qualified to make any conclusions.

Thanks!

[vimay]

André,

It took me a few days, but in the end, I was able to recover almost everything.

One database got seriously damaged but the lost portion of the data was not essential.

Thanks A LOT for your help!

BTW, do you think the AutoSnapshots are more reliable in the Workstation V15 and can be used for backup purposes?

Thanks,

Vitaly

[a_p_]

Glad to see that you were able to recover important data.

With the information from the latest log file, I took a closer look at the .vmdk files. There were no issues with the metadata structure itself, i.e. no holes, duplicates, ..., but what I found is that the "Unclean shutdown" bit was set in all of the snapshot ...-000006-x###.vmdk files. This bit gets reset during a clean shutdown only, so it looks like that eitehr the VM's process was killed (or crashed), or the system was rebooted without shutting down the VM.

Anyway, I strongly recommend that you rather backup the VM regularly, than relying on snapshots. Snapshots may be ok to have a way back to a previous point in time, but do not replace backups. Running a VM with active snapshots will also require additional disk space, and may result in decreased VM performance.

André