where can I find fast clone status in repository output

[pirx]

Hi,

I want to add a check to my script that checks if all xfs repo extents have fast clone enable. But I can't find the right property.

Code: Select all

PS C:\windows\system32> $extent.Repository

Info                           : Veeam.Backup.Model.CBackupRepositoryInfo
Host                           : Veeam.Backup.Core.Common.CHost
Id                             : 3511bc17-f659-4fdf-9cfd-e0dbcd05558f
Name                           : DE-WOP-XFS-C01-E01
HostId                         : cf6452e6-2130-4d42-b3a6-c493d7e34c11
MountHostId                    : 446a1c3e-b992-4657-abcb-ecc92b0fc48d
Description                    : Created by xxxx at 21.05.2021 09:59.
CreationTime                   : 
Path                           : /veeam_repo/SDEU2000_DE-WOP-XFS-C01-E01
FullPath                       : |veeam_repo|SDEU2000_DE-WOP-XFS-C01-E01
FriendlyPath                   : /veeam_repo/SDEU2000_DE-WOP-XFS-C01-E01
ShareCredsId                   : 00000000-0000-0000-0000-000000000000
Type                           : LinuxLocal
Status                         : Ordinal
IsUnavailable                  : False
Group                          : BackupRepository
UseNfsOnMountHost              : True
VersionOfCreation              : 10.0.1.4854
Tag                            : 3511BC17F6594FDF9CFDE0DBCD05558F
IsTemporary                    : False
TypeDisplay                    : Linux
IsRotatedDriveRepository       : False
EndPointCryptoKeyId            : 00000000-0000-0000-0000-000000000000
Options                        : Veeam.Backup.Model.CDomBackupRepositoryOptions
HasBackupChainLengthLimitation : False
IsSanSnapshotOnly              : False
IsDedupStorage                 : False
SplitStoragesPerVm             : True

Code: Select all

PS C:\windows\system32> $extent.Repository.Options

MaxTaskCount                : 26
IsTaskCountUnlim            : False
MaxArchiveTaskCount         : 13
CombinedDataRateLimit       : 0
Uncompress                  : False
OptimizeBlockAlign          : True
RemoteAccessLimitation      : None
EpEncryptionEnabled         : False
MaxPointCount               : 2147483647
OneBackupFilePerVm          : True
IsAutoDetectAffinityProxies : False

Code: Select all

PS C:\windows\system32> $extent.Repository.Info
Id                       : 3511bc17-f659-4fdf-9cfd-e0dbcd05558f
Name                     : DE-WOP-XFS-C01-E01
FormatDisplayName        : DE-WOP-XFS-C01-E01 (Created by xxxx at 21.05.2021 09:59.)
Description              : Created by xxxx at 21.05.2021 09:59.
CreationDate             : 
Type                     : LinuxLocal
Group                    : BackupRepository
HostId                   : cf6452e6-2130-4d42-b3a6-c493d7e34c11
MountHostId              : 446a1c3e-b992-4657-abcb-ecc92b0fc48d
Path                     : /veeam_repo/SDEU2000_DE-WOP-XFS-C01-E01
FullPath                 : |veeam_repo|SDEU2000_DE-WOP-XFS-C01-E01
ShareCredsId             : 00000000-0000-0000-0000-000000000000
Tag                      : 3511BC17F6594FDF9CFDE0DBCD05558F
Options                  : <BackupRepositoryOptions><RepositoryOptions><OptimizeBlockAlign>True</OptimizeBlockAlign><Uncompress>False</Uncompress><OneBackupFilePerVm>True</OneBackupFilePerVm><MaxTasksCount>26</MaxT
                           asksCount><WriteThroutput>0</WriteThroutput><IsAutoDetectAffinityProxies>False</IsAutoDetectAffinityProxies></RepositoryOptions></BackupRepositoryOptions>
EndPointCryptoKeyId      : 00000000-0000-0000-0000-000000000000
IsRotatedDriveRepository : False
IsDependant              : False
Status                   : Ordinal
IsUnavailable            : False
IsShadow                 : False
DeletedRetentionSchedule : Start time: [21.05.2021 10:06:13], Latest run time: [21.05.2021 09:56:13], Timeout for backup completion: [180min], Next run time: [], Retry times on failure: [3], Retry timeout: [10 
                           min], Daily options: [Enabled: True, DayNumberInMonth: Everyday, Days: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday]
CachedTotalSpace         : 384018673565696
CachedFreeSpace          : 381341190975488
VersionOfCreation        : 10.0.1.4854
UseNfsOnMountHost        : True

[oleg.feoktistov]

Hi,

Yes, there is no such property in CBackupRepository class, so no easy way to get it. It is being written to Veeam DB though, and if you are into .NET, you can retrieve it with DB Manager instance:

