PowerShell script exchange
Post Reply
B.F.
Expert
Posts: 160
Liked: 9 times
Joined: Jan 28, 2014 5:41 pm
Contact:

Self destruct with Stop-VBRJob

Post by B.F. »

Greetings,

I wanted to create a pre-job script (within the Script tab of the job) that check the status of another job. If the other job is still running, kill itself and essentially run again on the next scheduled event. Hoever, when I run it, it just does the 15min timeout.

Code: Select all

Add-PSSnapin veeampssnapin

$RepJob = Get-VBRJob | ?{$_.Name -eq "<RepJobName>" }
$BackupJob = Get-VBRJob | ?{$_.Name -eq "<BackupJobName>" }

If ($RepJob.GetLastState() -ne "Stopped")
{
    Stop-VBRJob -Job $BackupJob
}
If I do a -whatif it does state "What if: Performing the operation "Stop-VBRJob" on target "<BackupJobName>" if the RepJob is running.

Is it just the case that a running job does not have the option to kill itself?

Please advise.
Thanks
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Self destruct with Stop-VBRJob

Post by Vitaliy S. »

Hi,

Can you please elaborate a bit more on what you're trying to achieve? Do you want to limit the number of concurrently running jobs?
Thanks!
B.F.
Expert
Posts: 160
Liked: 9 times
Joined: Jan 28, 2014 5:41 pm
Contact:

Re: Self destruct with Stop-VBRJob

Post by B.F. »

Ticket ID# 01988476 can give you all the fine details if interested.

Summary:

Replication Job is set to kick off after Backup Job. Replication job uses the backup to replicate offsite. If Backup job kicks off again and Replication Job hasn't finished, Replication Job gets killed along with unfinished Veeam working snapshots. Datastore fills up with unfinished snapshots which causes unrest and discontent.

The first thing I tried via PS script was to have the Backup Job first check if the Replication Job is finished, if not, sleep for about 5 minutes and check again. Testing this seemed promising. But when I actually tried it, I didn't realize that Veeam has a 15min built in timeout timer. So that didn't work.

Thanks
Vitaliy S.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Self destruct with Stop-VBRJob

Post by Vitaliy S. »

B.F. wrote:If Backup job kicks off again and Replication Job hasn't finished, Replication Job gets killed along with unfinished Veeam working snapshots. Datastore fills up with unfinished snapshots which causes unrest and discontent.
Yes, that's ugly. Do you have Veeam ONE by any chance? If yes, then maybe this alarm could help > Orphaned VM backup snapshot. This alarm automatically detects orphaned snapshot left by the backup process, and then you can trigger automatic snapshot removal task.
B.F. wrote:The first thing I tried via PS script was to have the Backup Job first check if the Replication Job is finished, if not, sleep for about 5 minutes and check again. Testing this seemed promising. But when I actually tried it, I didn't realize that Veeam has a 15min built in timeout timer. So that didn't work.
It seems like you're trying to chain backup job right after replication? Maybe it sounds stupid, but why not to use a post-job script to trigger the backup job?
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Self destruct with Stop-VBRJob

Post by tsightler » 1 person likes this post

I don't think he's trying to chain the backup job off of the replication, he specifically states that he chains the replication job to run right after a backup job to immediately update the replica with the new data. The problem is, he's likely running the backup job fairly often, and if it's schedule happens to start before the chained replica job finishes, it kills the replica job and leaves things in an inconsistent state. He needs a way to make the backup job not try to run again on the schedule until the replica job finishes.

I have an alternative approach that I would suggest, what about simply disabling the Backup job in the pre-script of the replica job, and re-enabling the backup job with a post-script in the replica job. That would seem to achieve the goal fairly elegantly and reduce the code to the following:

Pre-job script:

Code: Select all

Add-PSSnapin veeampssnapin
Disable-VBRJob (Get-VBRJob -Name "<BackupJobName>")
Post-job script:

Code: Select all

Add-PSSnapin veeampssnapin
Enable-VBRJob (Get-VBRJob -Name "<BackupJobName>")
B.F.
Expert
Posts: 160
Liked: 9 times
Joined: Jan 28, 2014 5:41 pm
Contact:

Re: Self destruct with Stop-VBRJob

Post by B.F. »

tsightler wrote:I don't think he's trying to chain the backup job off of the replication, he specifically states that he chains the replication job to run right after a backup job to immediately update the replica with the new data. The problem is, he's likely running the backup job fairly often, and if it's schedule happens to start before the chained replica job finishes, it kills the replica job and leaves things in an inconsistent state. He needs a way to make the backup job not try to run again on the schedule until the replica job finishes.
Your understanding is spot on. The backup and offsite replication happens 4 times a day. Most of the time it's fine. Once a month when the dedupe does the thorough garbage collection, it churns enough bits to make the next backup / replication take much longer than normal. Replication isn't killed until the backup job completes and it starts the merge process on the very backup that the replication job is trying to use.
tsightler wrote:I have an alternative approach that I would suggest, what about simply disabling the Backup job in the pre-script of the replica job, and re-enabling the backup job with a post-script in the replica job. That would seem to achieve the goal fairly elegantly and reduce the code to the following:
WOW! What an awesome idea! I'll give that a shot. I won't be able to fully see if it works until almost another month later. We just recently had the monthly huge backup / replication occur a few days ago.

Thanks for the suggestion!


PS: Sorry, we do not have Veeam One :(
Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests