Actually, I am quite disappointed with your strategy to remove basic compression on the standard edition causing this kind of disservice. I think that your product is good and the choice to keep it free and "low-cost" is reasonable. However, while the previous version worked fine, the 0.4 introduced this big issue that push us only to the solution, buying the advanced (at least) version.

In my case, my backup HD is attached with giga ethernet to the PC that I use for thin ware but the issue appears when I backup a VM of 100Gb. If I backup a VM of 20Gb the job is properly run.

I hope that a solution will be found soon.

Thanks

First off I'd like to just say, vBackup is a great little product. We normally use Arcserve to backup our vSphere VMs. We have a couple of stand-alone ESXi servers with a copule of VMs that need to be backed up every day be we do not want to put them in to the enterprise backup rotation. vBackup let me be lazy and not create my own solution using VDDK API. When I saw that vBackup was going out of beta, I was almost sure I was going to have to re-invent the vBackup wheel. vBackup provides a great framework to fill our DR needs on couple relatively small VMs. So thank you Thinware for letting me to continue to be lazy.

With vBackup 4.0, I'm getting this error as well. After reading this thread, I migrated one of the source VMs from a think provisioned disk to a thing provisioned disk. Amazingly enough, the backup began working and working repeatedly every single time. This behavior kind of discredits the theory of a write issue on the destination storage. My destination storage are five ST3146707LC disks set in RAID 0 on a PERC3/Di. So my disks are local but I'm still getting the error. It would seem that this error should persist with a thick or thin provisioned vdisk if it were truly a destination storage issue.

Another point against this being a destination storage issue is the different ways that vBackup and VDDK seem to handle copying the snapshot. With a thin provisioned vdisk, I can watch all 2GB split files be created with zero bytes. As the copy proceeds, I can watch each split file get filled with data until it completes. On thick provisioned disks things are a little different. The 2GB split files are not preallocated. As the copy proceeds, each split file is just created as needed. Then at the end of the VDDK copy process, the error of topic comes up:

 [NFC ERROR] NfcNetTcpRead: bRead: -1
[NFC ERROR] NfcNet_Recv: requested 261704, recevied only 98304 bytes
[NFC ERROR] NfcFile_RecvMessage: data recv failed. retval = 3, expected 261704
[NFC ERROR] NFC_NETWORK_ERROR
Failed to convert disk: Operation completes asynchronously (0x300004650).

And if it's of any importance, the "Convert: 0%" never leaves 0% even though I'm watching data be transferred from the ESXi host and written to the split-files on local disks.

I'm no VDDK expert and I can't see the source code for vBackup. My gut tells me that some small changes were made in vBackup 4.0 on how it works with VDDK. Maybe it was tuned to work best with VDDK 5.5. I'm still using VDDK 5.1 because the server vBackup is running on is just 32-bit. Like I said, I can't see the source code so that's just a hunch based on my anecdotal evidence.

In short, you guys are doing a great job! I commend you for keeping a free tier for vBackup. As a free user who loves you guys, at least entertain me and look at how vBackup and VDDK are backing up thick provisioned disks. Maybe in my rantings, you've discovered a clue to this issue that your free users are facing.

vBackup 4.0.1.2713
Windows Server 2003 R2 SP2 (32-bit)
ESXi 4.1.0 1198252

Thank you to everyone for your continued patience here.

Please remember that this error is reported from VMware VDDK. Because of this there is really nothing we can do in vBackup (outside of enabling compression in the Standard Edition, which by design is currently not planned).

Maybe what we can do is communicate better - we will accept this as our fault on this one.

One important thing to note is that nothing changed in vBackup 4.0 except for the addition of licensing requirements. vBackup version 4.0 is essentially vBackup 0.3.2 with the expiration date removed and licensing components enabled.

To better explain the situation it might help to explain how we got here. All previous releases of Thinware vBackup (pre version 4.0) were released in public beta (provided at no cost) and ran licensed as Professional Edition. You did not get these errors before because the issue was masked by the fact that you were using features available in Professional Edition. Now that you have switched to a Standard Edition license the issues are no longer masked. If you had not used basic compression in vBackup 0.3.2 you would receive the same error.

It is also worth noting that if you were to run vmware-vdiskmanager.exe (part of VDDK) to download a thick provisioned disk to a thick provisioned disk on a network share you will get the same error.

Bottom line, vBackup Standard Edition is designed to work - and it does. It may mot work in every environment or with every possible configuration, but if you are willing to live with a few restrictions, you can continue to use Thinware vBackup for free (and we hope you will).

From our testing we have found that Standard Edition will work as long as you don't have more than one of the following conditions (results may vary):

- Virtual machine has thick provisioned virtual disk(s)
- Virtual machine has thick provisioned virtual disk(s) with large amount of free space
- Backup target is on USB 2.0 (or slower) external hard drive
- Backup target is on network share

We have found that simply changing one of these (if you have two in your environment) will allow the backup process without compression to work without error. For example: if you require the ability to backup to a network share, simply convert the virtual disks on the host server to thin provisioned. Or, if you require thick provisioned virtual disks on your host server, simply configure vBackup to save backups to local (internal or external) storage on the vBackup server.

Note: The same applies if you are running Advanced or Professional Edition and have compression level (in the job's settings) set to none.

The above should not be too restrictive for use with a free product and again we will take the blame for not communicating this out effectively.

Hope this helps.