Support Center

Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

job duration and skipped job(s)

Ken Schwartz Sep 13, 2017 07:39AM CDT


I was hoping to get some clarification/confirmation concerning the behavior of Minion Backup in the following situation:

Suppose MinionBackup-AUTO is scheduled to run at the top of each hour, with FULL backups occurring at 10 PM, and T-log backups other hours. Let's further suppose that the backups take 50 minutes. But I'm also creating secondary copies (afterBatch). If the copies take more than 10 minutes, do I then wind up missing my 11 PM run, and consequently will have a gap of over an hour between my full and my t-log backups? Or is intelligence built in to the software to check the end time and perform any tasks that would be missed?



1 Community Answers

Best Answer
Sean McCown Sep 13, 2017 08:24AM CDT

Right, so this is where the scheduler table kicks in and it’s not an accident that it was done this way. Notice we’ve got a begin and end time for the schedules in the table. So if your log backups are scheduled for 11p-6a and they’re set with a FrequencyMins of 60. So what you get is a log backup every hr between 11p and 6a. But if your full job goes over, and you miss that 11p log backup, then what happens? Well, the table says to do a log backup every 60mins between 11 and 6. So the next time the job runs it’ll see that it’s in the middle of the log run timespan, and it’ll see that it’s been more than 60mins since the last log backup and it’ll run a new one. The only drawback is that now your entire schedule is thrown off because the next one will go 60mins from the time this one started.
So it really depends on the variance you can afford. If you can’t afford that variance, then right now you’ll have to break the logs out into their own job and run it on just a straight schedule. However, disable the log row in the schedule table when you do this, and call the log backup specifically in your new job. This is one of the only cases where you have to create a new job to handle something.
This table method has a great advantage in that if something happens, like we talked about, and you miss your backup time, it’ll still take the backup when it comes back online. So this can withstand unscheduled reboots and other things that keep jobs from running, and as long as you’re still within that window then the job will run when the Agent comes back online.
This also hinges on how often you run your AUTO job. If you want it to take the log backup quickly after that full job finishes, then set your job to run every 5 or 10mins. That way if the full job finishes at say 11:10, then it’ll start the log backup at 11:15. And if you do that all day, then most of the time it won’t have anything to do and it’ll just go back to sleep. So for example, let’s say you’ve got log backups throughout the day scheduled for every 15mins. And your job is set to run every 5mins. The job fires off, checks that it’s in the log timeframe, sees that it’s only been 5mins since the last backup; there’s nothing for it to do so it ends. 5mins later the job fires up and sees it’s been 10mins since the last log backup; nothing to do so Then 5mins later it sees that it’s been 15mins since the last log backup so it takes the log backup and all is well. The cycle continues. So you can see that working between the job schedule and the FrequencyMins col can be a very flexible tool.
and don’t forget that jobs can have more than one schedule so you can even change it from every 10mins during the day to every 5mins or every 1min at night.
Anyway, I don’t know if you wanted anything this thorough, but I like to fully explain these things.

Post Your Public Answer

Your name (required)
Your email address (required)
Answer (required)
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found