Hi Everyone,
I'm trying to write a script that when the backup jobs complete, it then checks the file type or the back up type, and if the backup was a full back up or file type .vbk then it runs the script. if it was an incremental back up then it doesn't run the script. i think i have most of the script working, which is to use 7zip to split the files into smallers sizes so its easier to upload them somewhere but if anyone could point me in the right direction it would be greatly appreciated as I am still learning couldn't find anything similar on google.
Thanks
Col
-
- Lurker
- Posts: 1
- Liked: never
- Joined: Oct 29, 2024 3:09 pm
- Full Name: Colin Roberts
- Contact:
-
- Veeam Software
- Posts: 2749
- Liked: 630 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Post job completion script help
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: Select all
$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 point
I 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.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: No registered users and 2 guests