Networker

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

2003-07-18 10:57:37
Subject: Re: [Networker] Retention policies revisited (need advice)...
From: Michael Brooks <MichaelB AT SEQUOIAINS DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Fri, 18 Jul 2003 07:57:26 -0700
i would like to confirm that this method solves the problem for backups.
however, if you are cloning these savesets then you will find that the
cloned media will "revert" to the longer retention period. this is due to
the fact that when you attempt to create a clone pool that "captures"
bootstraps and indexes, you will find that you are unable to specify the
groups to attach it to. this is a known bug to legato (RFE LGTpa35740), and
they state it will be fixed in the next release.

michael brooks ................ michaelb AT sequoiains DOT com
Network Administrator ......... 831.657.4539 phone
Sequoia Insurance Company ..... 831.657.4512 fax


> -----Original Message-----
> From: John Gowing [mailto:johng AT SOURCECONSULTING.CO DOT ZA]
> Sent: Friday, July 18, 2003 1:53 AM
> To:
> Subject: Re: [Networker] Retention policies revisited (need advice)...
>
> Hi,
>
> Some thoughts on the issue.
>
> Your assumption re index retention periods is correct, and
> logical, since those indexes contain references to savesets
> with retention periods.
>
> Remember the golden rule . . .tapes will be retained until
> the saveset with longest retention period has expired.
>
> We normally recommend our coustomers to use a separate pool
> for indexes and bootstraps.(and if necessary a separate
> device attached to the Networker Server, this is often a
> useful task for an older standalone tape drive.) The logic
> here is that you need these savesets when you need to restore
> the server, and to have them handy on separate tapes
> simplifies finding them.
> Also in a config with one or more storage nodes, it also
> ensures that the Bootsraps and indexes reside on a drive
> actually attached to the server, which also simplifies
> NWServer restores.
>
> To do this create a pool, called BootDex or whatever, limit
> access to specific devices if desired, under savesets enter
> "Bootstrap" and "Index".
> this will "trap" bootstrap and index savesets, directing them
> to your special pool.
>
> Lastly, remember to add these savesets to your offsite
> cloning procedures if used, and update the DR procedure to
> grab these tapes during an evacuation,
> ;-)
>
> If you need to clean up your current tape collection, use
> NSRSTAGE to move the existing index savesets to your new
> BootDex Pool (See NSRSTAGE manpage).
>
> Hope this helps
> John Gowing
>
> ----- Original Message -----
> From: "Craig Ruefenacht" <Craig.Ruefenacht AT US.USANA DOT COM>
> To: <NETWORKER AT LISTMAIL.TEMPLE DOT EDU>
> Sent: Friday, July 18, 2003 1:15 AM
> Subject: [Networker] Retention policies revisited (need advice)...
>
>
> > 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.
> > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> --
> 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=