NetBackup 7.5.0.5 - How to clear recurring scheduled jobs

[PDragon]

Situation - We have the following policy's with the following schedules.

Policy: sql_Transaction_Log
Schedule: Full_Top_Hour - Starts @ 12:00:00
               Full_Bottom_Hour - Starts @ 12:30:00

The jobs do not start at these times however as they are starting at the perdicted times of "Wed Aug 21 13:45:39 2013 & Wed Aug 21 13:15:38 2013"

My question is how do you clear or purge the perdicted times?

[Marianne]

'Next' runtime is calculated based on start time of last successful backup.

Are you using Calendar or Frequency schedules?

Please show us entire schedule portion of 'bppllist <policy-name> -U'

[PDragon]

Here is the schedule

Schedule:              Full_Top_Hour
    Type:                Automatic Backup
    Frequency:           every Hour
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Sunday     12:00:00  -->  Monday     12:00:00
          Monday     12:00:00  -->  Tuesday    12:00:00
          Tuesday    12:00:00  -->  Wednesday  12:00:00
          Wednesday  12:00:00  -->  Thursday   12:00:00
          Thursday   12:00:00  -->  Friday     12:00:00
          Friday     12:00:00  -->  Saturday   12:00:00
          Saturday   12:00:00  -->  Sunday     12:00:00

  Schedule:              Full_Bottom_Hour
    Type:                Automatic Backup
    Frequency:           every Hour
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Sunday     12:30:00  -->  Monday     12:30:00
          Monday     12:30:00  -->  Tuesday    12:30:00
          Tuesday    12:30:00  -->  Wednesday  12:30:00
          Wednesday  12:30:00  -->  Thursday   12:30:00
          Thursday   12:30:00  -->  Friday     12:30:00
          Friday     12:30:00  -->  Saturday   12:30:00
          Saturday   12:30:00  -->  Sunday     12:30:00

And what I find odd is even though I have it set to every hour, the perdict script tells me it wont start until the next day.

[watsons]

As Marianne pointed out, you need to check when was your last backup. Quite likely it was last run on 12:45 & 12:15. 

To make it run again on every "half past", manually start a job by the time you need. 

For example, if the last job took 2 minutes to run and complete, and your current time is 15:50, then manually run the next job on 16:28, so when it completes in 16:30, your next schedule job will be 17:30.

Please note with frequency backup, be prepared the time to run backup will slip sometimes (just like what you are now experiencing). Because if your previous job fails, you will usually re-run the job on a different time. So if you successful job completes on 16:43, the next schedule job will be 17:43.

[PDragon]

Thanks for the explination. I do understand the points of the last run time and start time. But I dont seem to be making my point clear as explaining the mechanics is not answering my question.

So I have a job that kicks off from running it manually and it completes with in 30 minutes

Its scheduled to start @ 15:00:00 and end 15:00:00 the next day every day of the week

But after it runs and I run the command to see the next time its going to run, instead of showing it scheduled in the next 900 seconds....it shows its scheduled to run the next day.

00 W2K8CLS1SQL4         sql_W2K8CLS1SQL4-INST04_Trans 30min                0          Thu Aug 22 12:19:38 2013

The jobs start and stop fine, the run times are short, less then 30 minutes.So that does not explain why the perdict time is showing its next run time as being the next day.

[watsons]

Have you run "nbpemreq -updatepolicies" after you changed it to every hour?

How did you run your predict command?

Take a look at this one too: https://www-secure.symantec.com/connect/forums/single-policy-multiple-schedules

[PDragon]

I ran the predict command like so with a grep command to see only the Transactional policy's

nbpemreq -predict_all -date 08/22/2013 22:00:00 | grep Trans

00 wsqlprd11.main.pssworldmedical.com sql_W2K8PRDSOLO_Trans 30min                0          Wed Aug 21 22:28:06 2013
00 W2K8CLS1SQL1         sql_W2K8CLS1SQL1-INST01_Trans 30min                0          Thu Aug 22 11:42:08 2013
00 W2K8CLS1SQL5         sql_W2K8CLS1SQL5-INST05_Trans 30min                0          Thu Aug 22 11:42:55 2013
00 W2K8CLS1SQL4         sql_W2K8CLS1SQL4-INST04_Trans 30min                0          Thu Aug 22 12:19:38 2013
00 W2K8CLS1SQL3         sql_W2K8CLS1SQL3-INST03_Trans 30min                0          Thu Aug 22 14:11:22 2013
 

And no I did not use the updatepolicies argument.

PS: I did update the frequency and then ran the command, and then did a manual of said jobs.When I did the predict times were removed. After two of them completed the same predict time showing tomorrow came back. At the same times I might add, almost like they are stuck on those times.

00 W2K8CLS1SQL1         sql_W2K8CLS1SQL1-INST01_Trans 30min                0          Thu Aug 22 11:42:08 2013
00 W2K8CLS1SQL3         sql_W2K8CLS1SQL3-INST03_Trans 30min                0          Thu Aug 22 14:11:22 2013

[PDragon · Accepted solution]

Update: So the times listed above, I decided to just sit back and let them come and go. After the predicted times passed and the jobs kicked off, they started working in 900 second intervals. I have changed nothing and it just started working. So it would appear that the resolution for jobs that are showing the next day instead of hourly, or every half hour (depending on your setup) is to just let the predicted time come to pass and NBU will allign itself.

[PDragon]

One thing to note: We had to reboot our NetBackup Master Server. After which the scheduled jobs for the 30 minute transactionals kicked off, after they all completed, instead of being scheduled to run 30 minutes from the previous job. They were instead scheduled for the next day just like before. So this problem is re-producable and seems to resolve it self once you let that first predicted time run.