Code: Select all

$repo = Get-VBRBackupRepository -Name 'LINUX-REPO'
$repoInfo = [Veeam.Backup.DBManager.CDBManager]::Instance.LinuxRepositories.FindForRepoId($repo.Id)
$repoInfo.IsSyntheticAvailable

Not supported, yet comes in quite effective.

Thanks,
Oleg

[pirx]

Hm, should this work for SOBR extent too? For me it doesn't.

Code: Select all

PS C:\windows\system32> $repo


ParentId   : 0f6e0bf2-b99f-48ba-a734-6ec20c28c4eb
Repository : Veeam.Backup.Core.CBackupRepository
Status     : Normal
Name       : DE-WOP-XFS-C01-E01
Id         : 977723dc-807a-4e78-8f0b-532232adbbf7




PS C:\windows\system32> [Veeam.Backup.DBManager.CDBManager]::Instance.LinuxRepositories.FindForRepoId($repo.Id)

PS C:\windows\system32>

[soncscy]

SOBR is a bit different as you need to determine the extents first.

This is a function I wrote for another script and it returns extents from a SOBR. It accepts a string to fetch the SOBR with Get-VBRBackupRepository, but you can easily change it to accept a CBackupRepository Scale out Repo object:

Code: Select all

function Get-ExtentDataFromScaleout {
	param(
		[string[]]$ScaleoutRepoName
		)
		$ScaleoutRepo = Get-VBRBackupRepository -Scaleout -Name $ScaleoutRepoName
		$ScaleOutExtentsRepositories = $ScaleoutRepo.Extent.Repository 
		return $ScaleOutExtentRepositories
	}

From there you can act on normal Repo methods like Oleg referenced.

I similarly have the following to parse repos:

Code: Select all

function Get-LinuxRepositoryData {
    param(
        [string[]]$RepositoryID
        )
		$LinuxRepositoryData= [Veeam.Backup.Core.CLinuxRepository]::FindByRepository("$RepositoryID") 
		return $LinuxRepositoryData
	}

From there, you can pass this to parse the Original Repo object for the name, and the Repo information returned by the Get-*RepositoryData methods. Change CLinuxRepository for Windows/Cifs respectively.

[oleg.feoktistov]

Harvey has a point. I'd recommend using methods inside CLinuxRepository class as he mentioned. It returns the same info as DB Manager instance does, but looks rather concise. Thanks!

[pirx]

I already had the extend ID, I was just missing the way to query for IsVirtualSyntheticAvailable . There is a small typo in the example code:

$ScaleOutExtentsRepositories = $ScaleoutRepo.Extent.Repository
return $ScaleOutExtentRepositories

But this works now an I can check for IsVirtualSyntheticAvailable.

Id : daa968d3-bb4f-4c04-8201-504603992b39
RepositoryId : 43b032ea-237e-4b5e-bc6f-e0539cc941fd
IsVirtualSyntheticEnabled : True
IsVirtualSyntheticAvailable : True
ClusterSize : 4096

Thanks!

[spiritie]

FYI something has changed in v12, these functions are taking ages for us now, where before they were nearly instant.

[david.domask]

Hi @spiritie,

First, I need to note that these are unsupported methods, so we cannot really provide troubleshooting on them via a formal Support Case. I hope you understand.

As for the performance, I just tested fast in my lab, and I had no issues; responses were immediate:

PS C:\Users\Administrator> Measure-Command -Expression {[Veeam.Backup.Core.CWindowsRepository]::FindByRepository($repo.id)}


Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 14
Ticks : 145124
TotalDays : 1.67967592592593E-07
TotalHours : 4.03122222222222E-06
TotalMinutes : 0.000241873333333333
TotalSeconds : 0.0145124
TotalMilliseconds : 14.5124

So I would just check system resources on the VBR server and make sure that VBR isn't being backed up (or the server hosting the Veeam Configuration Database) while you're running the commands, but seems like it's local to your environment (all my lab environments I could not reproduce, just nice and fast responses)

[spiritie]

Yeah I know the are unsupported, just wanted to mention it.

We are seeing this across multiple VBR solutions.

[david.domask]

Interesting, I'm afraid I am not sure how to reproduce. Hopefully these can be returned by supported cmdlets in the future, but any common points behind any of the VBR installations? SQL Version/Edition? Are they all hosted on the same server as Veeam or are they standalone SQL servers?

If it's Microsoft SQL and the version is < MSSQL 2016, upgrading to 2016 should be priority; MSSQL has a LOT of optimizations in 2016 and later that the earlier versions just cannot do.

But I'm afraid it looks very much so localized at the moment.

[spiritie]

Hi David

