Which run days did you have checked. The one for the start of the start
windows, The end day of the start window or both. Were you trying to
get more than one full per week? I am using Solaris 9 just like you. I
have tried both the windows and the java gui's. I also had no rerun
after run date. I only saw the issue when I only had one run day
checked.
At first the run day was always the end of the start window but the
other 2 variations gave me the same issues. I am using a binary from
mp3 to fix vault/duplicate issues as well. (nbrb for Solaris) That
issue did not exist in 6.0 or mp1. I would be happy to send it to you
for additional testing if you still can not duplicate the problem.
After a bit of work Support was able to duplicate the issue and once
they did it was difficult to clear it up for them.
Thanks for your effort I understand if you are satisfied with your
findings.
Here is a bppllist -byclient aivas -L
For a working policy. This policy does not work when I change the
window to span from Friday to all day Saturday.
Policy Name: aivas
Options: 0x0
template: FALSE
c_unused1: ?
Names: (none)
Policy Type: MS-Windows-NT (13)
Active: yes
Effective date: 05/24/2004 00:00:00
Backup netwrk drvs:no
Collect TIR info: no
Mult. Data Stream: no
Perform Snapshot Backup: no
Snapshot Method: (none)
Snapshot Method Arguments: (none)
Perform Offhost Backup: no
Backup Copy: 0
Use Data Mover: no
Data Mover Type: 0
Use Alternate Client: no
Alternate Client Name: (none)
Enable Instant Recovery: no
Policy Priority: 0
Max Jobs/Policy: Unlimited
Disaster Recovery: 0
Collect BMR Info: no
Keyword: BMR Test Windows 2003 Box
Client Encrypt: no
Checkpoint: no
Residence: whitedragon_LTO2
Volume Pool: Full_Library_WIN
Client/HW/OS/Pri: aivas PC WindowsNET 0 0 0 0 ?
Include: C:\ECC\*
Include: C:\FabricManager\*
Include: C:\Program Files\ECC\*
Include: C:\Program Files\EMC\*
Exclude: (none defined)
Schedule: Full_Library
Type: FULL (0)
Calendar sched: Enabled
Friday, Week 1
Friday, Week 2
Friday, Week 3
Friday, Week 4
Friday, Week 5
Maximum MPX: 1
Synthetic: 0
PFI Recovery: 0
Retention Level: 4 (2 months)
u-wind/o/d: 0 0
Incr Type: DELTA (0)
Alt Read Host: (none defined)
Max Frag Size: 0 MB
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Daily Windows:
Day Open Close W-Open W-Close
Sunday 000:00:00 000:00:00
Monday 000:00:00 000:00:00
Tuesday 000:00:00 000:00:00
Wednesday 000:00:00 000:00:00
Thursday 000:00:00 000:00:00
Friday 017:00:00 024:00:00 137:00:00 144:00:00
Saturday 000:00:00 000:00:00
Schedule: Cumulative_Inc
Type: CINC (4)
Calendar sched: Enabled
Monday, Week 1
Tuesday, Week 1
Wednesday, Week 1
Thursday, Week 1
Monday, Week 2
Tuesday, Week 2
Wednesday, Week 2
Thursday, Week 2
Monday, Week 3
Tuesday, Week 3
Wednesday, Week 3
Thursday, Week 3 Monday, Week 4
Tuesday, Week 4
Wednesday, Week 4
Thursday, Week 4
Monday, Week 5
Tuesday, Week 5
Wednesday, Week 5
Thursday, Week 5
Maximum MPX: 1
Synthetic: 0
PFI Recovery: 0
Retention Level: 1 (2 weeks)
u-wind/o/d: 0 0
Incr Type: DELTA (0)
Alt Read Host: (none defined)
Max Frag Size: 0 MB
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Daily Windows:
Day Open Close W-Open W-Close
Sunday 000:00:00 000:00:00
Monday 004:00:00 010:00:00 028:00:00 034:00:00
Tuesday 004:00:00 010:00:00 052:00:00 058:00:00
Wednesday 004:00:00 010:00:00 076:00:00 082:00:00
Thursday 004:00:00 010:00:00 100:00:00 106:00:00
Friday 000:00:00 000:00:00
Saturday 000:00:00 000:00:00
-Jonathan Marks (970)295-5362
-----Original Message-----
From: bob944 [mailto:bob944 at attglobal.net]
Sent: Thursday, June 15, 2006 1:40 AM
To: Marks, Jonathan - Fort Collins, CO; 'Tristan Ball';
veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] whats wrong with my calendar based backup
> Support had me stop Netbackup and remove the file and then start
> Netbackup. I was told it would recreate that "pempersist"
> file. It did
> recreate the file but did not help get my fulls to run. I was using
> nbpemreq -predict -date XX/XX/XXXX XX:XX:XX with different dates and
> times to try and forecast what would run. I was very careful to use
> the -updatepolicies after any changes I made. This is important to
> note since there is a small possibility that some of the errors I saw
> after the initial failure was from the nbpemreq command. I tried to
> wait and see if the fulls ran at all, but after making a few changes
> such as the pempersist and waiting a week and then trying something
> else, I had to change my policies in order to have data backed up.
>
> I was always able to manually run the policy. Which I did for all
> affected policies when I discovered the issue.
Jonathan, I duplicated your symptoms today.
Took a Solaris 9 NetBackup 5.1MP4 lab server, added the simplest
possible policy to it with a frequency-based schedule and over-midnight
window. Copied that to a new policy and changed only the freq attribute
to calendar (more on this later). Made several variants of cal- and
freq-based, but that's not important here. Anyway, ran them both from
bpbackup -i and they worked fine.
Upgraded the server to 6.0MP2. All good running immediate backups. But
the calendar-based ones (new copy, with no "immediate" history) don't
run by the scheduler. Hmmm. Futzed with a lot of things, but mostly
relied on blowing away pempersist. That perks up the frequency-based,
but no-go on the calendar-based. Soooooo, _this_ is what Jonathan
meant... Changed all over-midnight windows (in the cal- policies first,
later on everything in the system) to not cross midnight (0000-2355).
Still no scheduled calendar-based backups.
Uninstalled MP2. Nothing changed. "Weird," sez I. There _have_ to be
a ton of customers using calendar-based scheduling even though _I_ think
it rots. What on earth could my setup have in common with yours to
where I'm seeing this on 6.0base and you on 6.0MP2?
One possibility came to me when I started writing this mail. Since I
don't use calendar-based scheduling, I muffed the basics: no run days.
DOH! Set a bunch o' rundays and the calendars fired off just fine at
2344 and 0000, as expected.
Changed the calendar schedules to span midnight (2300-2200). They fired
up just fine. Whew! At least base 6.0 handles calendar-based schedules
correctly, whether they span midnight or not. Speaking of midnight, I
didn't see the cal schedules run again at midnight. Maybe this means
that 6.0 "fixes" the logic which befuddles first-timers, or maybe I
didn't set up correctly to determine the behavior. Let's see what
happens when I put MP2 back in...
Okay, Jonathan, I have results: NetBackup 6.0MP2 starts calendar-based
schedules just fine, whether the schedule spans midnight or not. Just
got through the run of the 2300-2200 window. (And no 0000 rerun, so it
looks as if there's now logic to treat cal-based windows as an entity,
as they are in freq-based. This might be documented; I don't have time
to check.) Looks like your problem is specific to your setup. Good
luck.
The only way I've been able to duplicate your problem is by not having
appropriate rundays checked; perhaps that a good place to dig deeper.
Maybe post a bppllist.
|
