Davina,
I would like a copy of the script , if you don't mind.
Also how are you handling off-site tapes ?
Do you clone ?
        If Yes do you send the clone tapes off-site and if you do how do
u handle not keeping two sets of        tapes (both the orginal and the
clone).
          IF Yes and you dont send the clones off site, do you scratch
(delete from the media database) the    clones after some periord of
time so you don't have dup tapes for the full retension cycle?
          If none of the above what do you do?

Ed Skolnik
The Interpublic Group Of Companies, Inc.
Shared Services  Chicago System Administrator
676 North St. Clair Street
Chicago, Illinois 60611
Phone: 312-425-6554
Fax: 312-425-6924
e-mail: eskolnik AT Interpublic DOT com



-----Original Message-----
From: Davina Treiber [mailto:treiber AT HOTPOP DOT COM]
Sent: Wednesday, February 05, 2003 11:25 AM
Subject: Re: Different Retention per backup levels


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

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