John Gowing wrote:
>
> 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.)
Do you really suggest to write indexes and bootstraps to a standalone
tape drive ?
It almost implies that you are going to append the same tape for a while
(unless you have a "monkey" that swaps the tapes every day or so). IMHO,
doing that you put all your eggs in one basket (unless you have another
clone volume elsewhere). What happens if the tape goes bad at some point
and you can't restore anything from it ?
While this is a good idea, I would not use a standalone drive for it. To
me it makes much more sense to use a small pool of tapes with a cone
within a tape library.
> 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Yuri Pismerov, Sr. System Administrator,
TUCOWS.COM INC. (416) 535-0123 ext. 1352
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
