V12, powershell, positively identifying imported backup

[chrisrd]

Hi,

How can we, using powershell, positively identify a just-imported backup so we can then do something with that specific backup?

We receive 3rd party client backups and use powershell to import them into our own VBR for various purposes (run checks etc.).

When we import the backup the only thing we have is the path to the backup. With Veeam v11 and prior, we could then identify a specific imported backup using the path, e.g.:

Code: Select all

$dir = '\aaa\bbb'
$fname = 'ccc.vbm'
Import-VBRBackup -Server $host -Filename ($dir + '\' + $fname)
$b = Get-VBRBackup | ?{$dir -eq $_.DirPath -and $fname -eq $_.MetaFileName}
// do stuff with the $b backup

With Veeam v12, *iff the backup has a non-blank PolicyName*, the imported backup has blank for both DirPath and MetaFileName - i.e. a specific backup can no longer be identified using DirPath and MetaFileName.

Veeam Advanced Technical Support have said this is "by design ... and can not be changed":

Case #06035136 - BUG importing vbm file with non-blank PolicyName

In our environment we have a number of backups imported at any time, we're not in control of the backup names, and we don't know the backup names (other than what might be "encoded" in the path), and it's not uncommon for multiple backups to have the same name (e.g. we receive a lot of backups called "Backup Copy Job"), and we may be importing multiple backups at the same time as a response to external events (i.e. we can't rely on "look at the existing backups, do an import, and the new backup is the one just imported").

So... how can our powershell positively identify a just-imported backup so it can then do whatever it needs with that specific backup?

