Case #07670784 has been going on for a while now with no progress so far, so I figured maybe I'll try my luck here. Currently on 12.3.2.3617 on Server 2022 not doing anything else besides VBR
Since upgrading to 12.3.1.1139 we had the problem that our VBR VM deadlocks on Health-Check/Offload desprite having a dedicated machine used for S3 communication. Everything worked as it should before using 12.3.0.310, the dedicated host was used for S3 and no deadlocks occured. We are dealing with this ticket a few weeks now and it's not going anywhere. We did a re-install of VBR since "maybe it's an upgrade problem" - still exists. Did several re-configurations, problem still exists. For us it's looks more like a "let's see what else we can blame this on" approach currently since the fact that we said several times to please take a look at the logs after the resets to see if ANYTHING veeam tasks-wise started after the service did start it's ignored.
I did hard-reset the VM on saturday, as soon as the veeam services were up the machine froze again. Hard-reset. As soon as the veeam services were up... deadlock. Hard-Reset. Than everything went back to normal.
It's a bit frustrating and seriously affecting our backup cycle if the VBR keeps on deadlocking on itself. Even with 32 Cores the machine deadlocks itself with 100% cpu usage - seems like no matter how many cpu cores are thrown at it it eats all of them. We're not sure wether it's the local health check or the S3 health check (which is not using the dedicated VM for S3 communcation at all).
Help, maybe?
Thanks!
Since upgrading to 12.3.1.1139 we had the problem that our VBR VM deadlocks on Health-Check/Offload desprite having a dedicated machine used for S3 communication. Everything worked as it should before using 12.3.0.310, the dedicated host was used for S3 and no deadlocks occured. We are dealing with this ticket a few weeks now and it's not going anywhere. We did a re-install of VBR since "maybe it's an upgrade problem" - still exists. Did several re-configurations, problem still exists. For us it's looks more like a "let's see what else we can blame this on" approach currently since the fact that we said several times to please take a look at the logs after the resets to see if ANYTHING veeam tasks-wise started after the service did start it's ignored.
I did hard-reset the VM on saturday, as soon as the veeam services were up the machine froze again. Hard-reset. As soon as the veeam services were up... deadlock. Hard-Reset. Than everything went back to normal.
It's a bit frustrating and seriously affecting our backup cycle if the VBR keeps on deadlocking on itself. Even with 32 Cores the machine deadlocks itself with 100% cpu usage - seems like no matter how many cpu cores are thrown at it it eats all of them. We're not sure wether it's the local health check or the S3 health check (which is not using the dedicated VM for S3 communcation at all).
Help, maybe?
Thanks!
Statistics: Posted by ASG — Jul 04, 2025 5:34 am
