Thought I might add my $0.02 worth... :) I agree with
you, Davina, a way to override the browse/retention on
group or client would be nice. If you could set
browse/retention on the pool, then you could use
levels in the pool definition together with
browe/retention to accomplish the desired effect.

Only question is, is it worth trying to make this an
RFE with Legato...?

// Matts

 --- Davina Treiber <treiber AT HOTPOP DOT COM> skrev: > On
Wed, 5 Feb 2003 11:27:40 -0500, Charles Gagnon
> <charlesg AT UNIXREALM DOT COM>
> wrote:
>
> >We want/need to have different retention/browsing
> times depending on
> >the backup schedule.
> This is actually quite a common requirement, and one
> that NetWorker does not
> handle particularly well.
>
> > The only way we have found to do this is:
> >
> >MachineA
> >    Group: DailyBackups
> >    Pool: DailyBackups
> >    Schedule: Incremental Daily, skip friday &
> weekends
> >
> >MachineA
> >    Group: WeeklyBackups
> >    Pool: WeeklyBackups
> >    Schedule: Full on friday, skip otherwise
> >
> >Having two pools makes sense since the data in one
> pool will expire
> >faster than the data in another. So don't want to
> mix them on the
> >same medias.
>
> This is one of the best reasons there is for
> creating multiple pools. Some
> users (particularly novices) can get a bit carried
> away with creating pools
> and later (when it's too late) discover that it
> wasn't such a good idea
> after all. This is the right time for doing multiple
> pools.
>
> >
> >But already, listing the same machine twice is not
> really nice (but
> >there is not way around that is there?), but two
> have two groups on
> >top of that just complicates things.
>
> Two (or even three or more) client definitions for
> the same client is
> strictly the right way to accomplish this. But it's
> horrible and unwieldy,
> especially if you have a couple of hundred clients.
> Putting the same client
> in two or more groups helps, and allows you to split
> the data into different
> pools as well as overriding the client schedule with
> the group schedule.
> Unfortunately there is a little piece missing from
> the jigsaw (ARE YOU
> LISTENING LEGATO????). What is required is a way to
> override the retention
> (and browse) on the group in the same way as we can
> the schedule. This seems
> like such an obvious enhancement and it would be
> sooooo convenient.
>
> The only way I know to work round this is to
> override the retention and/or
> browse on a per pool basis AFTER the backup. The
> nsrmm command allows you to
> modify the browse and/or retention on a per save set
> basis. It is quite a
> simple script to update the browse/retention of all
> save sets in a pool to
> the correct period after the savetime. I have such a
> script if required. It
> probably only needs running about once a week.
>
> I hope this helps.
>
> --
> Note: To sign off this list, send a "signoff
> networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's
> Web site at
> http://listmail.temple.edu/archives/networker.html
> where you can
> also view and post messages to the list.
>
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

_____________________________________________________
Gratis e-mail resten av livet på www.yahoo.se/mail
Busenkelt!

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