This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data Protector loses connectivity with the backup server when addressing specific filetypes

Hello,

after months of testing we found that we have issues backing up *.qcow and *.qcow2 files, resulting in a "Connection reset by peer" when the backup process gets there.

Have anyone addressed such an issue or a related one with another filetype-specific file?

Thanks in advance.

  • Hi,

    I have never seen this would have been tested before. The problems must be related to the nature of those files or the way they are used (permanently I assume) by the qemu hypervisor. Maybe you could share the session messages so everyone can understand exactly what the behavior is? I'm not sure this is really supported or there will really be a solution for this problem. But if you share the details, maybe someone has some ideas.


    Koen Verbelen

    Although I am an OpenText employee, I am speaking for myself and not for OpenText.
    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button.
    You may also be interested in my Data Protector Support Tips listed per category

  • hello,

    Which version?

    Would you check connection from this sever to CM?

    re-configutr peer maybe fix he problem.

    regards

  • There is really nothing much in the debug log except the "Connection reset by peer" message. We've spent six months debugging this behavior and found out about these filetypes just recently. If we exclude them from the backup, it's doing well, as expected.

  • Our version is 9.06 and the connection can be made normally. Nothing (so far) seems to solve it btw...

  • Yes, it is clear the problem is with these files. I do not know anythng about the qemu hypervisor. But was it tried to run the backup while the hypervisor was stopped? Or is this what you are doing anyway?

    It may also help if you shared the session report. Seeing the subsequent messages and timing helps to understand the benavior.

    When you're saying there's not much in the debug log, do you mean the debug.log file or have you been looking into full debugs? I do not expect to see any other errors in debugs, but again here this may help to understand the process flow and timings etc. So it may be worth checking full debugs.

    That said, I doubt there's anything that could be done from a DP perspective. But looking at the report and debugs may help to better understand the problem.


    Koen Verbelen

    Although I am an OpenText employee, I am speaking for myself and not for OpenText.
    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button.
    You may also be interested in my Data Protector Support Tips listed per category