Set-VBRJobOptions not supported for Backup-copy jobs

[maanlicht]

In version 11a I succeeded in having powershell scripts configure all settings of our backup-copy jobs but it seems some significant design changes have been made in v12.

In v11 we used to do something like this:

Code: Select all

$job = Get-VBRJob -name 'Backup copy jobname'
$options = Get-VBRJobOptions -Job $job
$options.GenerationPolicy.EnableDeletedVmDataRetention = $true
$options.GenerationPolicy.DeletedVmsDataRetentionPeriodDays = 30
$options.GenerationPolicy.EnableCompactFull = $true
Set-VBRJobOptions -Job $job -Options $options

However in V12 it returns the error stating that the these objects are now ‘Read-only’ and that and that 'Set-VBRJobOptions' is no longer supported and I should use the ‘Set-VBRBackupCopyJob’ command instead. However, on the support page of the ‘Set-VBRBackupCopyJob’ command there only seems to be a limited set of settings I can control for Backup-copyjobs.

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

My question is: How can the following settings be controlled trough PowerShell?

1. ‘Remove deleted items after’
2. ‘Defragment and compact full backup file’

PS: I opened a support case. Case #05993827

[david.domask]

Heya @maanlicht will ask around and see if this indeed is just a part that needs to be further fleshed out now that the new Backup Copies have their own cmdlet sets.

As a workaround for now, you can use the CBackupJob object returned by Get-VBRJob; it has a property Options which holds the same as Get-VBRJobOptions (you will find the GenerationPolicy property there) and set the options there.

Then the CBackupJob object has an internal method Update(), which should push the change.

Please note that the .NET Methods/Reflection are not supported but this should be pretty safe I think until we figure out the intended way.

[maanlicht]

Yes that did it! Thank you so much!

So for anybody in the future running into the same thing. The following code snippet worked for me:

Code: Select all

$job = Get-VBRJob -name 'jobname'
$job.Options.GenerationPolicy.EnableDeletedVmDataRetention = $true
$job.Options.GenerationPolicy.DeletedVmsDataRetentionPeriodDays = 27
$job.Options.GenerationPolicy.EnableCompactFull = $true
$job.update()

[david.domask]

@maanlicht, glad to hear it

I checked internally and looks like it's a known limitation right now with the introduction of the new dedicated BCJ cmdlets (for PM team, tracked on issue 484870), so my guess is that it's coming back, but no specific release vehicle is chosen yet.

For now I think it should be fine with the workaround.

[xasz]

Just wanted to let you know that this helped alot.
I came across the same issue and found your thread.

Thanks for posting an answer.
However it is really not good practices reducing to reduce the range of functions with new cmdlets.

[xasz]

*Not sure why, but sometimes it does not work.
For Example:

Code: Select all

 
        $vbrjob = Get-VBRJob -name $cloudJob.name
        $vbrjob.Options.GenerationPolicy.EnableDeletedVmDataRetention = $true
        $vbrjob.Options.GenerationPolicy.DeletedVmsDataRetentionPeriodDays = 30
        $vbrjob.update()
 

Will throw:

Code: Select all

        Ausnahme beim Aufrufen von "Update" mit 0 Argument(en):  "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."
        In Zeile:1 Zeichen:1
        + $vbrjob.update()
        + ~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : NullReferenceException

For now i am not sure why and when but it does happen. Here is a code i can reproduce it every time:

Code: Select all

    $source = Get-VbrJob -Name "BackupVM"
    $target = Get-VBRBackupRepository | Where-Object {$_.Type -eq "Cloud"}
    $key = Get-VBREncryptionKey | Select-Object -First 1

    $storageOptionsParams = @{
        CompressionLevel = "Auto"
        StorageOptimizationType = "Automatic"
        EnableEncryption = $true 
        EncryptionKey = $key
        EnableDataDeduplication = $true
    }

    $params = @{
        Name = "TestJob" 
        Description = "Test $(Get-Date -Format "dd.MM.yyyy")" 
        DirectOperation = $true 
        Mode = "Immediate" 
        BackupJob = $source 
        TargetRepository = $target
        StorageOptions = New-VBRBackupCopyJobStorageOptions @storageOptionsParams
        RetentionNumber = 30
        RetentionType = "RestoreDays"
    }
    $job = Add-VBRBackupCopyJob @params
    
    $vbrjob = Get-VBRJob -name $job.name
    $vbrjob.Options.GenerationPolicy.EnableDeletedVmDataRetention = $true
    $vbrjob.Options.GenerationPolicy.DeletedVmsDataRetentionPeriodDays = 30
    $vbrjob.update()

It will throw on update() but it will set the options.

Any ideas ?

[david.domask]

Heya @xasz,

Just to confirm, it's only with jobs targeting a Cloud Connect repository, is this correct?
Also you write it gets "set" but it throws an error, correct? So it's working, just an ugly error?

Keep in mind, this is an unofficial workaround, so not sure how deep we should dive into this. If it's just making the ugly errors but otherwise working correctly, probably it's fine, but it might be best on jobs targeting a Cloud Connect repo to just set it from the UI until the cmdlets are further established to allow this with the new BackupCopy cmdlets.

[xasz]

@david.domask I have double and tribble checked and for now it appears to be someone random to me.
I have changed the target for example to:

Code: Select all

$target = Get-VBRBackupRepository | Where-Object {$_.Type -eq "CifsShare"} | Where-Object {$_.Name -like "*Zweite*"}

And first it appeared that it only happens on cloud targets, but then it happens a couple of times on a cifsshare.
I have not figured out what it is, that is triggering the problem.