I was wondering if anyone came across this issue as I find it very strange as to why the target machine our proxy is involve in the post-backup application-aware processing as from my understand the proxy is just a data mover and is not involve in anything else. This just start happening along with the timeout issue that we are having with veeam.
Processing XXXXX Error: VSSControl: Failed to prepare guest for freeze, wait timeout 1800 sec
Failed to perform post-backup application-aware processing steps Details: Failed to call RPC function 'Vss.FinishSnapshot': The remote procedure call was cancelled. RPC function call failed. Function name: [DoRpc]. Target machine: [XXXXXXX].
Unable to truncate Microsoft SQL Server transaction logs. Details: Failed to call RPC function 'Vss.TruncateSqlLogs': The remote procedure call was cancelled. RPC function call failed. Function name: [DoRpc]. Target machine: [XXXXXXX].
I do have a support case that is related to this Case # 02215466.
Could you please clarify your request? The post-backup in this case is the last stage of application-aware processing occurred inside the guest OS, not something that occurs after the backup job itself. And the proxy is the component that retrieves VM data from the storage, processes it and then sends to the target repository. Or are you saying that the target machine here: Target machine: [XXXXXXX] - is the proxy server VM itself?
It could help to jump into the affected VM itself and double check Windows event logs. Most of these VSS problems are caused by the VSS writer inside the virtual machine itself.
Basically what I wanted to know and confirm was that the post-backup should only involve the Guest OS and not the proxy itself. Therefore, as I had noted with the support tech whom I was working with was that the target machine should not be noting our physical proxy, as it would not be involve with truncating the SQL transaction logs as its main function is being a data mover. Therefore, I wanted to find out to why we were getting those warning message as shown above which had mention the target machine being our physical server.
Furthermore, I was hoping perhaps someone has seen something like this before or have come across this issue that may provide some insight to as why this occurring.
So far the support tech has only recommend increasing the timeout duration of the job for VSS, but I am still getting the unable to truncate Microsoft SQL Server transaction logs.
Seeing the proxy server name in this message is somewhat unexpected, especially provided it is a physical machine. The message should indeed mention backed up VM name, so I recommend asking for a closer investigation.