Jack,

What we did to get around this was to create a client instance of our
Networker server, set it to a schedule that skipped all days, and set
the retention/browse policy to the shortest retention/browse policy that
we use in all groups.  This in effect creates a client instance which
will never get saved (because the schedule is "skip" for all days).

We then added this client instance of the Networker server to all save
groups in which the Networker server was not already a part of.

This works because the on-line client index files physically reside on
the Networker server, so when a save group completes and the on-line
indexes are backed up, Networker looks in the current save group for the
Networker server, and if it finds it, uses whatever retention policy is
defined there.  If the Networker server is not part of the individual
save group, Networker looks for all client instances of the Networker
server and uses the longest retention period it finds defined for all
client instances of the Networker server.


On Mon, 2004-05-10 at 14:29, Jack Lyons wrote:
> It seems that my indexes are creating problems with my retention policies.
> I may have a tape that should expire 1 month, but the expiration date is 1
> year from the backup and it is because it is backing up the client indexes.
> Is there a way around this, I know that some people advocate backing up
> indexes to a different pool but I would rather avoid that if possible.
>
> Jack

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