I have a large (15.7 Gigabyte) VM image that I want to backup from my laptop.

It resides on a NTFS partition (windows 7; 64bit).

When I'm trying to copy the file using the "Windows Explorer", it always gets stuck at 4 Gigabyte. The file is not in use. The 4 GB limit should not apply, if I understand the limitations of FAT16 / NTFS. The error message is:

"Can't read from the source file or disk".

It doesn't matter where I copy it to, e.g. network drive, external NTFS drive. I also tried to use 7zip to split the file (zip; zero compression). 7zip errors out with a "Data error (cyclic redundancy check)". Then I tried robocopy <source folder> <destination folder>; robocopy reports ERROR 23 and Data error (cyclic redundancy check). Copying to an sftp server also gave an error.

The strange thing is, though, that the file isn't corrupt. The VirtualBox image loads fine and I can perform all nominal operations on it.

Could you give me hints on what to try out next? I am more familiar with Linux and I would like to attempt a raw copy (on Linux: dd), but I don't know how to do that in Windows. Also note that I'm not an administrator on this machine (but I can ask for it through some hassle). I also don't have the ability to mount the drive on another system. Unfortunately, my in-house administrators do not have much creativity...

What could help? file system check (dunno how to force it)? "raw copy" there seem to be tools online? any commands to try?

  • 3
    Almost sounds like that file is somehow corrupt. Is it a VDI storage file? or something else?
    – LPChip
    Jun 27 at 8:21
  • "I would like to attempt a raw copy (on Linux: dd), but I don't know how to do that in Windows." - Create a live USB of your favourite distro (e.g. Debian Live) and attempt a dd from there. And "I also don't have the ability to mount the drive on another system." - Why not? Pull the drive from the lappy, hook it up to a 'Nix PC via a suitable usb caddy, viola... you can dd to your hearts content!
    – user1138
    Jun 27 at 8:38
  • @LPChip: It's a VirtualBox vdmk file. @user1138: unfortunately, I don't own the laptop and cannot tamper with it in this way.
    – Bash Frank
    Jun 27 at 9:41
  • 1
    you may need defragment the source disk and check for errors a Linux approach it's good i will try whit rsync before dd
    – denn0n
    Jun 28 at 0:03
  • 1
    Sounds like LPChip is correct and the file is corrupt even though virtualbox can still open it. As a last resort, have you tried using Virtualboxes built in export functionality ?
    – Silbee
    Jun 28 at 8:18

5 Answers 5


The file in question might have a bad sector that is not normally used, so is only discovered when copying all the sectors.

You may find information about the disk's status by consulting its SMART attributes, for example by using Speccy. You may also consult the Event Viewer for messages concerning the disk.

If a bad sector is found, you may either discard or recreate the VM, or copy it from backup.

Otherwise, you will need to use products for recovering the disk. Or you could use an unstoppable copier product that will just ignore the bad sector, but you will then end up with a damaged VM.

  • I agree that your assumption "not used bad sector" could be right. Which tool would allow me to copy the file and ignore the sector? It seems the sector is not relevant for the image (could be free space of the guest OS). I'd give it a try...
    – Bash Frank
    Jun 27 at 9:44
  • 1
    For Windows I only know of Roadkil's Unstoppable Copier. For Linux, which you could use with a Live USB, there is also ddrescue.
    – harrymc
    Jun 27 at 9:50
  • dd ... iflags=noerror,fullblock ... | split ... ?
    – Hannu
    Jun 27 at 16:06
  • this answer helped me a lot. For my solution see superuser.com/a/1729274/576779.
    – Bash Frank
    Jun 30 at 15:11

Many thanks @all for the help and enthusiasm. Always enlighting to see how much help one can get here.

Resolution of the story:

After following advises to export the VM, the bad blocks theory got my attention. Interestingly, the bad blocks were not affecting the operation of the VM guest as it probably was located in unused guest disk space. It could also be related to the fact that the VM disk was created as "growable" to a maximum size of 20 gigabytes, but it wasn't using that much space yet.

Due to missing admin rights, I couldn't mount the entire host disk, or install unstoppable copiers. However, the decisive hint came from @criggie: "Back-up the VM from within".

I added a second virtual disk to the VM (sdb) and also attached a bootable Linux ISO. From within the booted Linux ISO, I could execute dd to mirror sda to sdb. However, it resulted in errors. When dd failed, I fell back on ddrescue, which copied as much as possible (while playing with dd, for the first time also a Windows indication on disk corruption appeared -- also shown):

enter image description here

I could backup the 20 gigabytes image of sdb to an external drive. I removed the corrupt virtual hardisk sda and the ISO from the VM and booted into the new system from the backup sdb. So far, it looks like no data corruption has occurred, at least not in the system libs or home directory.

Special thanks also to @Silbee and @harrymc. I'll accept my own answer to show the specific resolution.


I'm a little confused on the partition formats on the source and destinations:

  • NTFS (on Windows 7) supports a maximum file size of 16TB
  • FAT16 supports a maximum file size of 4GB

If you're trying to copy a 16GB file from a Windows 7 NTFS partition to a FAT16 partition it will not work (regardless of the copy mechanism such as USB, SCP or network drive) and will fail at the 4GB mark because that is the largest file size allowed on FAT16.

I would recommend re-checking the partition formats and maximum file sizes of the destinations you are attempting to copy to.

  • 1
    thanks for the answer. However, as stated in the question, the target FS is also NTFS. I've also tried just to copy it into another folder on the same disk (same error).
    – Bash Frank
    Jun 28 at 8:16
  • You mean FAT32. Technically FAT16 is also limited to 4GB, but nobody is using it anymore.
    – gronostaj
    Jun 28 at 9:41

Worst case is there's some creeping fault in the machine and you're at risk of loosing data. Grab your irreplaceable data immediately, even if its by copy-and-paste or email. Do it ASAP because it could get worse quickly.

Then, some things to try:

  • Scan the physical disk from within the Host OS, if the admin allows running of chkdsk or similar tools.
    If not, then boot a USB live image of your preferred distro and scan the physical disk directly.

  • Test the virtual disk from within the running VM. If its windows or linux or something else makes no difference, it should have some form of chkdsk or fsck or similar.

  • Back up the running VM from within the running VM. You might need to boot into single user mode if its linux, or boot the VM with a separate linux boot ISO/image.
    The difference here is you're backing up the filesystem, not the disk image. They're very similar things, but not identical.
    This may avoid any "bad sector"-like weirdness.

Good luck!

  • 1
    this answer helped me a lot. For my solution see superuser.com/a/1729274/576779
    – Bash Frank
    Jun 30 at 15:11

The file might look like 15 gigabyte, but if it's sparse (vm-ware does this, if you select it during disk creation), it may get expanded to its full size during copying.

If it's a 100gb sparse disk that's nearly empty, it won't fit on a 64gb usb stick, if all those zeros get inserted


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.