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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=