>Reading thru the archives, I noted many references to the "overnight
>quirks" of schedules
>slipping due to the " backup completed" time being used to determine
>when the next schedule is
Just for the record, please note that the above statement is
incorrect. It's a common question and a common misconception.
NetBackup uses the "backup time", i.e. the timestamp of the backupid
i.e. the backup job activation time, as the basis of its calculation
of whether or not a schedule has come due to be run again.
For example:
=============================
Suppose that you have a backup policy with a schedule that looks like:
-frequency of 7 days
-backup window every Friday from 8pm to 2am
And on Friday June 24th this backup job queues at 8:03, goes active
at 8:20, and finishes at 11:45.
Then Friday June 31st rolls around....
At what time will the NetBackup scheduler consider this schedule to
be due to run?
A) 8:03
B) 8:20
C) 11:45
D) it's a trick question.
=============================
the answer is, of course, D.
But if there WAS a June 31st, the answer would be B. ;-)
rob
>permitted to run, and can see that perhaps the weekies from last
>week took overly long
>to complete and thus none of them scheduled.
>
>There were two flaw's to the theory.
>1) one client had been trying valiently to do a weekly backup since
>monday. I killed it
>each day before completion, to force it to get "in sync" with
>everything else on Wednesday.
>It did not try on Wednesday.
>2) if the weekly backup schedule wasn't being triggered, why did the
>daily schedule not kick in
>
>One thing I have noted with the calendar scheduler, is that when
>scheduling by "days of week"
>the calendar display did not update with little green ticks on every
>wednesday. (trivial I know
>but it seemed odd - Administration console on Solaris)
>
>Does this sound like something any of you have seen before, or know
>a reason for?
>
>I'm a bit stumped, and I don't know what could be causing this.
>
>Thanks in advance
>
>-suz
>
>Example of backup schedule:
>
>Policy Name: fred
>
> Policy Type: Standard
> Active: yes
> Effective date: 01/01/1970 10:00:00
> Client Compress: no
> Follow NFS Mounts: no
> Cross Mount Points: no
> Collect TIR info: no
> Block Incremental: no
> Mult. Data Streams: no
> Frozen Image: 0
> Backup Copy: 0
> Client Encrypt: no
> Policy Priority: 0
> Max Jobs/Policy: Unlimited
> Disaster Recovery: 0
> Residence: (specific storage unit not required)
> Volume Pool: Bastion
> Keyword: (none specified)
>
> HW/OS/Client: Solaris Solaris8 fred
>
> Include: /
> /var
> /opt
> /home
> /var/log
>
> Schedule: monthly_archive
> Type: Full Backup
> Maximum MPX: 1
> Retention Level: 9 (infinity)
> Number Copies: 1
> Fail on Error: 0
> Residence: (specific storage unit not required)
> Volume Pool: (same as policy volume pool)
> Calendar sched: Enabled
> Allowed to retry after run day
> Day 15 of month
> Daily Windows:
> Sunday 20:00:00 --> Monday 01:30:00
> Monday 20:00:00 --> Tuesday 01:30:00
> Tuesday 20:00:00 --> Wednesday 01:30:00
> Wednesday 20:00:00 --> Thursday 01:30:00
> Thursday 20:00:00 --> Friday 01:30:00
> Friday 20:00:00 --> Saturday 01:30:00
> Saturday 20:00:00 --> Sunday 01:30:00
>
> Schedule: weekly_full
> Type: Full Backup
> Maximum MPX: 2
> Retention Level: 5 (3 months)
> Number Copies: 1
> Fail on Error: 0
> Residence: (specific storage unit not required)
> Volume Pool: (same as policy volume pool)
> Calendar sched: Enabled
> Wednesday, Week 1
> Wednesday, Week 2
> Wednesday, Week 3
> Wednesday, Week 4
> Wednesday, Week 5
> Daily Windows:
> Sunday 20:00:00 --> Monday 01:30:00
> Monday 20:00:00 --> Tuesday 01:30:00
> Tuesday 20:00:00 --> Wednesday 01:30:00
> Wednesday 20:00:00 --> Thursday 01:30:00
> Thursday 20:00:00 --> Friday 01:30:00
> Friday 20:00:00 --> Saturday 01:30:00
> Saturday 20:00:00 --> Sunday 01:30:00
>
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|