VBR - Stalled Backup jobs

What if you disable the jobs and then reboot the server to see?  After that, if they are not running, enable them again.  If the issue comes back, would suggest a support ticket for them to troubleshoot the issue.

​@Edy - I’ve not seen anyone post about this behavior here on the Community Hub. Maybe someone has had this happen to them after a VBR migration and can comment. Otherwise your best bet, & my recommendation, is to submit a Support ticket. My guess is something got “stale” in the VBR database during the migration and maybe some DB change needs to be made. And really only Support should mess with the VBR DB. 

Best.

My first thought is stale job session, possibly in the config DB after updates. You may have some luck with PowerShell vs the GUI. - Get-VBRJob -Name "Your Job Name" | Stop-VBRJob -Confirm:$false 

Otherwise what others have said makes sense. Disable jobs, reboot. Re-enable after start if the stale sessions are gone. 

Thanks for the fast replies to everyone. In Powershell all jobs are in stopped state and everything looks fine. Just the GUI still shows them even they are disabled now and I rebooted the server.

This is an NFR license and I don’t think to received support.

​@Edy - yeah..that’s why I suggested probably best to get ahold of Support. The error you showed in your screenshot shows the Job is stopped, but the GUI is showing something different. Honestly, I think Support is your only route.

Do I get support with NFR? I thought it’s only community while I’m here. 

Yes, kind of. You can open a Support Case and will get treated the same as you would as using the VBR Community Edition → it’s “best effort” Support. Below discusses Veeam’s Support Policy:

https://www.veeam.com/legal/support-policy.html

Thank you to all - I was able to open a support case. For the product I selected the VBR community edition. 

Great.  Let us know how it goes and hopefully you get a resolution.

Ok, keep us posted ​@Edy 

​@Edy , let’s hope Support has bandwidth for an NFR case -- the issue is a problem in the configuration database, that particular job session likely didn’t get closed out correctly, and usually requires manual intervention. This is purely an aesthetic matter, no processing is actually happening for the job, the session just was never told to stop so the counter continues to increment.

For your case in particular, if Support doesn’t have the bandwidth to take an NFR case, you can try the following:

1. Take a fresh configuration backup
2. Stop all jobs and tasks
3. Start a Configuration Restore from the configuration backup you made in step 1

The Configuration Restore has some clean-up activities for situations like this and you might be able to resolve it.

IMPORTANT: This is not a solution for a production server, as Configuration Restore has quite a few considerations -- it is not destructive, but it will interrupt backup operations, potentially for quite a long time. For a production backup server, a Support Case is a must.

Hi - Thanks for taking time to respond. I’m waiting for support and now I know it is a cosmetic thing (not nice thought) but I see the backup jobs are still running fine.

If I don’t hear from support, I will try your solution.

Thanks!

Keep us posted ​@Edy 

That is an interesting solution did not realize you could use configuration backup to resolve it.  Hope support helps you out.

Does this process clean up tables? I might have to explore this idea.