cancel
Showing results for 
Search instead for 
Did you mean: 

Calender Issue

H_Sharma
Level 6

Hello Experts,

We have a Policy aaa. Below is the schedule.

1:-Incremental:- Backup window 9 am to 6 pm - sunday to friday- Calender Based and (excluded saturday)

2:-FULL Full :- Bakcup window 9 pm to 9 am - saturday only - Frequncy based with (once in a week)

Problem Description:- Incremental Backup started on 9 am schedule on friday got completed in 3: 35 pm interestingly as soon as incremental
got completed at 3:35 pm on friday it got kicked off again.


What i concluded is as backup windows was from 9 am till 6 pm backup got completed at 3:35 pm however, backup windows
is still open and calender could not see any incremental backup on saturday as on saturday full backup was there it fot kicked if off again.
But the quetion is we have only 6 schedules on calender it should not run again. It did its part on friday.

Its my understanding. 

Attached are the full and incremental exclude options.

Pls help me to understand what exactly had happened?

1 ACCEPTED SOLUTION

Accepted Solutions

sdo
Moderator
Moderator
Partner    VIP    Certified

Did you any of these as well:

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

...or:

b) Rename the schedule?

...or:

c) Both of the above?

...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?

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

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

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

5) Did you amend the frequency?

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

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

View solution in original post

10 REPLIES 10

sdo
Moderator
Moderator
Partner    VIP    Certified

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

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

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.  

H_Sharma
Level 6

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.

sdo
Moderator
Moderator
Partner    VIP    Certified

Did you any of these as well:

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

...or:

b) Rename the schedule?

...or:

c) Both of the above?

...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?

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

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

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

5) Did you amend the frequency?

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

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

H_Sharma
Level 6

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.

 

 

sdo
Moderator
Moderator
Partner    VIP    Certified

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:

Event Event Time What was the scheduling at the time What Happened
A Wed 25th 15:00 15:00 to 18:00 = 3 hrs incr started
B ? 15:00 to 18:00 = 3 hrs incr completed
C Thu 26th 15:00 15:00 to 18:00 = 3 hrs incr started
D Thu 26th 16:00 09:00 to 18:00 = 9 hrs window changed, whilst incremental was running
E ? 09:00 to 18:00 = 9 hrs incr completed
F Fri 27th 09:00 09:00 to 18:00 = 9 hrs incr started
G Fri 27th 15:35 09:00 to 18:00 = 9 hrs incr completed
H Fri 27th 15:35 09:00 to 18:00 = 9 hrs incr started
I ? 09:00 to 18:00 = 9 hrs incr completed
J Sat 28th 21:00 21:00 to ?       = ? hrs full started

.

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? 

H_Sharma
Level 6

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 :)

 

sdo
Moderator
Moderator
Partner    VIP    Certified

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).

H_Sharma
Level 6

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.

H_Sharma
Level 6

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