Superseed rule did not work on march 2012

[pageup]

Hi

We are facing a problem in Backup Exec 2010R3 (Servicepack 2).
This march our superseed rule for weekly and monthly backup jobs failed.

So, I try to explain the configuration we are using:

We have weekly and monthly backup jobs.

The weekly jobs are running every friday of a week, starting 21:00.
The monthly jobs are running every last friday of a month, starting 21:00.

So, this means that weekly and monthly jobs would run together every last friday, but we have set a superseed rule in the policies to avoid this.
(we won't have duplicate backups)

The monthly jobs are superseeding the weekly jobs if the starttimes are concurrencing.
This worked for years without any problems, every last friday of a month, just the monthly backup jobs were started.

But the 30rd march 2012 this failed, and weekly backups were running, the monthly did not superseed.
 

Is this an known bug or what ever?

For other customers we are using the same configuration, but not every customer did have the same problems.

[Colin_Weaver]

I suspect this was a DST (Daylight Savings) issue. The known issues with DST cause problems the first time after the DST change that a specific job runs, now your weekly job probably already sorted itself out the week before, but your monthly job may have incorrectly set at start time at the end of Feb (for the end of March Job) that was 1 hour different when we actually got to the end of March due to DST.

Your weekly job was one hour different the week before but then scheduled itself correctly for the repeat this week resulting in the start time not conflicting and both jobs therefore trying to start (one hour apart)

If you check the Job History (make sure you are not in the Job Log Tab) of the Monthly job and the last 3 weekly jobs you might see some oddities reported against the "Original Start Time" value in the Job Summary Section 

With older versions of Backup Exec (2010 R3 and earlier) there is no fix for DST related things like this, you just have to work around them when they occur - Backup Exec 2012 has a completely rewritten scheduler that should handle DST changes correctly.

[pageup]

The DST change was on 25.3.2012...

So if I do understand correctly:

The last month job did run 24th february (correctly).
So the scheduler startetd counting the time to start the next job without taking notice of the DST change?

Which means in thruth the job starteted not really at 21:00, it started at 22:00 (summer time)?

Nothing to see in the job history, the weekly and monthly jobs did start at exactly the same time.
(this is confusing).

[Colin_Weaver]

OK it may not be DST that affected you but just to explain further (this is a relatively hard thing to explain simply)

In Versions of Backup Exec 2010 R3 and older, the next time a job is scheduled to run is actually set at the end of the previous job in the same Job schedule and is unaware of DST at that point in time

So with a weekly job, at the end of each weekly job, the next time the same job is set to run is specified in our database and the time stamp that is used at this point in time is unaware of DST so if we are in GMT at the time the next start time will also be GMT. This is even if the DST change occurs between the end of the job that has just run and the actual start time that the next weekly job should run, hence you will either see the job start an hour out from expected time, or it will fail with missed job window (depending on other settings)

The Monthly job will do the same thing at the End of the Feb job it will set the beginning time for the End of March job based on GMT as well

Now if the previous job ends within DST (say GMT+1) then it will schedule the next occurrence of the job for DST as well it is only when the previous job and the next job are either side of the change that problems are seen. Similar problems can happen at the end of DST as well.

Hence my suspicion that you issue might have been DST related that somehow separated the start times of your weekly and monthly jobs meaning the rule would not apply and both would run

Note: If I am correct your end of April job won't have a problem and additionally Backup Exec 2012 is the only permenant solution as we won't be fixing DST issues in older versions.

[pageup]

Ok, I did understand how and why. Thanks a lot.

And it was exactly as you said, monthly jobs did not start due time aviability window was closed before the job did start.

So, the weekly jobs were last run on 23rd march (before DST change).
The last monthly job was running on 24rd february.

Both before the DST change.
But it really seems like the superseed rule did not apply because of the DST change.