(Ideally, Import-VBRBackup would return the handle to the just-imported backup but... it doesn't. )

Cheers,

Chris

[oleg.feoktistov]

Hi Chris,

All backups have IsImported property available, also backup metadata gets updated on imports, so you could try querying a just-imported backup with the following script:

Code: Select all

$backups = Get-VBRBackup | where {$_.IsImported -eq $true}
$backups | select Name, MetaUpdateTime | sort -Property MetaUpdateTime -Descending

The one that have just been imported should appear first on the list given that no actions on other backups involving metadata updates are happening. Otherwise, you could track backup import session and correspond session timestamps with MetaUpdateTime property value.

Best regards,
Oleg

[chrisrd]

Thanks Oleg,

Using the MetaUpdateTime would certainly work almost 100% of the time - but as these imports are initiated by external events it's unlikely but possible for multiple imports to occur around or at the same time, in which case the MetaUpdateTime might not help distinguish which import belongs to which process.

I'm not sure how the sessions work but I suspect the session timestamps will suffer the same problem.

I'd really prefer a solution that's guaranteed 100% rather than "nearly 100%".

Is there some way to find out "this is my current session", then look at "this is the most recent import done in this session"?

Chris

[david.domask]

Hi @ChrisD,

I've been made aware of this case, and right now we're discussing the situation with RND a bit on how to best meet your requirements. The engineer should have an update in a bit, but I want to prepare you that this might not be an item that is suitable for a hotfix; however the Engineer will let you know the details in full once the discussion with RND is completed.

I'm also checking if we can find a workaround that is suitable for you in the meantime; I tested on the weekend and getting the import backup session result is actually much more simple than I realized (Get-VBRSession allows us to filter by -Type, and will return baseSession objects if you pass type '10002'). I've relayed my information and workflow to the engineer, and they will mention this as well with further details as well as the result of the discussions with RND>

[david.domask]

Addendum to my previous post as I realized I forgot an entire thought

I did check in the configuration database and the internal class methods, and regrettably the resulting CBackup object is not printed to any place in the session data, so it's not easily parse-able just from the Session data alone, which is what makes this complex I guess. Hopefully we can see some improvements on this, but that's the main issue as best I can tell, that we don't have a link in the database to the Import Backup session and the resulting imported CBackup object.

I can think of some pretty dumb but effective tricks for avoiding this, but it involves creating/removing temporary Repositories before/after import. It's a little primitive, but I could imagine a workflow like:

1. Get backup path to import
2. Pass it to a function that:
2a. Creates a temporary repository with some unique name and saves it to some variable $repo
2b. Use Import-VBRBackup with the -Repository flag and send it to $repo
2c. Fetch the backup by filtering on IsImported and RepositoryID (obtained from $repo.id)
2d. Do your actions with the Imported backup (restore it, test it, move backup to another repository)
3. Once the backup is no longer needed, remove it and its temporary repository

This is...not great, but depending on the result of the discussion with RND, I suppose it will work for the time being.

[oleg.feoktistov]

Hi Chris,

A question from my side - does the same issue with DirPath and MetaFileName properties apply to child backups?
I mean, if you try this:

Code: Select all

$backup = Get-VBRBackup -Name 'Backup Job 1' 
$childBackups = $backup.FindChildBackups()
$childBackups | select Name, DirPath, MetaFileName

Would DirPath and MetaFileName still be null?

Best regards,
Oleg

[chrisrd]

Hi Oleg,

Fantastic! $childBackups indeed comes back with the appropriate DirPath and MetaFileName.

I think that resolves my issue.

I was unaware of FindChildBackups(). I note that in the VBR GUI the imported backup "just appears" under Backups > Disk (Imported), there doesn't seem to be anything about parent vs child backups etc. Is there anywhere that describes how this all hangs together?

David - thanks for the temporary repository suggestion, that shows some out of the box thinking, although I must say I'm relieved that work around isn't necessary

Thanks for your help,

Chris

[david.domask]

I'm really glad it worked out for you @ChrisD, and tbh, I'm glad Oleg's suggestion works as I knew as I wrote the suggestion that it was complex I know it _would_ work, but it was definitely a kludge

The parent vs child backup is mostly a v11/v12 thing and it mostly describes the relationship for jobs with workers or backups that are using True PerMachine. We need to associate the individual machine backups with the "parent" backup; you can think of this from the Backups > Disk view and understand that the top level item showing the backup name is the Parent, and the individual machine backup chains are the children. (this is a bit of a loose analogy, but I think it should be enough for your purposes)

[chrisrd]

Thanks for the explanation @david.domask, I think I have a basic understanding of how the parent/child relationship arises now.

Interestingly, this helps me understand something that's bugged me a bit: under v11, importing a vbm file with a non-blank PolicyName results in TWO imported backups, one job with the JobName set to the PolicyName\JobName from the vbm file, and the DirPath and MetaFileName set to the import path and file, and another separate job with JobName set to just the PolicyName from the vbm file, and DirPath and MetaFileName set to null:

Code: Select all

veeam-v11:\> Import-VBRBackup -Server 'localhost' -Filename 'path\file.vpm'
veeam-v11:\> Get-VBRBackup | fl Id,JobName,DirPath,MetaFileName

Id           : 51f44dce-1591-4c49-9276-8b12843e11a1
JobName      : VIPLUS-SQL Backup Copy Job to OnTheNet\VIPLUS-SQL Veeam Local Backup_imported
DirPath      : \\nfs-01\nfs\veeam\veeam-02\glsys-viplus\VIPLUS-SQL Backup Copy Job to OnTheNet\VIPLUS-SQL Veeam Local Backup
MetaFileName : VIPLUS-SQL Veeam Local Backup.vbm

Id           : d9afcdbf-83dc-48b2-950f-e7038d05e86b
JobName      : VIPLUS-SQL Backup Copy Job to OnTheNet
DirPath      :
MetaFileName :

Only the first of these jobs shows up in the GUI, and that deleting EITHER job with Remove-VBRBackup will remove BOTH the "visible" job and the hidden (in the GUI) job. This behavior then results an error if you remove all jobs using:

Code: Select all

veeam-v11:\> Get-VBRBackup | Remove-VBRBackup -confirm:$false

...because the Get-VBRBackup returns BOTH jobs, then Remove-VBRBackup removes BOTH jobs when it sees the FIRST job from Get-VBRBackup, and Remove-VBRBackup returns a "job not found" error when it sees the SECOND job from Get-VBRBackup.

I had to code our app to ignore this error.

Veeam v12 no longer has this behavior because Get-VBRBackup returns only the "parent" job.

[david.domask]

Oh, glad I could help @ChrisD. Indeed, likely that is what you were having to account for.

BTW, as for your main issue, the use case was noted by our RND and there are plans to make this easier for you in future releases. (PM team, tracked in issue 526409)

No ETA on when it will come, but you can refer to your previous case number or this issue on future updates and Support can confirm the status.

[chrisrd]

Hi,

Unfortunately, my problem is not completely resolved, the same thing happens when importing an encrypted backup with a non-blank PolicyName: the object returned from Get-VBRImportedEncryptedBackup has a blank Path.

To restate the problem: when importing an encrypted backup, the method has been to use Import-VBRBackup to do the import, then use Get-VBRImportedEncryptedBackup and find the backup we just imported by looking for the path we just imported:

Code: Select all

Import-VBRBackup -Server 'localhost' "$vbmDir\$vbmFile"
$encrypted = Get-VBRImportedEncryptedBackup  | ?{$_.Path.ToString() -eq $vbmDir}
Set-VBREncryptedBackupPassword -Backup $encrypted -Password $pass

However since Veeam v12, if the imported encrypted backup has a non-blank PolicyName, the object returned from Get-VBRImportedEncryptedBackup has a blank Path. The object also doesn't have a FindChildBackups() member which was the solution for the same problem with Get-VBRBackup().

How can I positively identify which object returned from Get-VBRImportedEncryptedBackup is the backup I just imported?

Note that there can be multiple backups imported at the same time, and the Job Name is not under our control and can be the same for multiple jobs (e.g. "Backup Copy Job").

Cheers,

Chris

[chrisrd]

Hi @oleg.feoktistov, @david.domask,

Sorry to pester you, but any ideas here?

Thanks,

Chris

------------------------------------------------------------------------------
Hi,

Unfortunately, my problem is not completely resolved, the same thing happens when importing an encrypted backup with a non-blank PolicyName: the object returned from Get-VBRImportedEncryptedBackup has a blank Path.

To restate the problem: when importing an encrypted backup, the method has been to use Import-VBRBackup to do the import, then use Get-VBRImportedEncryptedBackup and find the backup we just imported by looking for the path we just imported:

Code: Select all

Import-VBRBackup -Server 'localhost' "$vbmDir\$vbmFile"
$encrypted = Get-VBRImportedEncryptedBackup  | ?{$_.Path.ToString() -eq $vbmDir}
Set-VBREncryptedBackupPassword -Backup $encrypted -Password $pass

However since Veeam v12, if the imported encrypted backup has a non-blank PolicyName, the object returned from Get-VBRImportedEncryptedBackup has a blank Path. The object also doesn't have a FindChildBackups() member which was the solution for the same problem with Get-VBRBackup().

How can I positively identify which object returned from Get-VBRImportedEncryptedBackup is the backup I just imported?

Note that there can be multiple backups imported at the same time, and the Job Name is not under our control and can be the same for multiple jobs (e.g. "Backup Copy Job").

Cheers,

Chris
------------------------------------------------------------------------------

[oleg.feoktistov]

Hi Chris,

The class returned with Get-VBRImportedEncryptedBackup doesn't offer any methods, so the workaround I could think of here is to try to return encrypted backup as CBackup type and apply the same algorithm with FindChildBackups() to identify the right one before decrypting it:

Code: Select all

$encrypted = Get-VBRImportedEncryptedBackup  | ?{$_.Path.ToString() -eq $vbmDir}
$backup = [Veeam.Backup.Core.CBackup]::Get($encrypted.Id)
$childBackup = $backup.FindChildBackups()
$childBackup

Best regards,
Oleg

[chrisrd]

Hi Oleg,

That works - thanks very much!

Chris