Hi Colin, welcome to the forums.
I would go at this through Get-VBRBackup and Get-VBRRestorePoint. A simple example workflow:
The COib objects returned by Get-VBRRestorePoint have an unsupported method GetStorage(), which returns the actual backup file information. The relevant properties on the result of GetStorage() method are:
As for running this as a post-job script, I would advise against it. It will work for sure, however, the job will need the script to succeed with "success" else you might get errors unrelated to your backup. While you can configure how to handle post-job script errors (ignore, require success, warn but continue), my personal take is that such errors are needless noise in the backup reporting when the 7zip operation isn't really related to your actual backups.
Similarly, some features like Backup Copy Immediate Mode, Offloading to Capacity Tier, etc, all have the ability to start their processing immediately after the primary job finishes; if 7zip is busy with the backup file while these operations are trying to start, you'll get a lot of file lock errors that may not be clear at first.
I would instead run such a script as a scheduled task outside of when the normal backup window is running. It avoids the chance of these conflicts and makes troubleshooting issues with the script a lot easier. I would also advise if you have available space for an extra full, consider integrating Export-VBRRestorePoint to make a copy of the restore point for 7zip to work with instead of touching your actual backups. You can set an auto-expiry on the exported restore point (for like 1 day or something) so you don't even need to worry about cleaning it up.
I realize it's a bit of extra scaffolding to your intended script, but I think this extra will help reduce frustration in the future.
I would go at this through Get-VBRBackup and Get-VBRRestorePoint. A simple example workflow:
Code:
$backup = Get-VBRBackup -name "ps-test-bcj" #replace this with your backup name$rp = Get-VBRRestorePoint -Backup $backup | Sort -Property CreationTime -Descending | Select -First 1 #We do this to ensure we always get the most recent restore pointI think that should help you with finding the most recent always and knowing if it's full or not. Please note if you use Scale-out Backup Repositories, FilePath will have a few nuances and will only show the actual backup file name, there are workarounds for this but let's wait to see if it's necessary for your environment.CreationTime (when the backup was made)
IsFull (is a backup a full backup)
FilePath (actual location on backup repository server of the backup file, probably useful if you want to use this path with 7zip)
As for running this as a post-job script, I would advise against it. It will work for sure, however, the job will need the script to succeed with "success" else you might get errors unrelated to your backup. While you can configure how to handle post-job script errors (ignore, require success, warn but continue), my personal take is that such errors are needless noise in the backup reporting when the 7zip operation isn't really related to your actual backups.
Similarly, some features like Backup Copy Immediate Mode, Offloading to Capacity Tier, etc, all have the ability to start their processing immediately after the primary job finishes; if 7zip is busy with the backup file while these operations are trying to start, you'll get a lot of file lock errors that may not be clear at first.
I would instead run such a script as a scheduled task outside of when the normal backup window is running. It avoids the chance of these conflicts and makes troubleshooting issues with the script a lot easier. I would also advise if you have available space for an extra full, consider integrating Export-VBRRestorePoint to make a copy of the restore point for 7zip to work with instead of touching your actual backups. You can set an auto-expiry on the exported restore point (for like 1 day or something) so you don't even need to worry about cleaning it up.
I realize it's a bit of extra scaffolding to your intended script, but I think this extra will help reduce frustration in the future.
Statistics: Posted by david.domask — Oct 29, 2024 3:46 pm