Networker

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

2003-07-18 00:33:18
Subject: Re: [Networker] Retention policies revisited (need advice)...
From: Kit Cunningham <kit AT 4F.CO DOT NZ>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Fri, 18 Jul 2003 16:30:04 +1200
Your problem is that Group3 does not contain the networker_server as a client.
Thus when the client indexes backup it looks for the longest retention policy 
for the server.


Add a third networker_server client as part of group3. It need only backup one 
directory and can
even be a permanent skip schedule. Set the policies of this instance of the 
server as desired for
group3.

This will cause client index backups to take the retention period of this 
instance of the networker
server for group3.

Kit



On 17 Jul 2003 at 17:15, Craig Ruefenacht wrote:

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



++++++++++++++++++++++++++++++++++++++++++++++++
Kit Cunningham - idata Limited
Mobile  +64 21 448 444   email: k.cunningham AT idata.co DOT nz
Support Calls to:  0800 backup -         0800 222 587
Support email: support AT idata.co DOT nz
http://www.idata.co.nz
++++++++++++++++++++++++++++++++++++++++++++++++
CAUTION: This email and any attachments may contain
information that is confidential. If you are not the intended
recipient, you must not read, copy, distribute, disclose or
use this email or any attachments. If you have received this
email in error, please notify us and erase this email and any
attachments. You must scan this email and any attachments
for viruses. DISCLAIMER: i-data Limited accepts no liability for
any loss, damage or other consequences, whether caused by
its negligence or not, resulting directly or indirectly from the use
of this email or attachments or for any changes made to
this email and any attachments after sending by i-data Limited.
The opinions expressed in this email and any attachments are
not necessarily those of i-data Limited.
++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++
Kit Cunningham      email: kit AT 4f.co DOT nz
Four F Ltd               Mobile  +64 21 448 444
PO Box 500            Phone/Fax  +64 4 293 4484
Paraparaumu
New Zealand         Tread Lightly
++++++++++++++++++++++++++++++++++++++++++++++++

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