How to copy an allegedly “corrupted” (but working!) VDI?

[metaleap]

I need to copy a 87 GB VDI file (the virtual disk of a VirtualBox Virtual Machine), off my old spring-2010 MacBook Pro (SSD) to then transfer it to my new work machine.

This Virtual Machine itself seemingly works fine, I still do work in it every day. I don't have another backup of it.

I try to copy it to a 100GB thumbdrive formatted with exFAT to allow files greater than 4 GB.

• Trying to do so with Finder gives: The Finder can’t complete the operation because some data in “Win7.vdi” can’t be read or written. (Error code -36) -- then the window showing copy progress stalls forever at 31.96 GB of 87.79 GB without even closing itself or anything... should I have waited a few more hours?
• Doing a cp -vX /Users/me/vms/win7.vdi /Volumes/TrekStor/ results in Input/output error at some 28.xx GB.
• Trying the clone-VM feature from within VirtualBox results in a similar error, also around 1/3rd into the process, and mentions possible disk corruption.

However running Disk Utility to check for possible disk corruption or problems reports a perfectly fine disk state without corruption or problems!

And no matter the problem with the disk, block or file -- by the way this problem has been present for months now (kept trying to copy it for backup and gave up on this very issue every 2-4 weeks or so...), all the while I've been using this VM productively for hours every other day with no problems whatsoever -- the VDI "works" without when I load it into VirtualBox and I don't see why I shouldn't be able to "copy the file with all its problems and continue using it the same way in VirtualBox on a different physical host machine"?...

I tried 3 approaches that I'm sure internally all use the cp command anyway. What other options are there? Is there such a thing as block-wise copying when one isn't actually cloning disk images?

[mpack]

Hard to diagnose from a distance and with only partial info, but I'll try.

The VDI is evidently corrupted in a part of the disk not touched by the partitions you tested with chkdsk. An alternate possibility is that you are using snapshots and are oblivious that a chkdsk run from inside the VM is actually testing the current state rather than the base VDI.

The only solution that springs to mind is a running a disk imager from inside the VM, e.g. download into the VM and run Disk2VHD, making very sure that you image the entire disk, and not just one partition. The resulting VHD would be written to a USB drive or a network share (GA shared folders should be avoided for this operation).

Once you have the VHD it can be used as the basis for a new VM - you should only consider mounting it in the original VM if that VM uses no snapshots.

ps. Disk2VHD is very handy, it's unfortunate that I consider VHD to be a pretty horrible format (slow and unsafe). I would convert the disk to VDI format before was willing to use it.