One advantage I can think of for having multiple indexes for same client
is that it would make it much easier and faster to run a command like
nsrinfo against one of the constituent parts (indexes). For example, if
I have a client with 5 file systems, and say 3 client instances, maybe
the index is really huge, but if I could put each of these three
instances under its own index, it might make managing the indexes more
efficient as none of them would be as large as the former whole.
Also at some point I might decide to move one of the indexes. If I move
it, I'd like to run nsrinfo before and after to ensure no differences.
This can take a long time on a large index, but if multiple indexes then
I'd only have to run it on the one affected piece and not on all the
indexes. Obviously, running it on all of them would take just as long as
it would if they were all lumped under one index like before but just
seems kinda risky to have huge indexes, but if you need the browse time
then seems less likely to get corrupt if broken down?
Any ideas on how to do this or advice on this?
Thanks.
George
Darren Dunham wrote:
>
> > We have several other client instances for this same host. These back up
> > other savesets outside the purview of the "special data" mentioned above
> > and actually comprise the majority of the data on this client. I have
> > the browse policy on these instances set to 'Quarter' (3 months). My
> > thinking was that a 6month browse policy for instance 1 would be
> > independent of the other instances since they use a separate browse
> > policy, so the other ones could not take advantage of the 6month browse
> > policy used by the first client instance and start eating into that.
>
> I don't understand what you're saying here. But yes, the browse policy
> can be independent for the separate instances.
>
> > So, I guess I'm asking if being able to have more than one index for
> > this host would benefit us or be a preferred method over the way we're
> > doing it now?
>
> The "index" just contains all the information about recovery. It's
> dependent on the browse policy and the number of files. The different
> pieces are independent within the "index", so splitting it shouldn't get
> you anything.
>
> > My goal is to keep the index as small as possible but
> > still allow 6month on the first instance and 3month on the others. Since
> > I don't know a way to do this using more than one index, of if our
> > release of NetWorker will even support it, I've been forced to lump
> > everything under one roof (one index), which might be increasing the
> > size of the index?
>
> No, I don't see why that would affect the size.
>
> > I would think our separate browse policies would
> > control or segregate this and prevent the others from eating into that
> > 6month portion used by the first instance but not certain? Just don't
> > know if there might be a better way to control the size of the host
> > index other than reducing the browse policy so I was thinking about
> > multiple indexes.
>
> Nope. You've got it.
>
> --
> Darren Dunham ddunham AT taos DOT
> com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
