09-30-2013 08:00 AM
Anybody ever see this before? This occurs only with Enterprise vault policies and only after I changed the start windows to be more efficient. There is literally plenty of time to start the jobs yet when the backup window opens and the job kicks off it fails with a status 196 within a matter of seconds. The following is from the job details:
9/29/2013 7:00:06 PM - end Enterprise Vault Resolver, Persist Discovery; elapsed time: 00:00:00
9/29/2013 7:00:06 PM - begin Enterprise Vault Resolver, Policy Execution Manager Preprocessed
Status 196
The backup window opens at 7 PM
I don't see anything within NBU that would cause this to happen. Can't see the EV side being an issue. Manual backups run fine. The Master server has been rebooted and the clock is in sync between the Master, Media and client..
Any thoughts?
Solved! Go to Solution.
10-01-2013 01:40 AM
Corruption can occur but quite often it is just that the way NetBackup now works is to set timers for when a job is due to kick off
If you edit a job but it does not get picked up to re-set the timers the job can kick in at the wrong time only to find it does not think it has a valid window
It is always good practice to run the nbpemreq -updatepolicies when ever you make any policy or schedule changes
I dont see anything wrong with the schedules so either the timers have not been reset / policy read correctly or corruption has crept in
Hopefully after you re-created the schedules you ran the nbpemreq command, although a deletion and re-add may have forced the re-read anyway
09-30-2013 11:25 AM
Please attach Policy attributes
bppllist <policy_name> -U
09-30-2013 11:38 AM
09-30-2013 11:48 AM
Jeff,
Please collet the logs for vxlogview.
And upload them...
09-30-2013 12:34 PM
Policy Name: Enterprise_vault_closedpartitions_tice
Policy Type: Enterprise-Vault
Active: yes
Effective date: 08/05/2013 10:59:41
Mult. Data Streams: yes
Client Encrypt: no
Checkpoint: no
Policy Priority: 0
Max Jobs/Policy: Unlimited
Disaster Recovery: 0
Collect BMR info: no
Residence: stu_disk_ticsnbapd1
Volume Pool: NetBackup
Server Group: *ANY*
Keyword: (none specified)
Data Classification: -
Residence is Storage Lifecycle Policy: no
Application Discovery: no
Discovery Lifetime: 28800 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: Windows-x86 Windows2003 parev01
Include: EV_CLOSED_PARTITIONS=JournalVaultStore
EV_CLOSED_PARTITIONS=MailboxVaultStore
Schedule: EV_ClosedPar_Full
Type: Automatic Backup
Maximum MPX: 1
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
Allowed to retry after run day
Day 1 of month
Residence is Storage Lifecycle Policy: 0
Schedule indexing: 0
Daily Windows:
Sunday 19:00:00 --> Sunday 22:00:00
Monday 19:00:00 --> Monday 22:00:00
Tuesday 19:00:00 --> Tuesday 22:00:00
Wednesday 19:00:00 --> Wednesday 22:00:00
Thursday 19:00:00 --> Thursday 22:00:00
Friday 19:00:00 --> Friday 22:00:00
Saturday 19:00:00 --> Saturday 22:00:00
Schedule: EV_ClosedPar_Daily
Type: Automatic Backup
Maximum MPX: 1
Synthetic: 0
Checksum Change Detection: 0
PFI Recovery: 0
Retention Level: 2 (5 weeks)
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
Day 2 of month
Day 3 of month
Day 4 of month
Day 5 of month
Day 6 of month
Day 7 of month
Day 8 of month
Day 9 of month
Day 10 of month
Day 11 of month
Day 12 of month
Day 13 of month
Day 14 of month
Day 15 of month
Day 16 of month
Day 17 of month
Day 18 of month
Day 19 of month
Day 20 of month
Day 21 of month
Day 22 of month
Day 23 of month
Day 24 of month
Day 25 of month
Day 26 of month
Day 27 of month
Day 28 of month
Day 29 of month
Day 30 of month
Day 31 of month
Last day of month
Residence is Storage Lifecycle Policy: 0
Schedule indexing: 0
Daily Windows:
Sunday 19:00:00 --> Sunday 22:00:00
Monday 19:00:00 --> Monday 22:00:00
Tuesday 19:00:00 --> Tuesday 22:00:00
Wednesday 19:00:00 --> Wednesday 22:00:00
Thursday 19:00:00 --> Thursday 22:00:00
Friday 19:00:00 --> Friday 22:00:00
Saturday 19:00:00 --> Saturday 22:00:00
09-30-2013 12:58 PM
Above, backup begins at 7PM and your Schedules show 11AM-1PM.
So your backup is outside the window.
* edit *
I see you changed that to 1900-2200. After modifying the Policy, run
nbpemreq -updatepolicies
09-30-2013 01:40 PM
Yea, posted the wrong policy output initially. I do have the same issue with a few different EV policies. I saw a thread from a while back where Mark thought there could be policy corruption and suggested the deletion and re-creation of the policy. Now I don't know that it needs to be that extreme in this case When I run the backups manually they run fine... Since that bypasses the scheduler I would think if there is an issue at all here its with the schedules, (which btw have been modified often in the last few weeks). I have just deleted the schedules, saved the policy then went back in and added fresh schedules back. I'll keep you posted on the outcome tomorrow.
10-01-2013 01:40 AM
Corruption can occur but quite often it is just that the way NetBackup now works is to set timers for when a job is due to kick off
If you edit a job but it does not get picked up to re-set the timers the job can kick in at the wrong time only to find it does not think it has a valid window
It is always good practice to run the nbpemreq -updatepolicies when ever you make any policy or schedule changes
I dont see anything wrong with the schedules so either the timers have not been reset / policy read correctly or corruption has crept in
Hopefully after you re-created the schedules you ran the nbpemreq command, although a deletion and re-add may have forced the re-read anyway