Get-VBRBackup GetObjects fails with Veeam 12

[stsc_srzc]

Hi Veeam users!

We have a PowerShell Script that has issues with Veeam 12.0.0.1420. The backup.GetObjects() method throws the following exception for some backups (not for all).

Code: Select all

The SQL Server machine hosting the configuration database is currently unavailable. Possible reasons are a network connectivity issue, server reboot, heavy load or hot backup.
Please try again later.

Error:
Unconsciously receiving objects from child backup {c89e149b-26ee-45f0-b730-dfb854eafb6e}

Here is a condensed version of the PowerShell we are using:

Code: Select all

    Write-Host "query backups"
    $backups = Get-VBRBackup
    Write-Host "backup count: "$backups.Count


    foreach ($backup in $backups) { 
        try {
            $objects = $backup.GetObjects()
        }
        catch [System.Exception] {
            $backup

            Write-Host $_
            Write-Host "Error exec backup.GetObjects"
        }
    }

For me this looks like an internal error. Like Veeam is preventing some internal structures from "leaking". Is there any workaround for this issue?


Best wishes
Stefan

[chris.childerhose]

Yes I am seeing this with the program that I am doing a PoC with in this post so to get a fix would be nice. Adding a +1 to here.

[david.domask]

Hey Guys,

Not to be that guy, but this is why it's not a good idea to rely on the internal methods

What specifically are you trying to report on? My guess is that the method changed and if any backups have Child Backups (like Transaction Log ones), it throws a warning.

If you can tell me what you're looking for as output, likely we can find a better way

[david.domask]

Btw, fwiw, you can pass $true as an argument for GetObjects() and it seems to work, but I'm still curious what you're wanting specifically to output; it looks like Job Objects based on the method:

Code: Select all

PS C:\Users\Administrator> $bbackup.GetObjects($true).Name
ddom-tinyvm
ddom-tinyvm_replica
ddom-tinyvm
ddom-tinyvm
ddom-tinyvm
PS C:\Users\Administrator> $bbackup.GetObjects().Name
Exception calling "GetObjects" with "0" argument(s): "The SQL Server machine hosting the configuration database is
currently unavailable. Possible reasons are a network connectivity issue, server reboot, heavy load or hot backup.
Please try again later.
Error:
Unconsciously receiving objects from child backup"
At line:1 char:1
+ $bbackup.GetObjects().Name
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : CSqlException

PS C:\Users\Administrator>

I would suggest if you're wanting Job Objects returned, to move this to supported, call both Get-VBRJob ($jobs) and Get-VBRBackup ($backups) before your loops and save them to some array.

In the loop, fetch the job with $bJob = $jobs |Where-Object {$_.id -eq $backup.JobID}, then pass $bJob to Get-VBRJobObjects.

However, if you're really wanting to keep using the internal methods, understand that this is not supported and likely will break on updates, and just pass $true as the argument for GetObjects(). @chris.childerhose, I suppose for your script probably it's fine temporarily until we understand the goal and how to move it to supported methods, but just prepare it might break again on minor updates until that change is made to supported methods.

(Side-Note: I suspect this might be related to True Per-VM in v12 or upgraded backups to True-PerVM. If you can confirm you see something similar, would just be interesting to know)

[david.domask]

Small update; just confirmed, looks to be by design. (PM team, issue 465881).

So just pass $true, it's the proper solution (and indeed it's about True Per-VM )

[Talom]

Just to give some context here.

We are using the object name to identify the backup file if Per-VM is true. We calculate the physical occupancy per vm
Maybe we could do it with Get-VBRJobObjects, but if the vm is no longer associated to the job but there are some backup files present we couldn't match them with the information from the backup.

[david.domask]

Ah, got it, now I get your concept.

Well, not sure there's a "legit" way to do this then, but it's safe to just pass $true as the argument.

But if your goal is to check if a backup is PerVM or not, there's another (unsupported) method you might enjoy: GetPerVmState()

Code: Select all

PS C:\Users\Administrator> $perjob.GetPerVmState()

PerVmState                                        SplitState
----------                                        ----------
Legacy (JobLvl backup is not TruePerVm container) SingleStorage (SplitState by actual backup)

Would it help your code a bit? I suspect this one will be "safe" to use moving forward.

Edit: Also, do you expect PerJob (non-perVM) chains in your environment? Or the goal is to detect incorrectly configured repositories? Get-VBRRepository should return the PerVM option, and it's default as of v12, so maybe that's better to check if that's your goal. But if you expect there to be mixtures, then of course this won't be super useful.

[Talom]

I think the safest way will be to pass $true and wrap it around a try catch. I'd like to avoid the usage of another unsupported method.

[david.domask]

That should work just fine, and I think it's reasonable.

Btw, if you're willing to share your script, I'd be curious on it and I think the community always loves additional examples. It also can help to understand what is missing and can be made into a properly supported cmdlet.

[stsc_srzc]

Hi David, thank you for all your feedback!

You made me a little nervous with your comment on using internal methods. So I checked the Veeam PowerShell Reference V12. I am not sure where external stops and internal/unsupported starts. The cmdlet Get-VBRBackup is in the documentation so it seems to be external/official. Now when we query the backup objects with these cmdlet are these objects already internal? Or are the methods from these backup objects internal? And if backup objects and their methods are internal how can someone work with these objects and create a supported use of Get-VBRBackup at all?

BTW: We are evaluating to publish the whole script as it is part of our product BACKUP EAGLE www.backup-eagle.com.
What we often hear is the request to report repository amount usages by VM/NAS/Share/Agent. We are able to report by VM/Agent by now but only if PerVM is enabled. And reporting for NAS backups located on Scale Out Repos is driving us crazy So a cmdlet to query these values with a one liner would be a dream.


All the best
Stefan

[david.domask]

Hi @stsc_srzc,

Sure, let me elaborate.

The officially supported endpoints are the cmdlets themselves and the specific _data_ they return. The methods that exist on the objects are .NET internal ones, and these are what do not receive support. Similarly, if you use .NET Reflection (e.g., something like [Veeam.Backup.Core.CBackupSession]::GetAll() ), this is not supported either.

The reason these are not supported is because these are the internal methods used by our RND and they are not maintained/developed for public use, meaning they can and _will_ change frequently on each release. We don't provide public documentation for them since it's a massive undertaking and keeping them consistent and explained for the public would be infeasible. Furthermore, the methods can be invoked _without the normal checks that prevent persons from doing stuff they shouldn't be_, so it's definitely a route you don't want to go. (Note: on occasion, you might receive .NET Reflection code from Support to assist with minor corrections to the Veeam Database; this is approved because it mimics the same DB edit we would do, but saves you the time of backing up the DB, uploading it to Support, and then waiting for a result, but such code should only be used for the specific issue Support has instructed on)

Not supported means just that; you can use them if you're brave, but cases involving unsupported methods for your scripts will be closed as there is no support/research.

Now, that being said, if you're comfortable with digging through the methods and __only use read methods to report on stuff__, probably you're in an okay place, and just will need to deal with the breaking changes like this thread has, and you'll either need to understand what got changed yourself or wait until someone on the forums can advise.

So, we cannot stop you from using them But we also won't be able to offer support via the Technical Support channels for issues with unsupported methods or scripts invoking unsupported methods.

I checked out your site and as I got it, mostly it's just about reporting, so _likely_ you're okay for most things, but again, it would be best to figure out ways of accomplishing the same with the supported endpoints if possible. I know that some areas of the Veeam Platform are needing supported endpoints, and definitely let us know here on the forums about such requests, it's the easiest and best way to register a feature request.

Does that help clarify it?

[stsc_srzc]

Hi David,

thank you for clarifing this. This is really helpful.

We are using read only endpoints and methods only. Reason is that our focus is mainly on reporting and monitoring - management is not our thing. Probably this is why we run into issues very seldom.

Sometimes we need to find a way to fulfil a requirement for specific values. This results then in using some workaround. And as you know nothing lasts longer than a workaround .

We will open a request for query occupancy values with a specific endpoint. This would make things lots easier.

Thank you again and best wishes
Stefan

[david.domask]

Happy to help @stsc_srzc!

And yeah, I suspect that aside from the occasional breaking change, _likely_ you'll be fine, but if there are breaking changes, you'll need to ask here on the forums and wait until someone can find a workaround.

Good luck with the scripts!

[stsc_srzc]

Hi David,

I have posted a feature request for querying occupancy data in: veeam-backup-replication-f2/feature-req ... 85495.html


All the best
Stefan