Hello Folks,
I feel like I don't understand something about how pre-job scripts get triggered with respect to copy-prune jobs.
Heres the set up
- Backup server is usually off except for a window of time when it gets automatically turned on, it turns on at 7:00am in the morning.
- All week the VBR server does this and backs up networked devices properly using normal backup jobs
- On Saturday there is a VBR copy-prune job, the copy period is set to "Copy Every" 1 days starting at 8am. The repository for this copy-prune is a usb disk
- The copy-prune jobs schedule window is open from 8am through 10pm on Saturday only.
- There is a pre-job script that must be run before the copy-prune begins
Observations
- at 7:00am plus OS boot up time, I can see in the VBR log that the copy-prune job starts, - these copy jobs are all continuous jobs
- The pre-job script runs at this time as well (7:xx am). This is fine as the script I've written checks the time and won't do anything until 8-9am
- The copy-prune job then sits and waits for scheduled time to allow data transfer
- 8am comes and the job progresses ... but of course the pre-job script doesn't run again and this is my problem.
I know why this is. The job has already started, the pre-job script did run at 7:xx am and it was only the scheduler that stopped progression.
Problem
The problem I can't think through is how to get the pre-job script to run immediately prior to the job actually starting to transfer data? Ideally I'd just run the copy-prune at 8am, but this can't be done insofar as I'm able to ascertain. Copy jobs are either disabled (and never run) or enabled, in which case they are always running.
Confusion (previous set up that worked as I expected)
- I used to wake up this machine at 7:30pm and run it all night every day
- The copy-prune was set to "Copy Every" 1 days starting at 2:00am
- The schedule was set to allow data transfer only between 02:00am-12pm on Saturdays
- The copy-job would start within a few minutes of the server booting and I could see the pre-job script run. Again, no problem, my script checks the day and time.
- The copy-job logs tells me that its waiting for the scheduler
- 2am (on Saturday early morning) comes, and the copy-prune job log tells me this: "Copy Interval has expired", "Waiting for the new copy interval"
- Moments after the above, the job log creates a new entry: "Job started 2:00:21am", "Pre-job script completed successfully" ... my script which checks day and time is happy, does its thing
- The scheduler is happy as the current time is now between 2am and 12pm Saturday and allows data transfer ... the job progresses and completes.
Whats going on here? Why would the second scenario listed work yet the first doesn't? The logic seems the same ... but in the second case we cross through a midnight boundary ... is this important?
-
- Enthusiast
- Posts: 71
- Liked: 14 times
- Joined: Jul 06, 2018 3:44 am
- Full Name: Moopere
- Contact:
-
- Veeam Software
- Posts: 3624
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Pre-Job script not launching?
Hello,
The reason is that there was no interval expiration in the first scenario, in particular you didn't see the corresponding message: "Copy Interval has expired".
I believe that you already found an explanation: in the second scenario you cross midnight boundary and a new interval is started at 2:00 AM according to backup copy daily schedule, in the first scenario backup copy waits for the next day to start a new interval. In your case, it's an infinite loop of waiting as Veeam B&R wakes up every day at 7:00 AM. As a workaround, you can start a new interval manually using this cmdlet or change job or Veeam B&R boot time schedule.
Thanks!
The reason is that there was no interval expiration in the first scenario, in particular you didn't see the corresponding message: "Copy Interval has expired".
I believe that you already found an explanation: in the second scenario you cross midnight boundary and a new interval is started at 2:00 AM according to backup copy daily schedule, in the first scenario backup copy waits for the next day to start a new interval. In your case, it's an infinite loop of waiting as Veeam B&R wakes up every day at 7:00 AM. As a workaround, you can start a new interval manually using this cmdlet or change job or Veeam B&R boot time schedule.
Thanks!
-
- Enthusiast
- Posts: 71
- Liked: 14 times
- Joined: Jul 06, 2018 3:44 am
- Full Name: Moopere
- Contact:
Re: Pre-Job script not launching?
@ PetrM - thanks for the powershell hint. Not sure how it might help in this case, but it might be useful later.
So midnight is an important milestone for the interval jobs it seems. 1x a day, 8am job won't respect the 8am setting until it has been running continuously and passed through a midnight transition? Is that right?
In my case, if I start the machine at 7am, the job runs immediately, because these copy jobs are all continuous jobs, then it won't respect the 8am 'interval' thing until we've passed through midnight - if I left the machine running the interval would expire at 8am the following day.
So midnight is an important milestone for the interval jobs it seems. 1x a day, 8am job won't respect the 8am setting until it has been running continuously and passed through a midnight transition? Is that right?
In my case, if I start the machine at 7am, the job runs immediately, because these copy jobs are all continuous jobs, then it won't respect the 8am 'interval' thing until we've passed through midnight - if I left the machine running the interval would expire at 8am the following day.
-
- Veeam Software
- Posts: 3624
- Liked: 608 times
- Joined: Aug 28, 2013 8:23 am
- Full Name: Petr Makarov
- Location: Prague, Czech Republic
- Contact:
Re: Pre-Job script not launching?
Hello,
Yes, your understanding is correct.
Thanks!
Yes, your understanding is correct.
Thanks!
-
- Enthusiast
- Posts: 71
- Liked: 14 times
- Joined: Jul 06, 2018 3:44 am
- Full Name: Moopere
- Contact:
Re: Pre-Job script not launching?
Hello again readers - thought I'd come back to this.
Subsequent to the above conversation I've upgraded the B&R server to the MAR 2022 version which appears to have altered the way these continuous jobs run. It now operates in a much more intuitive way, apparently without the caveat related to crossing a midnight boundary as described in the posts above this one.
What I see now, in the specific case mentioned in the thread is:
- Backup server wakes up at 7:00am, runs the pre-job script. The pre-job script through its own logic realises its too early and doesn't do anything
- At 8am, the current copy-prune cycle ends (which it didn't do in versions prior to MAR 2022 because of the midnight crossover thing), the copy-prune job then starts again
- As the copy-prune just re-started, my pre-job script runs again. This time the scripts internal logic realises the time is right and does its work
- After returning from the pre-job script Veeam now wants to actually run the job, so it triggers the pre-job script again (lol). This is fine as my scripts logic takes care of things
- Job runs and all is well in the world.
Subsequent to the above conversation I've upgraded the B&R server to the MAR 2022 version which appears to have altered the way these continuous jobs run. It now operates in a much more intuitive way, apparently without the caveat related to crossing a midnight boundary as described in the posts above this one.
What I see now, in the specific case mentioned in the thread is:
- Backup server wakes up at 7:00am, runs the pre-job script. The pre-job script through its own logic realises its too early and doesn't do anything
- At 8am, the current copy-prune cycle ends (which it didn't do in versions prior to MAR 2022 because of the midnight crossover thing), the copy-prune job then starts again
- As the copy-prune just re-started, my pre-job script runs again. This time the scripts internal logic realises the time is right and does its work
- After returning from the pre-job script Veeam now wants to actually run the job, so it triggers the pre-job script again (lol). This is fine as my scripts logic takes care of things
- Job runs and all is well in the world.
Who is online
Users browsing this forum: Bing [Bot] and 271 guests