Get running jobs

[Henrik.Grevelund]

Hi

Anyone found a way to list/count the active running jobs ?

Where all types of jobs are listed, just like the view in the console, including Agents, translog jobs, SAP-, oracle-plugins, SOBR tiering and all others.

Is there a SQL view, or some un-documented .net method, anything ?

[soncscy]

Hi Henrik,

Jobs have an IsRunning property, so you can just do Get-VBRJob and check that.

For Transaction Log Backups though you'd have to go into unsupported methods. I dug around a bit and found the following:

Code: Select all

[Veeam.Backup.Core.CBaseSession]::GetRunning()

You'll need to filter out some of course like the infrastructure tasks (storage discovery, etc).

Also Backup Copy Jobs are always "running", so you might want to filter on "Idle" also.

I don't have active SAP/Oracle plugin jobs to test with, but maybe you can confirm if this works for you.

[Henrik.Grevelund]

Hi Harvey,

Thanks, that was exactly what i was looking for.
I can confirm that it lists both SAP and oracle jobs.

It could be great if the .net calls could get documented, it has a lot of great functions not possible in the powershell commands.

[oleg.feoktistov]

Hi Henrik,

We document only the ways we support. Change rate of internal .NET classes and methods is too high to get them maintained and documented properly. We would need to spend much more time just on that, ruling out other cool and highly demanded features. Besides, they are too unstable to guarantee that they'll work as expected.

Thanks,
Oleg

[soncscy]

To add to this, as elitist as this might sound, if you don't know how to find the .NET methods on your own, you probably shouldn't be using them in general unless someone has vetted them

I know exactly how I sound but hear me out please; exposing .NET methods via reflections is kind of a risky venture. It's extremely powerful, but it's also basically unmitigated in every single way, and you bypass a lot of checks that are put in to ensure consistency in the program and other places.

Something like the above I feel isn't too bad because it's just polling and returning data, but it does introduce some danger as you end up with objects and exposed properties that were never meant to be exposed independently.

You personally are likely responsible and just want some good reports, but suppose there was a full list of the .NET classes/methods exposed and some not so careful persons end up borking their entire environment. Caveat Emptor only goes so far!

I think it's better to just point out what reporting you're missing or which cmdlets don't match your needs, and let there be an official endpoint instead. Trust me, while we occasionally touch on such methods with my team when writing scripts for clients, we try to avoid it because it's a ton of maintenance and a lot of panicky calls at awkward hours.

[Henrik.Grevelund]

Hi,

@Oleg, if they are that unstable i hope that you don't use them internally

@Harvey, no need for such a disclamer, i know the .net calls are unsupported.
There are several old posts on this forum regarding the same issue, finding active/running jobs.

My end goal is to stop everything in veeam a clean way with a script. This will allow us to automatically patch the server.
At this time i don't see any other way than using unsupported calls.

[oleg.feoktistov]

Henrik,

Just to clarify, by unstable I meant solely that their outcome is hard to predict from customer's perspective due to the high rate of changes in their internal implementation Developers change some of them whenever needed to support features and business logic amendments/additions. Shouldn't affect most of Powershell cmdlets though, as their implementations are fixed. That's why we recommend to use them instead.

Thanks,
Oleg