This is a mixture of small VBR installations, some SQL 2016, some 2019 and some of them on Postgres, while others are large installations with SQL Standard and so on.

I've narrowed it down to to be an issue with SOBR, as soon as I remove this part of the script it executes nearly instant:

Code: Select all

$scaleouts = Get-VBRBackupRepository -ScaleOut

foreach ($so in $scaleouts) {
    $sobr_extents = Get-ExtentDataFromScaleout -ScaleoutRepoName $so.Name
    foreach ($se in $sobr_extents) {
        Get-RepoData -repo $se
    }
}

Adding some measurement into it:

Code: Select all

$scaleouts = Measure-Command { Get-VBRBackupRepository -ScaleOut }
Write-Host ("Time taken by Get-VBRBackupRepository -ScaleOut: {0}" -f $scaleouts.TotalSeconds)

foreach ($so in $scaleouts.Result) {
    $sobr_extents = Measure-Command { Get-ExtentDataFromScaleout -ScaleoutRepoName $so.Name }
    Write-Host ("Time taken by Get-ExtentDataFromScaleout for {0}: {1}" -f $so.Name, $sobr_extents.TotalSeconds)

    foreach ($se in $sobr_extents.Result) {
        $repoData = Measure-Command { Get-RepoData -repo $se }
        Write-Host ("Time taken by Get-RepoData for {0}: {1}" -f $se.Name, $repoData.TotalSeconds)
    }
}

Result: Time taken by Get-VBRBackupRepository -ScaleOut: 40,3756531

And it not give me any data, just empty.

[spiritie]

Just a little update, I've tested a bunch. The reason I got no output was because we have a filter to only show Linux repos, the hardened one in v12 are not called "LinuxLocal " anymore, but called "LinuxHardened ", so I've fixed that part in my script, my bad.

It seems to be our Postgres VBR server which is super slow to execute the command: Get-VBRBackupRepository -ScaleOut
Without the ScaleOut flag it is instant. At first I thought it was related to the SOBR which has S3 buckets in it or perhaps Linux repos, but they are all slow. For test I created an entire new SOBR with just 1 Windows extent in it, 0 backups in it.

I'll create an support case with Veeam support. This has 8 vCPU's, 24 GB RAM, and at the time of running the measure command the VBR server is not performing any jobs. CPU usage at 10% and RAM at 37%

Code: Select all

Measure-Command -Expression {Get-VBRBackupRepository}

TotalSeconds      : 0,1853648
TotalMilliseconds : 185,3648

Code: Select all

Measure-Command -Expression {Get-VBRBackupRepository -Scaleout}

TotalSeconds      : 73,0808433
TotalMilliseconds : 73080,8433

Code: Select all

Measure-Command -Expression {Get-VBRBackupRepository -Name "TST-WIN" -Scaleout}

TotalSeconds      : 40,3942879
TotalMilliseconds : 40394,2879

[david.domask]

Thanks for the update and the testing @spiritie .

> It seems to be our Postgres VBR server which is super slow to execute the command: Get-VBRBackupRepository -ScaleOut

Hrm, that is not good. The good news though is that this _is_ supported, so we can check it out on a support case.

Can I ask you to please open a case, reproduce the issue (note the date and time of the test and the exact command you used), and collect logs using https://veeam.com/kb1832. Use the 3rd radio option, and select the Veeam Server itself.

Please also provide a copy of the Veeam Configuration Database if your company's data export policies allow it: https://www.veeam.com/kb1471

And post your case number once it's created.

[spiritie]

Hi David

I've created the case and uploaded logs + Database + timestamp for query.

#06106018

[david.domask]

Thanks, I will monitor it and provide guidance for the engineers!

[david.domask]

Small update for anyone who was interested, the case is being reviewed by our RND team; it appears there may be an unexpected behavior in the Get-VBRBackupRepository cmdlet when using the -Scaleout flag, but it's being reviewed to confirm the behavior.

[spiritie]

FYI for anyone stumbling upon this forum post. The issue for PowerShell performance was because our VBR server was not allowed to connect to dev.veeam.com on port 443 and some Veeam PowerShell commands require this for some crazy reason. This is a bad design choice as many VBR servers are locked down and or are behind proxies and so on, this adds up to 10-20 seconds to the timeout to be reached, in some cases up to 1 minute, just for some PowerShell code that should have been executed in under 1 second.

Registry key to disable this: DWORD: CloudRegionsDisableUpdate = 1

[david.domask]

Thanks for the follow up @spiritie, this issue should be resolved in an upcoming release; I don't _think_ it got bundled in the v12 Cumulative Patch 3 however, so likely v12a (but to be determined. PM team, issue 531533)

The workaround is safe and stable, so it's not a problem