any ideas are welcome on the following as the case we have with veritas is almost 2 months old without any progress:
if the hyper-v virtual machine has a snapshot which was created from hyper-v or failover console, the backup of the vm fails with status code 13 or 25:
28.09.2020 18:57:27 - Error bpbrm (pid=145214) socket read failed: errno = 104 - Connection reset by peer
28.09.2020 18:57:27 - Error bptm (pid=147427) system call failed - Connection reset by peer (at ../child.c.1289)
28.09.2020 18:57:27 - Error bptm (pid=147427) unable to perform read from client socket, connection may have been broken
28.09.2020 18:57:28 - Error bptm (pid=147293) media manager terminated by parent process
28.09.2020 18:57:33 - Info xxxxx (pid=147293) StorageServer=PureDisk:xxxxxx; Report=PDDO Stats (multi-threaded stream used) for (xxxxx): scanned: 3 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%, cache disabled
28.09.2020 18:57:35 - Error bpbrm (pid=145214) could not send server status message to client
28.09.2020 18:57:37 - Critical bpbrm (pid=145214) unexpected termination of client xxxxxx
28.09.2020 18:57:38 - Info bpbkar (pid=0) done. status: 13: file read failed
28.09.2020 19:00:15 - connecting
28.09.2020 19:00:16 - connected; connect time: 0:00:00
28.09.2020 19:00:22 - begin writing
28.09.2020 19:00:35 - end writing; write time: 0:00:13
file read failed (13)
a workaround is to disable exclude deleted block and swap and paging files but this is not appropriate for us due to negative performance impact
thank you all!
did you try to remove that one existing snapshot and try to re-run a backup?
thanks for the suggestion.
we have production snapshots for production vms and this used to work before end of july.
I expect the functionality to keep working as desired.
please note that we are not talking about a netbackup snapshot.
yes, i have tried removing the snapshot just for the test. the backup worked. but this is not a solution.
I have very sporadic experience with Hyper-V but if you believe NBU behaviour is not correct, I would open a support case.
Since I have significant experience with VMware I thought that its behaviour with snapshots may provide a clue what might have happened with Hyper-V and it looks like it had worked, basically in VMware environment, you can't have snapshots attached to a VM for the snapshot backup to work, this might be well true for Hyper-V as well.
Are all of the VMs in the policies failing, or just a few (ones with snapshot outside of NBU)? Are the VMs being selected via Intelligent Policy (query-based), or manually added to the policy? If it's query-based, I'd try adding one of the problematic VMs to a standalone policy and attempting the backup that way.
Any special network configuration that needs to be considered? VLANs, multiple interfaces, virtual name mismatch for clusters, etc. Status 13 and status 25 are very vague error codes, but they indicate to me that the problem lies between the media server and the Hyper-V host, as I would expect to see status 156 or other snapshot errors if the problem was occurring during snapshotting.
thanks for your hint. there are no limitations of backing up hyper-v vm that has a non-NBU snapshot. other difference from vmware backup is that if there is NBU-snapshot, natbackup has no option to delete it, as it has for vmware policies.
i have a case and since end of july we have no progress with the case.
not all of the vms in the policy are failing, only those vms with a non-NBU snapshot are failing.
manual selection is in use
manually creating other policy and adding a client with non-nbu snapshot still fails the backup.
the snapshot operation gets completed and just after beginning the backup operation the error appears in the job.