Single VMDK file of a multi file disk appears to be corrupted - cannot copy or move. VM is still accessable

[rulmer]

I am running VMware Workstation v12 and the VM in question is 'hardware version' 6.5-7.x. When the VM was created, the (~100 GB) disk was broken up into 2 GB files so there are about 52 VMDK files. I need to move the VM from the physical SSD that it is located on to another drive so I can replace the SSD with a larger one.

The host OS is Win 7 Pro 64-bit SP1 and the guest OS is Win 7 Pro x32 SP1.

One of the files (W7-P-x32-S005.vmdk) causes program that 'touches' it to hang up / stop responding. I have tried to copy it to another drive - Windows Explorer 'hangs' when it tries to copy the file. I've tried to zip the file to move it - WinZip hangs when it tries to add the file to the zip file. I've tried to export the VM to an OVA file but the export hangs and never completes. I have removed all of the snapshots in the hopes that one, or more of the file clean ups would nudge the file back into being accessible again - no luck. I have defragmented the VM and compressed the VM to recover space, all of which hasn't changed anything.

I have run a windows error check on the drive. The automatically fix file system errors runs quickly to completion. The scan disk, and attempt recovery of, bad sectors hangs up during the scan process.

Every other file is accessible without any problems.

Surprisingly the VM will boot up and run with no apparent ill effects.

I have copied all of the files to another drive, with the exception of the problem file, successfully - both by direct copy and by adding them all to a zip file and unzipping to the other drive. Again, every other file works without any issues.

I would be very appreciative if anyone can shed some light on my situation to help me save the VM.

[a_p_]

If a disk scan hangs it unfortunately looks like a hardware issue (i.e one or more bad blocks).Another - less likely reason would be a virus scan application which detects a false positive for this file (that's why I usually exclude *.vm* files from being scanned).

Anyway, in case this is a hardware issue, maybe continuum​ can help, or recommend a tool which is able to at least copy most of the data.

Btw. what's the size of this file.

André

[continuum]

You say the VM loads and boots without noticeable issues ?
One idea I would eventually suggest is:
- power off VM
- create new virtual disk that uses exactly the same size of the split chunks.
- boot VM into Linux LiveCD
- assuming /dev/sda is the old - bad - vmdk and /dev/sdb the new one and 2Gb is the chunk-size do the math and use a dd-command like
- dd if=/dev/sda of=/dev/sdb bs=1gb count=2 skip=8 seek=8 conv=notrunc
(as this command will probably fail you would instead use ddrescue or create a script that carefully leaves out the bad area)
Result would be a new *-s005.vmdk without having to clone the full vmdk.

This is a very ough overview of the procedure - just to give you an idea ...

Actually I cant tell you at the moment what I would really do - more details are required.

Ulli

[a_p_]

One more thing that I just thought of, is that most vendors offer health check, and repair tools for their SSDs.

Anyway, prior to running any repair tools, I strongly recommend that you follow continuum​'s instructions to avoid possible (further) data loss.

André