How to change OperationalRestorePeriod on SOBR

[Dagr]

I am working on a script that will gradually change our on-prem stored data, by changing when data will be moved to our capacity tier.
I can get the OperationalRestorePeriod on our SOBR by running:

Code: Select all

$repository = Get-VBRBackupRepository -Name "ScaleoutRepo_Name" -ScaleOut

But if at try to set this parameter with the following:

Code: Select all

Set-VBRScaleOutBackupRepository –Repository $repository -OperationalRestorePeriod "301"

I get the error:
Set-VBRScaleOutBackupRepository : Specify at least one extent

How can i change the "OperationalRestorePeriod" parameter?

[david.domask]

@Dagr, it's a bit strange for me, but the reason is that Set-VBRScaleoutBackupRepository requires the -Extent parameter, which has some really spooky language regarding _replacing_ extents.

Feeding it the array of existing extents (extents are a VBRScaleOutBackupRepository property, so in your case, you'd use $repository.extents) satisfies this, but I'm a bit curious as to whether there are some "big" issues with this.

A quick test in lab and this worked without incident on a test scale out repo with just a single backup

Code: Select all

PS C:\Users\Administrator> $repo = Get-VBRBackupRepository -name 'temp-sobr-ps-testing-ddom-rb3' -ScaleOut
PS C:\Users\Administrator> $repo
PolicyType                    : DataLocality
Extent                        : {temp-repo}
...
OperationalRestorePeriod      : 14
...
CapacityTierMovePolicyEnabled : True
...
Id                            : 6d2e339e-225f-4b8c-9d3a-064188ffa502
Name                          : temp-sobr-ps-testing-ddom-rb3
Description                   : Created by DDOM-VEEAM-RB3\Administrator at 4/3/2022 9:43 AM.

PS C:\Users\Administrator> Set-VBRScaleOutBackupRepository -Repository $repo -OperationalRestorePeriod 99 -Extent $repo.Extent
PS C:\Users\Administrator> $repo = Get-VBRBackupRepository -name 'temp-sobr-ps-testing-ddom-rb3' -ScaleOut
PS C:\Users\Administrator> $repo.OperationalRestorePeriod
99

Incremental was fine, and checking the logs, I actually don't see the spookiness the User Guide warns about Let me check a bit more in my lab before you test in prod And maybe @oleg.feoktistov can comment on the intent if he knows it.

But I think this might just be some documentation strangeness.

[Dagr]

@david.domask

My guess is you are thinking of this, as the spooky part:

IMPORTANT! The cmdlet will replace the extents currently added to the scale-out backup repository with this array.

I agree that it indeed sounds spooky, and might need clarification in the guide. But I do understand it, even though the wording leaves a lot of questions. It should just have given an example that explains it a bit better.
But it do makes sense. If you have a SOBR with Extent-01,Extent-02 & Extent-03 and then use:

Code: Select all

Set-VBRScaleOutBackupRepository -Repository $repo -Extent "Extent-01,Extent-02"

This wil set the SOBR to only contain Extent-01 & Extent-02, leaving Extent-03 out of the SOBR.

But in my mind, it should not even have been needed to specify the extents, when it is global parameter you set. I should in a perfect world just have been:

Code: Select all

Get-VBRScaleOutBackupRepository -Repository $repo |Set-VBRScaleOutBackupRepository -OperationalRestorePeriod 99 

[david.domask]

Well, I don't disagree However, our team are pretty smart people, and maybe there's some reason that's not as clear. Again, perhaps Oleg can comment, else I can try to pursue a bit internally.

The process (after I tested last night) does actually seem pretty benign. I don't see a lot of harm as long as you just pass an array of the current extents from the ScaleOut object to the cmdlet, but I must admit I agree with you and don't quite get why we need to do this to change a property on the Capacity Tier extent. Not saying there's no reason, just it's not clear to me.

[oleg.feoktistov]

Hi guys,

To be honest, I can't think of any reasons why it could be implemented like that. Set cmdlet should be a plain equivalent of walking through wizard steps. So, even if nothing besides a subject-to-change is passed to Set, it just resaves entity like you do when just going through wizards, not changing anything and then pressing "Finish". For example:

Code: Select all

$repo = Get-VBRObjectStorageRepository -Type AmazonS3
Set-VBRAmazonS3Repository -Repository $repo

Thus, it does look like a bug to me. I'll take some time to check it with QA and follow-up on this thread after.

Best regards,
Oleg

[oleg.feoktistov]

Confirmed as a bug. The fix is scheduled to vNext. Thanks for your feedback, Daniel!