Calender Issue

My advice, is to try it the other way around...

Incremental, frequency based, window is 9am to 6pm, is 9 hours, so have a frequency window of 10 hours

Full, calendar based, every saturday, 9pm to 9am, so ensure 'retries allowed after run-day is selected.

And this may help you understand scheduling:

https://www-secure.symantec.com/connect/articles/netbackup-frequency-based-scheduling

I agree with sdo.

I prefer to stick to Frequency schedule for daily and weekly and only use Calendar for schedules that cannot be done with Frequency, like monthly and yearly.  

Thanks for the solution.

But any guesses what had caused the incremental backup to run two times on friday? I remeber one more thing

I had changed the incremental backup schedule starting from 3 pm to 9 pm to 9 am to 6 pm on thrusday and on friday this incident had happened. However i did not make any change for calender or frequncy based option.

Sudo thanks :) I see a ray of hope that i am going to reach to any solid conclusion. As i could see many quesitons ha ha :)

Ok here we go...

Did you any of these as well:

a) Delete, and re-create the schedule, even if you used the same name or not?

...or:  No I didnot 

b) Rename the schedule?

...or: No I didnot 

c) Both of the above?

       No I didnt.

...if so, then NetBackup considers it to be a new schedule, and so will run it at the first opportunity.

.

1) If you only changed the run window... then did you change it more than once?

Ans:- I cleared the old one timing 3:00 pm to 6:00 pm and changed the timings to 9 am to 6 am and saved it. 

2) And, at what time did the previous schedule run, before the two runs that you mention?

Ans:- The actual backup window was 3 pm to 6 pm and incremental backup was running at that time around 4 pm when i changed the timings  to 9 am to 6 am on 26th Mar and last got completed on 25th.

Issue came up when i changed the timings only from 3 pm to 9 am morning.

3) And, at what time did the two runs, that you mention, run?

Ans:- On 27th 9o clock incremental started and ran till 3:35 pm and suprisingly strated at 3:35 pm again.

4) What was the frequency of the schedule before you made any modifications?

Ans:- It was calender based.

5) Did you amend the frequency?

Ans:- No...Not at all.

6) If so, how many times, and to what values and when?

Ans:- No i didnot make change on the frequecy. i just changed the timings only on calender and saved it...

7) What was the frequency just before the first normal run, and just before the second unexpected run?

Ans:- it was calender and calender till issue came up. still its calender.

Let me add one more thing today is full backup schedule at 9:00 PM and full is running. No incremental had happened today.

I'm trying not to get confused - in this last post you say (two times) that the run window was amended:

...old:   15:00  to   18:00  = 3 hrs

...new:  09:00  to  06:00  = 21 hrs

...however, in your previous posts you say (four times) that you amended  it:

...old:   15:00  to   18:00  = 3 hrs

...new:  09:00  to  18:00  = 9 hrs

...so, I'm going to assume the times mentioned in your previous posts are correct.

.

Here's my attempt at an event timeline:

.

This is pure guess work, but what may have hapenned is that:

- at event C, PEM initiates schedule and also loads it's internal scheduling database with the next expected run (i.e. plans ahead ro run again at 15:00 on 27th).

- at event F, PEM initiates schedule and also loads it's internal schedulign algorithm with the next expected run (i.e. plans ahead to run again at 09:00 on ? (Sunday?)) - but does not remove the planned next run for 15:00 on 27th.

- at event G, PEM realises that it's planned event is now possible, and so runs the job (event H).

If true, then I would say that you've discovered a feature (sometimes known as a bug).

I believe that PEM does not re-evaluate the entire set of policies and schedules at every 'scheduling interval', because this is CPU expensive and can take a long time for large sites - and so, instead, that it uses some form of internal database, and only re-evaluates the next possible run, as and when jobs either start or when they finish (i.e. when PEM tell JM to start a job, or when JM tells PEM that a job has finished), or perhaps based upon the time of policy amendment (i.e. re-evaluates policies amended since it's last evaluation run).  Such an algorithm would smooth out the CPU impact of job scheduling.  I suspect that event F should have caused PEM to drop the planned run for 15:00 the next run, but maybe it doesn't by design, or because of a bug.  I'd think of this scenario as a 'PEM' evaluates next job, at job start' type scenario.

I wonder if we were to think in terms of a 'PEM evaluates next job, at job end' whether we would come up with a similar theoretical cause.

What version of NetBackup on master?  And which OS for master?

Overall, it's an interesting question.  Do you have Symantec Support?  Maybe they could perform RCA (root cause analysis).  But then again, is it really worth trying to identify root cause for something like this.  However, you used the term 'incident' earlier... Did your company suffer any harm/loss/penalty/cost because of this unexpected backup run? 

Thanks Sdo,

I really Appriciate your efforts...

Masert: - 7.6.0.1 win 2008 R2

Yes we have symantec support. No Company didnot suffer any loss. The time was changed at older time CPU utilzation was going up and impacting the database so we changed it to morning. If it happens on Friday again then this could lead to a escalation :(

To be very honest with you. It would take good time to grasp the whole concept...

Ok my policy schedule is like this.

1:- Full Backup:- (Frequency Based) Once in a week:- Sat 9 pm to sunday 9 pm :- No exclude date.

2:- Incremental:- (Calender Based) :- Sun 9 am to sun 6 pm(Sunday to friday)- saturdays are not selected in include date due to full backup on saturday

I mean its the same schedule in which incremental ran 2 times on friday. 

So do you think its fine and now incremental wont run twice on friday :)

No worries - I find that trying to hypothesize root cause helps us ask the right questions.

I actually think that it should run just fine next Friday... but I really would take Marianne's sound advice, and switch to frequency based, and I say that... because it is well known that mixing frequency and calendar based schedules can lead to confusing results.

IMO, I don't think there's any wrong with mixing, it's just that it becomes more difficult to understand.  And if you read that article by Dave Chappa (linked in my first reply/post above) then you should hopefully begin to understand the complexities.  So, I think Marianne is right, and that you could simplify your configuration by adopting frequency based schedules for this backup policy.

My tip for (when using simple) frequency based schedules is... to set the frequency to be one hour longer than the longest run window within the schedule.  This avoids 'schedule creep' (which you'll have to Google if you want to find out more) - but also means that - IF - you were to manually run an adhoc instance of the schedule, then there is a much greater chance that the next 'open' run window will (although possibly later than normally scheduled ) probably still run.  If this is confusing, then I must apologize, and instead perhaps recommend that if your working environment somehow dictates that you often have to manually run or re-run  'schedules' then maybe it would be better to have (pre-configured) manual schedules (without a run window) that you can run manually on an ad-hoc basis, so that normal scheduling does not get affected by a possible (but not always definite) delay caused by the frrequency of the previous ad-hoc manual run 'overlapping' in to the normal schedule run window(s).

Thanks Sdo,

Wonderfull support.. We did not change any schedule and left it with the older one That schedule did not run two times on friday. So i must say I would have accidently saved it two times and it ran two times.

Thanks Sdo. Appriciated much for your support. U rock :)