Forum Discussion

Jevon's avatar
Jevon
Level 4
11 years ago

Wrong schedule running when duplicating start times

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.

7.5
Backing Up
Backup and Recovery
Configuring
Linux
NetBackup
  • Andy_Welburn's avatar
    Andy_Welburn
    11 years ago

    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.

10 Replies

Sort By
  • Andy_Welburn's avatar
    Andy_Welburn
    Level 6
    11 years ago

    Have they got exactly the same window start time?

     

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

  • quebek's avatar
    quebek
    Moderator
    11 years ago

    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's avatar
    Marianne
    Level 6
    11 years ago

    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's avatar
    Jevon
    Level 4
    11 years ago

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

  • Andy_Welburn's avatar
    Andy_Welburn
    Level 6
    11 years ago

    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's avatar
    Jevon
    Level 4
    11 years ago
    # 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's avatar
    Andy_Welburn
    Level 6
    11 years ago

    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's avatar
    Marianne
    Level 6
    11 years ago

    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's avatar
    Jevon
    Level 4
    11 years ago
    • 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's avatar
    Andy_Welburn
    Level 6
    11 years ago

    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.