As far as I can see you can set the schedule on the group rescource. And I 
do belive it overrides what else might be set on the clients, although I 
don't know that for sure.

**************************************************
Med venlig hilsen / Regards
Kenneth Larsen
Steria
Tonsbakken 16-18
2740 Skovlunde
kel AT steria DOT dk - 44506261 - 26306261
**************************************************
With a revenue of 1.1 billion Euro and more than 9,000 employees, Steria 
is one of the top ten IT services companies in Europe. 
Steria Denmarks ambition is to reach a yearly growth of 20% in the coming 
3 years. Our focus expertise is in:  e-Business, e-Government, 
Outsourcing, Infrastructure, CRM and Workflow.



Davina Treiber <treiber AT HOTPOP DOT COM> 
Sent by: Legato NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
16-02-2005 11:27
Please respond to
Legato NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please 
respond to
Davina Treiber <treiber AT HOTPOP DOT COM>


To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
Re: [Networker] Scheduling






Siobhan Ellis wrote:

> That's what I thought. There was a suggestion of using one client 
definition
> and putting it in multiple groups. That is where you have the single
> browse/renetion policy issue. If you ahve separate clients, then that
> resolve sthat issue - but creates another... if you change the saveset
> definition, you now have to change it as many times as you have a copy 
of
> that client. Either way, the management starts to become onerous.


S[iobha|hau]n,

This seems to be a common problem. To me, the idea of having perhaps 3
client resources for a large number of clients is unacceptable due to the
management headaches you mentioned.

There are two ways round this, neither is perfect, although one could be
perfect with a small code change to NetWorker.

(1) Use a single client resource for each client, each client resource 
would
be in three (?) groups using different pools. For clarity the pools would 
be
named based on the intended retention. The client resources would be 
defined
using the longest retention required. After the backups have been taken
(suggest once weekly) a script is run from cron to amend (decrease) the
browse and retention of each save set (using nsrmm) in each of these pools
to match the desired retention. I have such a script written and tested 
and
in regular use on a site I previously worked at.

(2) Again use a single client resource for each client, and again each
client would be in three (?) groups using different pools. Override the
browse and retention defined on the client resource from the group. This 
can
be done using the -w and -y parameters to the savegrp command. For clarity 
I
would probably define a special policy (very long) for the clients called
something like "using group policy".

The snag with option 2 is that this can only be done when running savegrp
from a command line or an external scheduler. Most people prefer to use 
the
NetWorker scheduling tool. One workaround is to place savegrp inside a
wrapper script that somehow looks up the desired browse and retention 
based
on the group name or some other factor such as dates, then adds 
appropriate
values for the -w and -y commands. I can supply more detail if anyone
requires it.

Option 2 could be perfect if the override values for browse and retention
could be specified in the group resource. We know this is possible because
the same mechanism is available for the schedule attribute. I have 
suggested
this several times on this list but no-one from Legato Engineering has yet
picked up my good idea. Siobhan, do you still have any good contacts in
Engineering to suggest this to?

Tell us more about this tool that your company has...

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=