Wednesday, May 22, 2024
Thinware Forums
 
ForumsForumsThinware vBacku...Thinware vBacku...DiscussionsDiscussions[NFC ERROR] when trying to backup[NFC ERROR] when trying to backup
Previous Previous
 
Next Next
New Post
 6/12/2014 10:44 AM
 
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
New Post
 6/12/2014 11:33 AM
 

gianpyc:

We understand that after 4 years of beta many of our users got used to having all features provided at no cost and we apologize for any confusion this may have caused. We ran such a long beta because we wanted to help and we wanted to get as much feedback as possible in an effort to produce a software package that does what our users need it to.

Some environments and configurations will require compression for backups to function properly. Some environments and configurations will work fine without compression.

Thinware vBackup Standard Edition works great for a lot of organizations and it can work for yours as well. If you are willing to make some minor changes to your environment and how it is configured we can help you get Standard Edition working.

Please feel free to contact our support team at support[at]thinware[dot]net if you would like assistance in getting Standard Edition working in your environment.

New Post
 6/12/2014 1:24 PM
 
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
New Post
 6/13/2014 7:41 AM
 
Yes,

I have to confirm what Mike said about vBackup that, indeed, is a great product and allows us to backup our servers basically for free or low effort in our side. However, what sounds strange to is the fact that this error basically has not a solution except connecting the disk directly to the computer. For me it's fine to have the free version without compression but I don't like that my backups fail for a strange reason. What I have understood from my trials is that the result depends on the VM size. In fact, without compression 20Gbyte the backup is properly run, with 100Gbyte of VM the backup fails.

I tried with this workaround, but without success:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2038497

I think that I'll contact your support soon

Thanks
New Post
 6/13/2014 1:47 PM
 
 Modified By vBackup Team  on 6/13/2014 1:32:23 PM

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.

Previous Previous
 
Next Next
ForumsForumsThinware vBacku...Thinware vBacku...DiscussionsDiscussions[NFC ERROR] when trying to backup[NFC ERROR] when trying to backup

Thinware Community
Membership Membership:
Latest New User Latest: haihd4
New Today New Today: 0
New Yesterday New Yesterday: 0
User Count Overall: 41208

People Online People Online:
Visitors Visitors: 25
Members Members: 0
Total Total: 25

Privacy Statement  |  Terms Of Use
Copyright 2007-2019 Thinware, Inc.