I am novice,
Now for NBU backup virtual machine, some clients often found 11 error () system call failure or 13 error (file read failure)

Features are: the backup to part, backup failure, such as 400 g of virtual machine backup to show this information when I was 200 g,

In general, is the problem of insufficient space? Or virtual space problem? What specific recommend adjustment way,

The case, according to the following information:

1. VXMS log shows that every time we backed up to the amount of data size will interrupt reason is: the host only backup yzbbxt - db. Every time VMDK disk, and disk yzbbxt - db_1. VMDK trying to read 3 times dropped out after failure, namely yzbbxt - db_1. Read VMDK disk is not normal,
The log is as follows:
The Begin: vfm_read/19:02:39. 0393:
In: nreq=1
Vfm_obj_t {orig_name=[HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db. VMDK}

The I/O the Req
Vfm_io_req_t {offset=214748270080 65536 bytes_trans reqlen==0 bytes_req=0 error=0}

Out:

The I/O the Req
Vfm_io_req_t {offset=214748270080 65536 bytes_trans reqlen==65536 bytes_req=0 error=0} - 214748270080 is to read the amount of data, increase of the

End: (0)

The Begin: vfm_read/19:02:39. 0395:
In: nreq=1
Vfm_obj_t {orig_name=[HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db. VMDK}

The I/O the Req
Vfm_io_req_t {offset=214748335616 29184 bytes_trans reqlen==0 bytes_req=0 error=0}

Out:

The I/O the Req
Vfm_io_req_t {offset=214748335616 29184 bytes_trans reqlen==29184 bytes_req=0 error=0}

End: (0)

The Begin: vfm_close [19:02:39. 0397:] - close reading
In: vfm_obj_t {orig_name=[HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db. VMDK} - it was done this disk read tag

End: (0) - normal return

The Begin: vfm_open_file_name/19:02:39. 0431:
In: filename=& lt; Vix> [HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db_1. VMDK - began to read the next piece of plate
Flags=2
The context=

Out:
Rflags=0
Vfm_obj_t {orig_name=[HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db_1. VMDK}

End: (0)

The Begin: vfm_read/19:02:39. 0432:
In: nreq=1
Vfm_obj_t {orig_name=[HDS_HUS_LUN1_2TB] yzbbxt - db/yzbbxt - db_1. VMDK}

The I/O the Req
Vfm_io_req_t {offset=0 35328 bytes_trans reqlen==0 bytes_req=0 error=0} - didn't read the data, returning 11 error, this operation tried three times have failed,

End: (11)

2. Bpbkar log records with clear reading three failed in
19:03:02. 806: [1604.568] <2> Tar_base: : V_vTarMsgW: three - Read of VM file Read 0 bytes, should have Read 35328 bytes, will be issuing retry 1 of 3 (../flashmap. CPP: 2006)
19:03:03. 806: [1604.568] <2> Tar_base: : V_vTarMsgW: three - VxMS Error message 1=fiml_read_file vfm_read
11 the req message 2=stat. Io_error 0 (../vxms_bridge. CPP, 320) - bkbkar 11 error log files are read times,
19:03:03. 806: [1604.568] <2> Tar_base: : V_vTarMsgW: three - Read of VM file Read 0 bytes, should have Read 35328 bytes, will be issuing retry 2 of 3 (../flashmap. CPP: 2006)
.
19:03:04. 807: [1604.568] <2> Tar_base: : V_vTarMsgW: three - Read of VM file Read 0 bytes, should have Read 35328 bytes, will be issuing retry 3 of 3 (../flashmap. CPP: 2006)

The following for the ESX server logs:

1. The ESX server you have jet lag time and Beijing time, but the time difference is a problem within a day not
2. Vpxa log for the update of disk, I gave you the following 2 log contrast, clearly show that opid exit if normally update will return to normal, but opid SWI - 9 e91f12e had been updated in the past, please check,

Normal log, will soon update:
The 2016-09-14 T06:37:07. 128 z [550 c7b70 verbose 'VpxaHalCnxHostagent opID=f9690 WFU - 91] [WaitForUpdatesDone] Received callback
The 2016-09-14 T06:37:07. 128 z [550 c7b70 verbose 'VpxaHalCnxHostagent opID=WFU - 91 f9690] [VpxaHalCnxHostagent: : ProcessUpdate] Applying updates from 5434414 to 5434415 (at 5434414)
The 2016-09-14 T06:37:07. 128 z [550 c7b70 verbose 'hostdvm opID=WFU - 91 f9690] [VpxaHalVmHostagent] 34: GuestInfo changed' guest. Disk '
The 2016-09-14 T06:37:07. 129 z [550 c7b70 verbose 'halservices opID=f9690 WFU - 91] [VpxaHalServices] VmGuestDiskChange Event for the vm (40) 34
The 2016-09-14 T06:37:07. 129 z [550 c7b70 verbose 'vpxavpxaInvtVm opID=f9690 WFU - 91] [VpxaInvtVmChangeListener] Guest DiskInfo Changed
The 2016-09-14 T06:37:07. 129 z [550 c7b70 verbose 'VpxaHalCnxHostagent opID=f9690 WFU - 91] [WaitForUpdatesDone] Starting next WaitForUpdates () call to hostd
The 2016-09-14 T06:37:07. 129 z [550 c7b70 verbose 'VpxaHalCnxHostagent opID=f9690 WFU - 91] [WaitForUpdatesDone] Completed callback

OpID=SWI - 9 e91f12e update is not successful, (you have to find this opID vmware to do, I only know this opID update failure),
The 2016-09-14 T06: afterward. 181 z [FFB03B70 verbose 'vpxavpxaMoVm opID=SWI - 9 e91f12e] [VpxaMoVm: : CheckMoVm] did not find a VM with ID 59 in the vmList
The 2016-09-14 T06: afterward. 181 z [FFB03B70 verbose 'vpxavpxaAlarm opID=SWI - 9 e91f12e] [VpxaAlarm] VM with vmid=59 not found
The 2016-09-14 T06:46:36. 183 z [FFB03B70 verbose 'vpxavpxaMoVm opID=SWI - 9 e91f12e] [VpxaMoVm: : CheckMoVm] did not find a VM with ID 59 in the vmList
The 2016-09-14 T06:46:36. 183 z [FFB03B70 verbose 'vpxavpxaAlarm opID=SWI - 9 e91f12e] [VpxaAlarm] VM with vmid=59 not found

3. Hostd. The log log on this disk yzbbxt - db_1. VMDK has error, please find vmware to analysis,
The 2016-09-14 T03: when. 003 z [2 a681b70 verbose 'Default' opID=69 c6fd79 - a9 user=vpxuser] AdapterServer: target='vim. VirtualMachine: 37', method='queryChangedDiskAreas'
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnull