Get-VBRTapeJob Slow?

[aaron@ARB]

Hi Veeam,

Is there any way that I can speed up the return speed of the Get-VBRTapeJob powershell cmdlet? When my veeam server (with a physical SQL server backend running the DB) is busy on the full backup days it can take over 45 minutes for this cmdlet to return which i think you will agree, is somewhat excessive.

Are there any indexes that I could add for example that could speed it up?

[sarbaron]

Hi, did you get anywhere with this - I really could do with having a response from the 'get' that takes less than 5 minutes!
Cheers.

[aaron@ARB]

Sadly not.. I logged a call and boiling it down to "it has a LOT to do so when the DB is busy, that's how long its going to take"

I just live with it now unfortunately.

I'm hoping that it may be fixed in v10 along with the other SQL errors that I have reported in relation to the tape engine.

[sarbaron]

That's unfortunate - I have gone down the same path as you - logged a call, at the moment returning results from "measure-command {get-vbrtapejob}, and it's coming back with over 3m 13s...

All I want to do is script a check for Nagios on the state of the tape backups... currently looking to see if I can get it from get-vbrtapebackup - although this comes with the warning "WARNING: This cmdlet is obsolete and no longer supported"...

Cheers

[veremin]

In busy environments execution of Get-VBRTapeJob cmdlet might take some time indeed. Depending on your needs, you can store execution results in hash tables and operate with them - this should speed up the performance. Thanks.

[mzhen]

Try [Veeam.Backup.Core.CBackupJob]::GetAllBackupSyncAndTape() function, it runs much faster. Here is an example on how to retrieve backup size and endtime from a tape job.

Code: Select all

$TapeJob = [Veeam.Backup.Core.CBackupJob]::GetAllBackupSyncAndTape() | Where Name -eq "FileServer1"
$LastSession = $TapeJob.FindLastSession()
$LastSession.EndTime
$LastSession.Info.Progress.TotalUsedSize
$LastSession.Info.Progress.ReadSize
$LastSession.Info.Progress.TransferedSize

[veremin]

It might work faster indeed, but keep in mind that this script uses the undocumented and unsupported method (which loads an assembly), meaning there is no guarantee the script will work in the next product version. Thanks!

[mzhen]

Get-VBRTapeJob hung if I don't use the -Name filter, it took over 15 minutes if I want to filter jobs like -Name "*Daily*". The reason this cmdlet took so long to finish is because it returns all the results of the backup jobs. You need to filter them out if for example you want backup done in last 24 hours. This cmdlet has been around since 2014 as far as I can tell. We're on Veeam 9.5 Update 4. It's almost 2020 and we're still experiencing this issue....
The assembly functions are much faster because they only return the last backup job apparently
Here are more assembly functions people may be interested in.

Code: Select all

[Veeam.Backup.Core.CBackupJob]::GetAllBackupSyncAndTape() | Select Name | Sort Name ## List all VM to Tape jobs, except File to Tape. It's FAST!!!
[Veeam.Backup.Core.CBackupJob]::GetAfterThisScheduleable() | Select Name | Sort Name ## List all "File Copy", Replications, VM, VM to Tape backups except File to Tape jobs
[Veeam.Backup.Core.CBackupJob]::GetByType("FileTapeBackup") | Select Name | Sort Name ## List all File to Tape jobs
[Veeam.Backup.Core.CBackupJob]::GetByType("VmTapeBackup") | Select Name | Sort Name ## List all VM to Tape jobs
[Veeam.Backup.Core.CBackupJob]::GetByType("Backup") | Select Name | Sort Name ## List all VM backups
[Veeam.Backup.Core.CBackupJob]::GetByType("Copy") | Select Name | Sort Name ## List all "File Copy" jobs
[Veeam.Backup.Core.CBackupJob]::GetByType("Replica") | Select Name | Sort Name ## List all Replication jobs

[veremin]

It doesn't return job results, it returns jobs itself.

However, if in your environment it takes 15 minutes for cmdlet to run, kindly, open a ticket with our support team and post its number here, so that, we can investigate the issue internally.

Thanks!

[mzhen]

Since Veeam 11, [Veeam.Backup.Core.CBackupJob]::Get*() functions no longer work! May be deprecated...pity

[veremin]

When you're using internal classes in PowerShell scripts, it's always a trade-off: you get what you want, but if internal structure changes, previous script breaks.

Can you tell us what exact information you were getting through assembly load? If it's just getting jobs based on their types, there are plenty of other ways to do that.

Thanks!

[oleg.feoktistov]

@mzhen, are you sure all Get*() methods don't work? Because I use most of them regularly in my lab and since upgrade to v11 GA nothing broke. Maybe you were referring to particular ones? Thanks!

[mzhen]

@veremin, @oleg.feoktistov
Thanks for your prompt reply and my apologies guys. I didn't receive your replied even I've subscribed the the this topic, may be filtered by my webmail service.
They're still working fine. I've been using the VeeamPSSnapIn before v11 and didn't notice it had been removed since v11 due to I suppressed the errors like below. I'm using point 2 below to import the module. It's been working fine and better than the Snapin in some ways
1) Add-PSSnapin -Name VeeamPSSnapIn -ErrorAction SilentlyContinue
2) Import-Module Veeam.Backup.PowerShell

Get-VBRJob method do work, but Get-VBRTapeJob hung for some reason. They're much slower compare to [Veeam.Backup.Core.CBackupJob]::Get*()

[oleg.feoktistov]

Hi Marcus,

I'm not sure why Get-VBRTapeJob could hang. How many tape jobs do you have? Did you notice if cmdlet execution time is server load related?
It never took much time to return jobs neither with Get-VBRTapeJob nor with Get-VBRJob in my environment. It returned them almost instantaneously even though I had a bunch of them. I would suggest opening a support case as it looks as an environment-related issue to me.

Thanks,
Oleg

[mzhen]

We have over 160 Veeam Jobs include the following 7 backup types. I use the bottom 2 assembly functions in a scheduled task to fetch all the jobs and send an HTML report to our team. The schedule task only take less than 2 seconds to run in the morning e.g 8am when the Veeam jobs have finished running. There is very little load on the server after 8am. Running Get-VBRJob after 8am alone took over 7 seconds not to mention Get-VBRTapeJob hung since Veeam 8. May be it's only happens to our environment since I haven't seen people reporting this, but I'm ok with it since I have found these assembly functions as a workaround which work a lot better. Thanks for following this up again.

1) NasBackup
2) EpAgentBackup
3) VmTapeBackup
4) FileTapeBackup
5) Copy
6) Replica
7) Backup

Internal Classes
[Veeam.Backup.Core.CBackupJob]::GetAfterThisScheduleable()
[Veeam.Backup.Core.CBackupJob]::GetByType("FileTapeBackup")

[oleg.feoktistov]

Sure, just remember that internal classes and methods are not supported. Their definition can change from release to release.
So, if you will feel stuck with Get-VBRTapeJob cmdlet, feel free to contact our support as I do think that it has to do something with the environment.
Thanks!