cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong schedule running when duplicating start times

Jevon
Level 4

Hey folks.

I have setup a few NetBackup policies to run full backups in a weekly/monthly/yearly fashion.  The three schedules have the following differences:

  • Retentions
  • Weeky is on "Frequency 1 Week"
  • Monthly is "1st Friday of the Month"
  • Yearly is manualy selected "1st Friday of the Year"

From what I was told, if you have multiple schedules for the same policy running at the same time, the schedule that had the oldest "Last ran" would execute and the others would be ignored.

I never had a problem betweek weekly and monthly, but the yearly didn't run Jan 3rd for some policies.  Instead, the monthly run. These policies are varied in type (*nix, Windows, VMWare, Exchange)

I have all sorts of workarounds in mind, but for a concise solution, I need to know where my logic is off.

1 ACCEPTED SOLUTION

Accepted Solutions

Andy_Welburn
Level 6

That's fine. I knew there was likely to be other factors to take into account so it was just a suggestion.

 

The point I made with the frequency was to try & show the more obvious impact - we've come across this more than once on the forum - but there is a more 'insidious' aspect we've come to know as 'schedule creep':

It could be due to resource limitations that a job may start a few minutes late - it will now always run a few minutes late. If it gets delayed again ......etc etc. This may well be more than a few minutes if no resources are available due to the fact that other backups are running for hours. Due to the fact that we (as backup admins) always seem to have a lot of backups to squeeze into the smallest possible time then, if something is delaying backups, we could be losing a 'window of opportunity' (pun intended!) to get our backups done earlier.

View solution in original post

10 REPLIES 10

Andy_Welburn
Level 6

Have they got exactly the same window start time?

 

Can we see an example of the policy? (bppllist policy_name -U)

quebek
Moderator
Moderator
   VIP    Certified

Hello

There is a recommendation from NBU that in a given policy schedules should be only from one kind, ie either frequency based or calendar based. These two types should have never been a part of the same policy.

Some strange things might happen when combining both in the same policy...

I am looking after TN stating this...

## Edit ##

to my surprise this link is not anylonger valid http://seer.entsupport.symantec.com/docs/303314.htm

I took it from my earleir post https://www-secure.symantec.com/connect/forums/backup-starting-yearly-or-monthly-instead-weekly

and now I found this one: http://www.symantec.com/business/support/index?page=content&id=TECH129503&actp=search&viewlocale=en_US&searchid=1389789282572

Looks like things are changing... per above now we can mix the schedules in one policy....

Marianne
Level 6
Partner    VIP    Accredited Certified

Yes, NBU manuals have always stated that Calendar and Frequency schedules should not be used  in the same policy, but many of us have been using them together for a long-long time with great success.

Yes, we used to have issues with wrong schedules kicking off, but we soon learned to bypass that with backup windows:
If weekly (Freq) and monthly (Cal) are due at the same time, we simply changed the monthly window to open about 15 minutes before the weekly window. 
Same with yearly (Cal). 

As per Andy's post - please post your policy config. 
We need to see schedules and open windows.

Jevon
Level 4

Do you not run into the situation where both schedules would run if you had different start times?

Andy_Welburn
Level 6

In my experience when we did this the monthly didn't run as the yearly was already active.

There certainly is the potential for both to run especially if the backup window is large enough.

Jevon
Level 4
# bppllist VMWare2-FS-17 -U
------------------------------------------------------------
 
Policy Name:       VMWare2-FS-17
 
  Policy Type:         VMware
  Active:              yes
  Effective date:      05/02/2013 12:26:20
  File Restore Raw:    yes
  Mult. Data Streams:  no
  Client Encrypt:      no
  Checkpoint:          no
  Policy Priority:     0
  Max Jobs/Policy:     Unlimited
  Disaster Recovery:   0
  Collect BMR info:    no
  Residence:           VMWare-Tape
  Volume Pool:         ENCR_Tape
  Server Group:        *ANY*
  Keyword:             (none specified)
  Data Classification:       Wood
  Residence is Storage Lifecycle Policy:    no
  Application Discovery:      no
  Discovery Lifetime:      -1 seconds
