Policy Schedule - Frequency Issue.

[Gormag]

Environment: Solaris8, NBU4.5fp6

Below is an example of one of the policys I am having a problem with. As you will see the window is set to open at 18:00, but the problem I have is, nothing ever hits the queue until 20:50. I need to know what to do to push this time closer to 18:00.


Policy Name: General_lto

Policy Type: Standard
Active: yes
Effective date: 09/10/2004 18:00:00
Client Compress: no
Follow NFS Mounts: no
Cross Mount Points: no
Collect TIR info: no
Block Incremental: no
Mult. Data Streams: yes
Frozen Image: 0
Backup Copy: 0
Client Encrypt: no
Policy Priority: 3
Max Jobs/Policy: Unlimited
Disaster Recovery: 0
Residence: blah_1_lto
Volume Pool: blah_lto
Keyword: (none specified)

HW/OS/Client: Solaris Solaris8 1.blah.com
Solaris Solaris9 2.blah.com
Solaris Solaris8 3.blah.com
Solaris Solaris8 4.blah.com

Include: ALL_LOCAL_DRIVES

Schedule: Incr
Type: Differential Incremental Backup
Frequency: every 1 day
Maximum MPX: 16
Retention Level: 3 (7 weeks)
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Daily Windows:
Sunday 18:00:00 --> Monday 08:00:00
Monday 18:00:00 --> Tuesday 08:00:00
Tuesday 18:00:00 --> Wednesday 08:00:00
Wednesday 18:00:00 --> Thursday 08:00:00
Thursday 18:00:00 --> Friday 08:00:00
Friday 18:00:00 --> Saturday 08:00:00
Saturday 18:00:00 --> Sunday 08:00:00

Schedule: Full
Type: Full Backup
Frequency: every 7 days
Maximum MPX: 16
Retention Level: 3 (7 weeks)
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Daily Windows:
Sunday 18:00:00 --> Monday 08:00:00
Monday 18:00:00 --> Tuesday 08:00:00
Tuesday 18:00:00 --> Wednesday 08:00:00
Wednesday 18:00:00 --> Thursday 08:00:00
Thursday 18:00:00 --> Friday 08:00:00
Friday 18:00:00 --> Saturday 08:00:00
Saturday 18:00:00 --> Sunday 08:00:00

 

[Stumpr]

Change the daily incremental frequency to 16 hours vice 1 day

Bob Stump
Incorrigible punster -- Do not incorrige

 

[Stumpr]

Change the weekly to 156 hours vice 7 days

Bob Stump
Incorrigible punster -- Do not incorrige

 

[lenski]

Because the last backup was at 20:52 then the system waits one day before submitting the next backup which is at 20:52 the next day. So as Stumpr says reduce the frequesncy to less then one day. The frequesncy on jobs only needs to be a bit bigger than the window to stop it running twice in the same window.

 

[sebasg]

Anyone knows why Veritas doesn't recommend this for the daily backups (i.e. Frequency = 24 - <Window_Hours>), but it does recommend something like 4 days for the weekly backups?
Also, any reasons on why 156 Hs (6.5 days) and not 4/5 days?
Thank you!

S.

 

[Stumpr]

I think there was a technote onetime describing using a frequency that is a little bit larger than the window.
I learned from experience.
My suggestion for this particular schedule and the 156 hours is because of the daily open windows in the schedule. If you use days then it will not produce the desired frequency because a window is open every day.
The hours was a way to get around that without changing the open window.
It actually could be done by modifying the open windows and using a number of days as you suggested.

Bob Stump
Incorrigible punster -- Do not incorrige

 

[JayKoonz]

We have our weekly backups setup with a frequency of 1-day but a start window only open for about 8-hours one day on either Saturday or Sunday. This was changed after we had problems when someone ran a full backup during the week for a special occasion, and the weekly didn't run the following weekend cause it hadn't been a week yet.
But I never though about the fact that once a daily backup kicks off late, it will always kick off late if it's setup for a 24-hour frequency.