Identify the proper physical location of a restorepoints file

[stephan.troxler]

I'm working on some reports to gather a list of all the physical files referenced somewhere in Veeam. As storage solution we have scale-out repos with multiple extents and we use the placement policy where backups should always stay in the same extent of the repo. Recently, some extents were running full and the jobs restarted in other extents. While this is not a drama itself it resulted in restorepoint object with multiple links to extents. The manual states here: "Veeam Backup & Replication does not split one backup file across multiple extents.". Therefore only one extent cant really contain the file and some manual checks proofed this.

How can I identify the extent that was used to store the physical file from a restorepoint perspective?

pseudo code:

Code: Select all

#gather a list of all restorepoints from a backup
$backups =  Get-VBRRestorePoint -Backup "mybackup"
foreach($b in $backups)
	{
	$extent = $b.FindChainRepositories()
	
	->now some $extent contains one, some multiple references to a "Veeam.Backup.Core.CBackupRepository" object
	}

$backup.

[david.domask]

Hi Stephan,

post509821.html#p509821

Try my function here, it should work on 12.x (and there are v11 and v10 versions of the function earlier on in the topic).

Fetch a backup with Get-VBRBackup and pass the resulting object to the function (you can make an array of multiple backups, but pass them one at a time with a foreach loop)

The function returns a bit of extraneous information, but you can edit the function to your liking. It will return the value of $StoragePathsandBlocksize at the end so just save the results to some variable and you can then export to CSV/JSON/continue working with the data in your script.

This was originally meant to troubleshoot fast clone issues so probably you don't need the Blocksize property, you can change that or remove it if you like.

[stephan.troxler]

Hi David

Thank you so much for this info! I could modify my script with it and it works like a charm now, returning only one extent. Do I understand correctly that the objects of restorepoint, extent and the file (storage) themselves contains no info about the exact location (but the repo has it)?

What is the point with those Backups that have an ID of "'00000000-0000-0000-0000-000000000000'" and that you switch in your code? I've noticed that some Jobs have multiple Backups with the same name but only one of them has a proper ID, while the others have the zeros.

Btw - a response time of only 4 minutes to my not-so-standard question. I'm impressed.

Greetings
Stephan

[david.domask]

Hi Stephan,

You're very welcome! Glad it worked and thank you for the kind words :3

As for your questions, will split them into two sections:

Backup File Location:

First, some terminology:

Backup: Logical construct representing the top-level of what makes a "backup" in the UI. Includes info like VBM location, repository information, etc.
Restore Point: Logical construct representing point in time of a given object in backup.
Storage: The actual backup files on repository (VBK/VIB/V..), inside of which are the actual data blocks and metadata to make up a backup.

For storages not stored on a Scale-out Backup Repository (SOBR), fetching the path from CStorage objects is as simple as checking FilePath.
For SOBRs, you need to "build" the path from a few other locations, and I'll just share from my notes document:

Scale-out Repositories (SOBR) and non-SOBR repos have different paths

Non-SOBR use full path on system and can be retrieved with just the path for the Storage Object
SOBR uses relative paths for the Storage and need to be constructed with:

Extent.GetPath()
MetaPath property†
Storage Name (Storage = backup file, e.g., vbk/vib/vrb)
† You can also use the Job.Name property but this will fail for imported backups on a SOBR as well as Orphaned, so it's better to use the MetaFile Path
SOBR requires a metafile for Backups when adding an extent, so it's safe to assume this will be here. Backups on SOBR that somehow have a NULL or empty meta file path should be treated as exceptions and do not need special handling; by definition it is a problem with the environment and it needs to be fixed, not handled by code
Note: the bolded part I'm talking about image based backups (VMware/HV, Agents, etc) -- I'm not sure how it works with Plugin backups, but for image based backups that should be true

The script does this automatically, and builds it from the Extent path (Repository Path set in the Repository wizard in the UI), the MetaPath (represents the job folder name on the repository, may differ from what you see in the UI), and then the actual storage file name.

Why 0'd UUID in the script?

Good eye for noticing this It's to allow the script in its current form to process Imported and Orphaned backups, which will have a 0'd UUID for the JobID property. In looking again at the script, I don't remember why I made an if statement there; I want to say imported/orphaned behave differently and you need to check a different property, but it's entirely possible I was just in a rush and needed a quick fix for a case at that time and forgot to go back and check it Probably it can be optimized, but I think it's pretty fast still.

[stephan.troxler]

Hi David

Thank you for your detailed explanation of how the path is built and why some backups have a 0-reference. The info about the 0-IDs helped me to clean up old imported backups.
The part with the folder is however raising even more questions to me..
If I get you correctly, "$Backup.FindJob().Name" would be the right way to identify the folder name of the the physical path? Is this what you call the "MetaFile Path"?

I have found an example where this is not working:
Name of the Backup: "myname-daily"
$Backup.FindJob().Name --> returns "myname-daily"
$Backup.DirPath.ToString() --> returns "myname-daily_1"
The physical files from the restorepoints can be found in the "myname-daily_1" directory. The other directory "myname-daily" however also exists but is empty.

Another strange thing that I dont understand is how the path to the physical file is generated. I've identified 3 different versions so far:
1. every server has its sub directory inside a directory named after the job. This seems to apply mostly for backups of type "Windows/Linux Agent Backup"
> extent/<job name> / <server name> / <jobname - servername - date>.vbk
2. multiple servers share a directory and the server name is part of the file name dived by "." This seems to apply for all backups of type "VMware Backup"
> extent / <job name> / <server name>.<guid - date>.vbk
3. A directory is created containing the job name and server name divided by "_-_"
extent/<job name>_-_<server name> / <jobname - servername - date>.vbk

Is this due to legacy seetings? Is there an option to use the same naming on all backups?

[david.domask]

Hi Stephan,

For the folder items, to be honest I think using FindJob().Name is not correct anymore and probably fails on some edge-cases like what you're describing here. Similarly, I did a quick test with GetMetaPath() and seems there are some nuances I need to check also on this, but probably that research will be on a later time when I have some more time to dive in.

And I should add a clarification that my note there was primarily focused on image based backups when I wrote it The general idea is still true, but some of the properties/methods may have changed since I wrote it, which is probably why there's some confusion, and the script also has a few edge cases it does not handle well, for example the folder_1 behavior you're observing here. That happens if Veeam tries to make the normal folder, but there is already a folder with the same name, so Veeam just appends the _N as one might expect. So in a few situations, the script might give a wrong path; I will think about how to fix it when I have some time to sit down and review.

For Agent backups, the structure is a bit different with Policies. For 1 and 2 you are correct on the construction, that is expected with Policies and that is how image based backups (VMware/HyperV) will be handled. Just note that this assumes Per-Machine backups are enabled (PerVM), with each machine having it's own backup chain. For PerJob backups (all machines are stored in single backup file), the backup files will take the name of the job (I think the name will be truncated to 52 characters if I remember right, I think this is done to try to get the filenames as short as possible to avoid Windows default configuration which does not support longpaths without a registry value being set).

At this time, there's not a way to customize the naming schema, so the scripting is required, though I think it's worth a discussion internally on making this more easily retrievable without having to utilize unsupported methods, as there's a lot to consider as we can see