eject job - not ejecting on the right date

[cyberninja]

Hello,

We just added a 2nd tape library to our NetBackup environment. The new tape library is not ejecting on the same day as our 1st one. How can I make sure that the 2nd tape library ejects on the same day as the other one. We have are tapes eject every two weeks or ever other Friday. We have our tapes eject every two weeks because they go off site. We have the vault job run the same day as the tape pick up. The vault jobs run on a single schedule. There is a vault job for each library.

Envirement
Master server           Solaris 10   running NetBackup 7.5.0.7
Media/robot control server       Solaris 10 running NetrBackup 7.5.0.7

1st  tape library    SL150
2nd tape library    SL500

[Marianne]

Did you go through all the steps to add the new robot as another Vault robot and a new profile for this robot?

Can you show us screenshots of the new vault profile? 

Have you added this new profile to the vault policy?
Please show us the policy config:

bppllist <policy-name> -U 
 

[Mark_Solutions]

I assume you are using frequency based scheduling for the vault policies...

If so then other than using lots of exclude dates etc. you can never guarantee that you will keep then in sync.

A work around would be to use calendar scheduling and have them eject on the 1st and 3rd Friday of the month .. they will always do it on the same day then.

Hope this helps

[cyberninja]

Marianne,

Did you go through all the steps to add the new robot as another Vault robot and a new profile for this robot? We made a new robot.

Can you show us screenshots of the new vault profile? We can't send you a screenshot, sorry.

Have you added this new profile to the vault policy? We made a new profile for the new library
Please show us the policy config:

bppllist <policy-name> -U Not shore what the policy name is?

My co-worker is getting ready to post addition info.

[cyberninja]

Mark,

Yes we are using frequency based scheduling. If we used calendar scheduling how would we get it to eject ever two weeks? Some mouths have more week some have lass.

[randes_2000]

I work with cyberninja and I created the policy. I'll try to fill in the details. This system is on our high side, so I cannot post any screen shots.

Marianne, I went through all the step to set up a new vault robot/job and created this new policy to run it. This policy is running a vault job that only performs an eject.

Mark, you are correct, we are using frequency based scheduling. The policy is working, except that the Friday it runs is out of sync with the day our vendor picks up our offsite tapes. I created the policy on 9/19 and ran it manually. I expected the next scheduled run to be on 10/3, but it ran on 9/26. Our pickup schedule is 9/19, 10/3, 10/17, etc. The policy is running on 9/26/ 10/10, etc. How do I get the policy back in sync?

[Mark_Solutions]

You will need to set exclude date(s) for the new policy for the Fridays when you do not want it to run .. you may need to run it manually the first week if it is not actually due to run .. but it should be ok after that. so you may get away with just the one exclude date.

Calendar would be better but i guess that would need you to manually enter every friday you want it to run .. having said that once you have done one schedule you can then copy it to the other policy

[mph999]

What frequency do you have set, eg once a day, once a week ?

[cyberninja]

We have the vault job set for evry 2 weeks. We have the tape pickup for off site evry two weeks. We try to vault the morning of the tape pickup.

[Mark_Solutions]

When using frequency always use less than the window you need .. so if you have a window set on fridays and want it to run every 2 weeks set it to every 10 days so that it is always ready to run... i think that is what Martin was wondering .. but to get back in sync you will need to set an exclude on the new policy, maybe run it manually the first time ,,, or set specific calendar dates .. good to change them to run every 10 days while you are doing it..

[mph999 · Accepted solution]

Yes Mark, that was what I was originally thinking, but I see in the explanation that the policay was run manually, but then ran sooner than expected, when it should have been another 7 days later ...

" I created the policy on 9/19 and ran it manually. I expected the next scheduled run to be on 10/3, but it ran on 9/26."

So, thought I'd ask about the freq anyway, as this would obviously cause this issue, though I suspect it has been checked.

Persoanlly, I'd run nbpemreq -subsystems 1 screen and look down for the Client/ Policy pair and see when NBU is next planning to run it - if it's n the correct date, no issue, if not, it shold give the logic behind why it will run it at time X.

If output is large, it gets truncated, so if the bits you need are missing, run it without the 'screen' and look for the details in the nbpem log.

[randes_2000]

Sorry for not posting a solution to this before now. Working with Symantec support we were able to resolve this issue.

It seems that whenever you change the scheduling within a policy, Netbackup ignores the Frequency set in the policy and simply looks for the next Start Window.   That was certainly the case for us.  We were able to view this using the command nbpemreq

nbpemreq -due -date <mm/dd/yyyy HH:MM:SS> -policy_filter <valid policy>

This showed us the next time Netbackup would run the policy in question.

The solution to correcting the timing was to simply run the policy manually to establish the date/time that Netbackup would start the clock for the settings in the policy.

So mph999 you were right on track, however the solution was to set the Frequency and Start Window in the policy (and leave it) and then run a manual backup to establish the date/time reference.  I was changing the policy to try to estabish a date/time reference.   This was actually killing my attempt to fix.  Simple fix when you know the tools and solution.  Thanks all for the assistance.

[cyberninja]

My co-worker randes_2000 posted the solution we got from tech support. It is awaiting moderation at this time.