Networker

[Networker] Retention policies revisited (need advice)...

2003-07-17 19:17:51
Subject: [Networker] Retention policies revisited (need advice)...
From: Craig Ruefenacht <Craig.Ruefenacht AT US.USANA DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Thu, 17 Jul 2003 17:15:44 -0600
Hi everyone,

I'm not trying to sound like a broken record here, and I'm trying to be as
concise as I can be.   This is one of the last remaining issues I have to
resolve with our Networker system, which I inherited.

In early June there was a discussion on this mailing list about different
client retention policies.  I was one of a couple of people who posted with
problems with client retentions.  While the answers I got were helpful in
understanding the issue (and mostly confirmed what I had suspected), I was
unable to figure out how to get around my issue.  I put it in the background
for a while, but it has come to the foreground recently, and so I am
renewing my efforts to get it resolved.

In summary to June's threads, the issue boiled down to the retention policy
that Networker uses for indexes.  From a few posts, it is apparent that
Networker looks for the longest retention given for the server's client
definition, and uses that retention for the indexes

Here is my current configuration

Server: Networker 6.1.3 Network Edition Build 428
OS: HP-UX 11i on a K570
Clients: HP-UX, Solaris, Novell, Win2000

Group1
        Pool: DailySaves
        Schedule: Incr Mon-Sat, Full on Sunday, except for the
                   Networker server, which is Incr Mon-Sat, skip Sunday.
        Browse Policy: All clients set to Month
        Retention Policy: All clients set to Quarter
        Clients: A mix of HP-UX and Sun machines, Networker server is one of
them.

Group2
        Pool: FullSaves
        Schedule: Full on Sunday, nothing any other time
        Browse Policy: Sole client set to Month
        Retention Policy: Sole client set to 3 years
        Clients: The Networker server itself, no other clients.

Group3
        Pool: Novell and Windows
        Schedule: Incrs and Fulls spread out over the week
        Browse Policy: All clients set to Month
        Retention Policy: All clients set to Quarter
        Clients: A mix of Novell 5.x/6.x and Exchange

Our client list looks like this (in the Client Setup window of the nwadmin
GUI):

        networker_server (belongs to Group1)
        networker_server (belongs to Group2)
        UNIX-1 (belongs to Group1)
        UNIX-2 (belongs to Group1)
.       Novell-1 (belongs to Group3)
        Novell-2 (belongs to Group3)
        Win2000-1 (belongs to Group3)
        Win2000-2 (belongs to Group3)

I'm using generic names here.  Note that the networker_server is listed
twice - because it is in two groups.  One of the two networker_server
listings belong to Group1 and the other one belongs to Group2.  They are two
separate distinct groups.  Also note that each group uses its own tape pool,
each pool with their own unique tape media, i.e., no two groups share the
same tape pool nor media.

Here is my problem.  Before 4 months ago, Group2 didn't exist in our setup.
Before Group2 existed, the retention periods of tape pools used in Group1
and Group3 were set to 3 months.  After 3 months the tapes would expire and
be recycled, if they were not manually set to state recyclable first.

When we added Group2 to our setup (so that we could retain the full backups
of the Networker server for 3 years), all of a sudden, as tapes were
recycled and reused in Group1 and Group3, the retention periods for the
tapes in the pools used in these two groups was being set to 3 years!  The
tapes being used for Group2 were also being set to a 3 year retention, but
for Group2, that is what we wanted.

As I mentioned above, several of the posts in early June pointed to the fact
that the actual client savesets on the tapes for Group1 and Group3 do have
the correct retention of 3 months, and I have verified this.  But also on
those same tapes are the Networker server index backups, and Networker is
using the 3 year retention policy for the indexes, thus making the actual
volume have a 3 year retention period.

So it appears that to determine the retention policy for the index files,
regardless of what group is currently running, Networker is using the
***LONGEST*** retention policy that is defined for any save set of the
Networker server itself, regardless of what group the Networker server is in
and whether it is in multiple groups  (assuming that the Networker Server is
also a client that gets backed up).  In my configuration above, the
Networker server is the only Networker client that uses a 3 year retention,
as shown in Group 2.  No other client in any other group uses anything but a
3 month retention policy, and, in fact, in Group 1, the Networker server (as
a client of itself) uses a 3 month retention policy.  That's because we want
to do an incremental of our Networker server on Monday-Saturday and keep
that around for 3 months, but do a full of the Networker server on Sunday
and keep that around for 3 years.

It seems the way to fix this so that the tapes for Group1 and Group3 have
the correct 3 month retention is to force the indexes to be written to their
own tape pool (either the Default pool or some other pool).

So it boils down to this: How can I get Networker to either honor the
retention policy on a group-by-group basis, meaning set the client index
savesets to the ***LONGEST*** retention period that is defined within that
same group (don't look at any client or server-as-a-client in any other
group), or move all the index saves to their own tape pool while writing the
client savesets to the same pools they are being written to now?  I know
that some tweaking can be done in the pool definitions, but the
documentation (and other posts that have hinted at this) don't provide much
detail on how to do it right.

Keep in mind that this situation may be kind of a unique in that the
Networker server is a client of itself, and it appears in two different
groups and uses different retention policies in each group, and the longer
of the two retention policies is being used for ***ALL*** index saveset
retention policies for all groups.

--
Craig Ruefenacht
UNIX Systems Administrator
USANA Health Sciences, Inc.
(801) 954-7559



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