Get-VBRComputerBackupJob does not list all job types

[potemkin]

Dear all,

I'm working on backup jobs infos retrieval on Veeam Backup & Replication 10
Reading the doc, I've noticed Get-VBRJob has become deprecated, and that we shall use Get-VBRComputerBackupJob instead.

My point is that Get-VBRJob still shows job typs that are not shown by Get-VBRComputerBackupJob :
File Backup
File Copy

This looks an issue to me, as it forces me to continue using deprecated Get-VBRJob.

Is there a command that I've missed and that could help fetching 100% of job types ?

Thank you for your help.

Support case ID: 04745648

[jhoughes]

It is intended to say that you should use 'Get-VBRComputerBackupJob' instead of 'Get-VBRJob' for agent jobs.

For all other jobs, you'd still use Get-VBRJob. You can run 'Get-VBRJob -WarningAction SilentlyContinue' if you don't want to see the message.

[potemkin]

Thank you Joe,

I'll go for that then! (was afraid this Get-VBRJob could stop working on a future update)

Regards

[oleg.feoktistov]

For Get-VBRJob it's still a long away ahead to a full deprecation.
Not all job types have their sets of cmdlets, but we are working on that.
Thanks!

[ratkinsonuk]

Hi Oleg. I'm coding some reports that scan through the backup jobs using GET-VBRJob, and see the same warning.

My problem is, how can we tell what Get-VBRComputerBackupJob looks like programatically. I.E. are there any major differences in the methods and properties, or can we just run both cmdlets separately and then append the objects together for further processing? Presumably, the fact that the developers are trying to separate the two means that they will start to fork from each other at some point?

As you've stated, it's not going to happen overnight, so we have time to work through our scripts once the ultimate direction is clear.

Cheers, Rob.

[oleg.feoktistov]

Hi Robert,

As you might know, with Get-VBRJob we can retrieve all job types through a single model of CBackupJob core class. As a result, properties and methods, which are used in different job types, are all residing together and some get rendered to default values if the property/method purpose doesn't match a job type of the instance object we obtain. With new class-cmdlet pairs for each job type (like in VBRComputerBackupJob/Get-VBRComputerBackupJob) we keep only job-specific properties and lose methods as it is considered not safe to modify data with them.
Beside that, in CBackupJob class instances we can use .NET reflections to set some properties directly, which was fully replaced with a more safe approach, that is, an enhanced list of parameters in new job cmdlets. Hence, if we are talking about Get-VBRJob vs. Get-VBRComputerBackupJob (+ other new job cmdlets and classes) difference, it is crucial in terms of logic and structure. And though some properties across these classes can look alike, they will definitely hold distinct types. So, I wouldn't say that appending such entities together as they are and considering them structurally equal is a good idea unless you use some of their properties to serialize each object to something custom. In my test scripts that's what I usually do if I want to get some general report on all job types: compose custom model for a job object, search for relevant properties across CBackupJob, VBRComputerBackupJob, VBRNASBackupJob etc. classes and create custom object accordingly.

Thanks,
Oleg