cancel
Showing results for 
Search instead for 
Did you mean: 

Calandar based incrementals fail to run on schedule if manual is run early (6.5.2a)

Chris_Valentine
Level 3
I have now upgraded to 6.5.2a and we have about 3 machines who's calendar based schedule is set for 10:40pm-12am each night and sometimes these jobs have to be put on hold that night (because of maintenance on them) and released the following morning with a manual backup run to catch any changes.  With 6.5.1 I could run the manual and later that night the scheduled inc would also run without a problem.  Now with 6.5.2a if I run the manual at 8am the 10:40pm scheduled job doesn't run does anyone know why this would happen now? Thanks, -CV

 

11 REPLIES 11

Rakesh_Khandelw
Level 6
Just double check if your schedule is still calendar based or 6.5.2a did something funky and made it frequency based. If it is still calendar based, please contact Symantec Technical Support and escalate it right away, this may be one of the bug with 6.5.2 or 6.5.2.a

Giroevolver
Level 6
Did you ever get a fix for this issue as I get exactly the same and am unable to run a manual backup without the schedule later in the day not running.

alazanowski
Level 5
We had a similar situation happen when we performed an upgrade. Recreating the policy from scratch (not copying) resolved it.

netbackup_rooki
Level 4
Certified
what is the frequency set to.. I had heard there was issue in 6.5.2a but should have been fixed in 6.5.3.

Apparently the issue also existed in 6.5.3.. you may need to apply 6.5.3.1.

http://seer.entsupport.symantec.com/docs/311581.htm


brlawson
Level 3
I am having a similar problem with calendar based policies on RHEL 5 with Netbackup 6.5.3.1.

Occasionally, a nightly backup will fail (forgot to load the tapes) and I need to run it the next morning when I come in. On our old 5.1 NBU machine, I created a manual version of each of my daily, weekly and monthly policies and use them to do emergency manual backups. That keeps them from interfering with the regularly scheduled backup that evening.

On my 6.5.3.1 machine, I did the same thing, but every time I run the manual (say, daily) policy in a morning, that evening, the regularly scheduled policy (daily) fails to run with the famiar 196 error - my backup window closed. If, for instance, the policy for that evening is one of the others (say, weekly), it will run just fine.

These are all calendar based policies and the manual policies were copied and modified from the regular policies. I keep all of the manual policies activated with an empty starting time grid so they never auto launch.

What am I doing wrong?



rjrumfelt
Level 6
So when you run a manual backup, it sometimes fails with a 196?  This to me seems more like a resource issue than a scheduling issue.  If it were a scheduling issue, such as the one in the OP, it would just not run that evening, but it sounds like you backup kicks off, but it just stays queued up for the duration of the backup window?

Dion
Level 6
Certified

There is a bug with version 6.5.2 to 6.5.3.  As far as I can recall, you will need to upgrade to at least 6.5.3.1 or higher to remove the problem.

The bug that occurs is around using calendar schedules which will only run a specific backup/schedule once per day.  If you do a manual backup earlier on in the day, the schedule backup will not run later (you can use nbpemreq command to take a look at what is scheduled to run for a specific date).

Until you can upgrade your system you should be able to work around the problem when you have to run a job manually by running the job manually again when it is scheduled to run.  If you leave the job (skipping the scheduled run) it should run fine the next day.

Bit of a pain but the upgrade will solve the actual problem

brlawson
Level 3
Dion,

I am running 6.5.3.1 and I am not running the same policy manually.

For years on NBU 5.1, I have had a workaround where I created a second policy for each of my calendar scheduled policies and used them to run an emergency off schedule backup. That has always worked fine. However, on my 6.5.* install, that has never worked and I don't know why. I am ready to put the new machine into production and am trying to clean up leftover problems.

I am upgrading to 6.5.4 today, but am not optimistic that it will fix this.

Brandt

Omar_Villa
Level 6
Employee
Since Symantec performed a big change over teh nbpem process on 6.5.1 all the scheduler it have been kind of messy, upgrade your client to the latest version of NBU and see if that helps, other way open a case for Symantec because it points to be a bug on nbpem.


regards.

brlawson
Level 3
For what it's worth, I updated to NBU 6.5.4 and I created a new daily policy from scratch instead of copying one from my calendar scheduled daily policy. I ran a manual daily backup yesterday morning and last night, my scheduled daily policy ran just fine. Apparently, copying a policy to a new name brings along some attribute that causes this interference.

I kinda doubt that the 6.5.4 update was the fix - anyone know for sure?

Brandt

CRZ
Level 6
Employee Accredited Certified

I would be willing to bet that applying 6.5.4 DID address your issue - although I'm not sure which specific issue you were experiencing, so I can't prove it by throwing you a specific Etrack number.

There have been A LOT of scheduling fixes between 6.5.1 and 6.5.4, and you can check the Tech Alerts and 6.5.4 READMEs if you don't believe me.  I see over a dozen resolved Etracks containing "schedule" in the 6.5.4 README alone - and that's JUST counting in the 6.5.4 section!

(This is part of why we in Support always harp on you to always have the latest Release Update installed.)

I WILL say that recreating your policy from scratch may also have helped towards your resolution, too, though.  :)