ASC Application and attributes: (none defined)
 
  Granular Restore Info:  no
  Ignore Client Direct:  no
Enable Metadata Indexing:  no
Index server name:  NULL
  Use Accelerator:  no
  HW/OS/Client:  vmx-08        windows7Serve FileServer
 
  Include:  ALL_LOCAL_DRIVES
 
  Schedule:              Yearly
    Type:                Full Backup
    Maximum MPX:         2
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     9 (infinity)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Calendar sched: Enabled
      SPECIFIC DATE 0 - 01/03/2014
      SPECIFIC DATE 1 - 01/02/2015
      SPECIFIC DATE 2 - 01/01/2016
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Friday     17:00:00  -->  Saturday   06:00:00
 
  Schedule:              Monthly
    Type:                Full Backup
    Maximum MPX:         2
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     8 (1 year)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Calendar sched: Enabled
      Friday, Week 1
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Friday     17:00:00  -->  Saturday   06:00:00
 
  Schedule:              Full
    Type:                Full Backup
    Frequency:           every 7 days
    Maximum MPX:         2
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     3 (1 month)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Friday     17:00:00  -->  Saturday   05:00:00
 
  Schedule:              Differential-Inc
    Type:                Cumulative Incremental Backup
    Frequency:           every 1 day
    Maximum MPX:         2
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (1 week)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Sunday     18:00:00  -->  Monday     05:00:00
          Monday     18:00:00  -->  Tuesday    05:00:00
          Tuesday    18:00:00  -->  Wednesday  05:00:00
          Wednesday  18:00:00  -->  Thursday   05:00:00
          Thursday   18:00:00  -->  Friday     05:00:00
          Friday     18:00:00  -->  Saturday   05:00:00
          Saturday   18:00:00  -->  Sunday     05:00:00
 

Andy_Welburn
Level 6

At first glance it seems that your schedules should work as expected, but if the yearly is causing an issue then you could tweak it slightly to start a few minutes earlier.

General suggestions:

- maybe the windows could be reduced? Unless there is a potential that your backup could start as late as 10 or so hours after the window actually opens, then a window doesn't need to be 11 hours. It is afterall only a window of opportunity during which a backup can start, it doesn't need to cover how long a backup will take.

- frequency. Drop the weekly frequency to 6 days or preferably much less (you could even drop it to as low as 13 hours - longer than the current window) and the daily frequency from 1 day to 12 hours. This will ensure that the jobs will always be in a position to start when the backup window opens. This is never more obvious than if you have to manually re-run a failed backup - the scheduler will wait until the frequency has passed after the manual backup before it will allow the job to run again, by which time the next window could have closed resulting in missed backups.

Marianne
Level 6
Partner    VIP    Accredited Certified

I have never seen issues with 2 schedules kicking off where we have implemented the '15 minute head start'.

nbpem will see that there is already a Full backup running for this policy and not submit another backup.

Jevon
Level 4
  • The backup "start window" is larger because, sadly, I don't have disk.  Everything is straight to tape. with limited drives where multiplexing doesn't fix everything. Sometimes, some jobs can suddenly take a few extra hours. (Nobody tells the backup guy anything).
  • I see where you are going with the frequency thing.  I haven't had a problem with this that I am aware of.  In fact, it may have worked to my advantage.

Andy_Welburn
Level 6

That's fine. I knew there was likely to be other factors to take into account so it was just a suggestion.

 

The point I made with the frequency was to try & show the more obvious impact - we've come across this more than once on the forum - but there is a more 'insidious' aspect we've come to know as 'schedule creep':

It could be due to resource limitations that a job may start a few minutes late - it will now always run a few minutes late. If it gets delayed again ......etc etc. This may well be more than a few minutes if no resources are available due to the fact that other backups are running for hours. Due to the fact that we (as backup admins) always seem to have a lot of backups to squeeze into the smallest possible time then, if something is delaying backups, we could be losing a 'window of opportunity' (pun intended!) to get our backups done earlier.