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. 

It sounds to me like it does but don’t quote me on that. 😋

I’m still waiting for a reply from support. 24 hours has passed. I think, in someway they will answer else I will try the workaround with the database.

Yeah, best to wait and see since it is best effort support.  Should you not hear, then the other method may work since it is CE edition.

I will ask we leave it as “it performs maintenance tasks” -- it’s quite involved and what is checked exactly will change from update to update as we change / modify / optimize the configuration database. 

Main idea is that the configuration backup / restore is smarter than just copy / pasting SQL rows, it tries to clean up after itself and check to ensure it doesn’t create invalid states (for some situations anyways). It cannot solve every incorrect state for the config DB, but it helps on some issues.

However, I must reiterate and stress: Configuration Restore is not a panacea, and should not be used to troubleshoot issues randomly. Use it when you know that you need to perform a Configuration Restore, or when instructed by Veeam Support (with proper explanation on why you’re doing it)

Reason I am so strict on this is because I know quite a few users here are bloggers and love to share information -- I am glad for this and appreciate your hard work!

But configuration restore has some caveats that depending on your environment you need to plan for, for example:

If you have Scale-out Backup Repository with Capacity Tier, it will be sealed and rescanned

If you have Tape workloads and / or Replicas, they will all be rescanned (tape rescan = catalog)

For small lab environment, not a big deal.

But if you have big amount of data in capacity tier, tons of tapes, or slow link to DR site where replicas live, the sync may take a long time, and this will impact backup operations.

Point is, Configuration Restore itself is good and useful, but you must not use it as a magic cudgel for every issue.

In TC’s case, since it’s community edition I’ve got pretty good idea how big the environment is because of workload limitation, so probably config restore is not a huge deal.

But someone in charge of even moderately sized Veeam environment looking for help instead of Support case and finding blog post that says “hey try config restore that might work!” might be in for a rough day of missed RPOs and inability to do urgent restores, and worse the configuration restore may have been completely useless step.

Excuse my long post, but want to be 100% clear why I’m overly cautious about the statements here.

Similarly eblack, if you suspect your Config DB is bloated, it’s best to open a Support Case to review -- there is already a very good Database Maintenance job built into the backup server since a long time, so there’s really no need to touch it. If you are worried about size of Config DB / some tables, Support Case first before anything.