Networker

Re: [Networker] Can't get index to backup tocustom pool

2003-10-20 12:02:43
Subject: Re: [Networker] Can't get index to backup tocustom pool
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Mon, 20 Oct 2003 12:01:14 -0400
Well, what I want is this one particular client's index to go to this
"new" pool along with maybe /var. I want nothing else to go to this new
pool, though. Everything else should go to the normal nightly pool,
including the server. The idea of creating a second client instance of
the server, with an associated skip schedule, is an intruiging one, but
there's one problem. If I set the schedule to skip then the other client
might likewise skip since it would be a member of the same group. I'll
try it and let you know.

George


"VERHAEGHE Koen (BMB)" wrote:
>
> I see ...
> What we have here is 2 pools, none of them called Default (so we have
> zero tapes in he Default pool).
> One called Local the other Remote for obvious reasons. We want to avoid
> that backups use the very slow WAN, so I limited the pool Local by
> clicking all the drives of the server in the pool definition, and
> limited the pool Remote by clicking the drives of the remote storage
> node. This, together with the storage node affinity list, is working.
> All data, including the indexes of the remote clients, stay remote, and
> all local stuff stays here, also the indexes.
>
> This is what you want, right (oh, 6.1.1 on Solaris 8)
>
> Alternatively, you could create a client for the server and assign to a
> group using the "new" pool and have the schedule "skip". Never tested
> this, though.
>
> Cheers
> Koen
>
> -----Original Message-----
> From: George Sinclair [mailto:George.Sinclair AT noaa DOT gov]
> Sent: Monday, October 20, 2003 5:02 PM
> To: VERHAEGHE Koen (BMB)
> Subject: Re: [Networker] Can't get index to backup tocustom pool
>
> I was already aware of this. Thanks, though. Here are the details. Of
> course, we do have the primary server and one storage node server. I had
> 'nsrserverhost' listed first and the storagenode server listed second in
> the storage nodes fields for the server client instance.
>
> In regards to our discussion, what happens in this case is that the
> server will ask for a writeable tape to the "new" pool when it goes to
> back up its index. This occurs after it has already backed itself up to
> the normal pool. If you have such a tape in its library then you'll end
> up with one "new" pool tape on that library with only the server's
> indexes on it plus one "new" pool tape in the storage node server's
> library with the client's index on it. However, if you reverse the order
> of the values in the storage nodes field, or if you simply remove the
> 'nsrserverhost' value, then, yes, you will end up with the server's
> index and the client's index both getting written to the "new" pool tape
> in the storage node server's library. So, in this case, you won't
> require two sets of tapes, but both of these scenarios still result in
> two undesirable effects:
>
> 1. The server will back itself up to the normal pool.
>
> 2. The server will back up its index to the "new" pool.
>
> This is frustrating because I don't want anyone's index on this "new"
> pool other than the desired index. Even still, I sure as heck don't want
> the server to back itself up every time the client sends its index here,
> but that's what will happen. It's a no win situation because again, you
> have to have the server listed in the group if you select the group in
> the pool window and have the server listed below. And, you have to have
> the server listed below to get the other client index to backup to this
> pool. But, failure to select the group in the pool window means all
> clients will send their indexes to this pool.
>
> My solution is to avoid backing up the client index to this "new" pool.
> Instead, I will only back up one of its file systems (/var) to this new
> pool. The rest of the file system will go to the normal pool. When the
> backup completes, the client's index will get backed up to the normal
> pool also. This will not involve the server at all -- well, the server
> won't back itself up as a result, nor will it back up its index. I don't
> need to list the server below or even have it in the group. Finally,
> I'll come along maybe once a week or so and clone the client's indexes
> to a pool named "new_clone". So, I'll have client:/var all on pool
> "new", clones of these file systems on "new_clone" and clones of the
> client indexes on the clone pool as well.
>
> Not such a big deal because I would have wanted to clone the file
> systems anyway. I just won't have a separate original copy other than
> the one that's already going to the normal pool. The normal (nightly)
> pool tapes are recyclable after 6 months. "new" pool tapes will never be
> recycled. Can't really think of any better solution that doesn't involve
> really goofy strategies or a lot of hoops to have to jump through.
>
> George

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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Networker] Can't get index to backup tocustom pool, George Sinclair <=