Forum Discussion

Yusoff's avatar
Yusoff
Level 3
12 years ago
Solved

Calendar Schedule resetting the selected days

I've a backup policy that makes use of the Calendar Schedule feature of NetBackup 7.0, running on RHEL 5.2. The schedule is set to run only on the last day of the month. However, everytime I check the policy a few days later, I noted the schedule reverted to its original setting, where first day and last day of the month, and weekends are also checked. This resulted in my backup job running on days other that the last day of the month as intended. This have been confirmed to be a recurring issue and I've confirmed that no one is tampering with the policies.

Any idea what could be causing my backup policy calendar schedule to reset? Is there something else I need to configure beside the obvious settings in the policy tabs?

 

7.1.x and Earlier
Backing Up
Backup and Recovery
Configuring
Linux
NetBackup
  • Yasuhisa_Ishika's avatar
    Yasuhisa_Ishika
    Level 6
    12 years ago

    I have never heard such issue. It is possible that someone or some script initiate restore of files under /usr/openv/netbackup/db/class/policy_name/schedule/schedule_name.

    Please check mtime and ctime of files. if mtime is reset to date before you changed schdule settings, this file must be restored by someone at ctime's date.

  • huanglao2002's avatar
    huanglao2002
    Level 6
    12 years ago
    can you try to disable the policy,and create a new policy instead.
  • Stumpr2's avatar
    Stumpr2
    Level 6
    12 years ago

    ya know..I like huanglao2002's suggestion to create a new policy. If this is for full backups which normally is for end of month backup then it could remain in its own policy with only the specified end of month backup schedule.

  • Stumpr2's avatar
    Stumpr2
    Level 6
    12 years ago

    uh oh. Do you really mena NetBackup vesion 7.0? look at this technote.

    http://www.symantec.com/docs/TECH161431

    Problem
     

    The NetBackup policy scheduler NBPEM (NetBackup Policy Execution Manager) is not honoring the retries after runday setting.

    Example: A monthly Full calendar schedule is set to run on the last Friday of the month.
    The monthly Full calendar schedule does not have an open window on the last Friday of the month but instead is configured with open windows on Saturday and Sunday.
    The schedule is set for Retries allowed after runday.

    In this configuration NBPEM did not schedule the monthly Full for either Saturday or Sunday during the open window.
     

    Error

    No visible error is noted.

    The client backup is missed and a manual backup is required to complete the backup.
     

    Environment

    Master Server
    Windows 2008 Server
    NBU Version: 6.5.6

    Cause

    Enable Retries allowed after runday to have NetBackup attempt to complete this schedule until the backup is successful. With this attribute enabled, the schedule attempts to do run, even after a specified run day.

    Note: An open schedule window on the runday is not required.

    The NetBackup policy scheduler nbpem (NetBackup Policy Execution Manager) is not honoring the retries after runday setting and the effect is a skipped client backup.

    Solution

    The formal resolution to this issue (Etrack 2361594) is included in the following releases:

    • NetBackup 7.1 Maintenance Release 4 (7.1.0.4)
    • NetBackup 7.5

    More information on these releases is available at the following link:
    http://www.symantec.com/business/support/index?page=landing&key=15143

    Workaround:
    Create a schedule with an open window on the runday.

    In this example, if the calendar full is scheduled for the last Friday of the month, the work around is to create an open window on Friday.

     

  • Yusoff's avatar
    Yusoff
    Level 3
    12 years ago

    Thanks for the replies.

    Based on the inputs, I will do the following:-

    1. As per Yasuhisa suggestion, I will do a quick check on the time of the files. This is unlikely as no restore was ever scheduled, be it manually or automatically. However, no harm checking it out.

    2. As per huanglao suggestion, I will create another policy to try out and see if the issue recurs.

    The Monthly Full policy is standalone i.e. it only has one schedule that is suppose to run on the last day of the month. I have a separate Daily Incremental and Weekly Full policies, using frequency based schedule and I have no issues with these two.

    For my Monthly Full policy, I've actually created an open window everyday from 1600 to 2000, since the last day of the month could fall on any of the weekday or weekend. The technote highlighted by Stumpr2 does not match my current problem however.

    I'll post my update once I tried out the two above.

  • Yusoff's avatar
    Yusoff
    Level 3
    12 years ago

    Update:-

    1. I checked the mtime and ctime of the files in the schedule using the "stat <filename>" command. The last modified time tallies with the time when I rectify the days of the schedule. Based on this, I can safely confirm that no modifications was done to the calendar schedule.

    2. I've created a new identical policy and disabled the original. I'll have to observe this for a few days and see if the issue occurs on the new policy. *fingers crossed* I'll post the update again in a few days.

     

  • Yusoff's avatar
    Yusoff
    Level 3
    12 years ago

    After a few days and several random checks, the new policy is working as intended. For reasons unknown, there's some issue with the original policy causing the schedule dates to reset.

    I've marked huanglao post as the solution. Probably once I have more time, I'll dig deeper to find out what's the root cause of the issue.

    Thanks all.

  • huanglao2002's avatar
    huanglao2002
    Level 6
    12 years ago

    Thanks Yusoff.

    From your experence do a test is very important when we encount some backup issue.

  • huanglao2002's avatar
    huanglao2002
    Level 6
    12 years ago

     I'll dig deeper to find out what's the root cause of the issue.

     

    #if  we need detail info, it should inspect nbpem verbose logs.