In regard to: Re: [Networker] Make Expired Volumes Browseable, Davina...:

Tim Mooney wrote:

Here's one thing I've never really understood: why separate your index
savesets from your data?  I don't get what the advantage is, so we've
never done that here.  Our indexes save to the same pool/tapes as the
actual saveset data and their browse/recover period is the same as the
saveset data.

Can anyone enlighten me on this issue?  I know there are plenty of sites
that are saving indexes separately so there obviously has to be a valid
reason for it.

The usual reason is to speed up a DR situation, so that when you do an
nsrck -L7 for all clients it does not need to read dozens of tapes.

Thanks Davina!  That makes sense.

There are other situations where it may be beneficial. Some sites have
lots and lots of pools (bad practice IMHO).

When I was first learning NetWorker (13 years ago!) the 3.x manuals didn't
do as much to direct one away from lots of pools as the modern manuals do,
so I chose lots of pools for out site.  What's worse, I mixed clients with
different browse and retention periods in the same tape pools.

We've since remedied both issues, though going to just three pools took us
a while.

In this scenario if you were
backing up some data to a storage node in one pool, NetWorker would need
to unmount the tape from the storage node and remount it on the server.
The worst case of this is where you have non-shared libraries, and
perhaps just a small library for just the server. In this case you could
need to have lots of tapes labelled in various pools on the server just
to write indices.

Ah, that too makes sense.  We have two full servers with no
storagenode-only systems (our primary server is located in a remote
datacenter where no client data exists), so I've never needed to worry
much about storage nodes.

There are valid arguments NOT to have a separate pool for indices too.

There are also arguments both ways for backing up the indices all
together in one group rather than with the data groups.

Thanks for the explanation, that helps to clear up one of the things I've
always wondered about.

Tim
--
Tim Mooney                                             Tim.Mooney AT ndsu DOT 
edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER