George, Itzak, Jason, Stan,
Thanks for your help and pointing me in the right direction. Up to now I
was not aware of the distinction between client "save set" and pool "save
sets" but it is a very important (and undocumented?) difference. For the
record, pool "saves sets" are actually partitions or mount points ONLY.
Client "save set" is a mount point, partition, directory, or subdirectory
(/user/home/oracle). The client save set does not seem to require
metacharacter escaping (i.e. "C:\temp" will work for a windows client on a
Unix server).
I took a modified approach to the 2 client, save set=All suggestion. For
readability, I created client 1 with no directives and put directories in
the save set list. For client 2 the save set list is All, and I put 'skip'
directives for each directory from the client 1 save set list. I found
this more readable as I can see exactly what specific directories are being
backed up from the client window. Client 1 and 2 are in different groups.
The pool is set up to take data from the group and has no save sets
specified. Works great.
However, I had a problem that took me a few days to resolve. Using global
directives, I learned that I must run the group that has the client that
specifies the save set All last. If I run it first then when the
group/client that has directory entries starts it would also skip the
directories. Even though the directive used by the All client skips the
index entries, when the other group rolls around it knows it visited that
file system before and so skips it again - even though the All client group
did properly skip directories per the directive instructions. Everything
seemed ok when I tested the 2 groups using 'savegrp -n', but the next day I
kept noticing the skipped files. I hope this makes sense - it's kinda hard
to explain.
In regards to the racing condition on the Index, my groups are pretty far
apart and so they complete in time. I run my savegrps from crontab, so if
I do encounter a race problem I'll probably ensure my All directives have
nulls in them and I'll put a '-I' in the other savegrp commands.
Thanks again...
Chuck Davis
Army Medical Surveillance Activity
Walter Reed Army Medical Center
Washington DC
On Mon, 23 Sep 2002 10:43:28 -0400, George Sinclair
<George.Sinclair AT NOAA DOT GOV> wrote:
>Well, I must admit that in the past there were at least two occasions
>where a client's (in this case, the same one) index became corrupt, and
>I suspect it may have had something to do with this race condition or
>contention as admonished in the previous update. I was never able to
>prove that this was the cause, however. That was quite sometime ago, and
>we have never had that occur again. We have several clients wherein we
>do this kind of tomfoolery, and I've never had any problems in say the
>last year and a half. I would add that in these cases, the groups may
>overlap, but they do NOT start at the same time. I would think that if a
>group needed to update the index, and the timeout is set high enough
>then NetWorker SHOULD simply wait until the other group that is writing
>to the index completes. Updating the index doesn't take the long, does
>it? I don't see why a group that needs to update the index couldn't wait
>if it's locked, but that's just my feeling. I don't consider my logic
>irrefutable by any means.
>
>George
>
>Itzik Meirson wrote:
>>
>> To the best of my understanding, Networker will backup the client index
as soon as all savesets for the specific client instance have completed.
>> During this client index backup the index is (Networker) "locked".
>> Having two instances of the same client run at the same time, either
within the same group or through different groups might cause sporadic
backup failures due to indexes unavailability.
>> I would appreciate if anyone could concur or contradict my statement.
>> HTH,
>> Itzik
>>
>> -----Original Message-----
>> From: Heller, Jason [mailto:Jason.Heller AT HARLEY-DAVIDSON DOT COM]
>> Sent: Saturday, September 21, 2002 00:39
>> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
>> Subject: Re: [Networker] saving sub-dirs to different pool
>>
>> I do/can accomplish what you are doing by having separate savesets. You
didn't want that, but it would let you backup everything from one group,
and use the "saveset" attribute of the pool.
>>
>> In Mr. Sinclair's example below, I'd recommend using the "NULL"
directive over the "SKIP" directive. Using skip might make the skipped
directory not show up for a recover unless you picked a browse time in what
might be a small window between the two saves. Null would avoid this by
still skipping the data, but logging in the index that the directory does
still exist.
>>
>> George - I like your idea, so that you can use "ALL"...can you run both
groups at the same(or near same) time without problems(other than
performance)? You would potentially cause two backup sessions at the same
time for the same saveset. Even though no data would conflict, I'm curious
if this would cause any other potential problems? I'm assuming it
wouldn't, but doesn't hurt to ask around.
>>
>> -Jason-
>>
>> -----Original Message-----
>> From: George Sinclair [mailto:George.Sinclair AT NOAA DOT GOV]
>> Sent: Friday, September 20, 2002 2:27 PM
>> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
>> Subject: Re: [Networker] saving sub-dirs to different pool
>>
>> You could create two instances of the client, each having a separate
directive. The first instance would be a member of group 1 under pool 1,
and the second would be member of group 2 under pool 2. Each client
instance would use its own directive. Client 1's directive would be set up
to back up everything but one of the sub-directories; this one it would
skip. Client 2's directive would be set up to skip everything but the
affected sub-directory. In this manner, both clients could list 'All' for
their savesets so you don't have to specifically list the savesets. We do
this all the time, only under Unix. I don't think it would be any different
for NT.
>>
>> George
>>
>> Stan Horwitz wrote:
>> >
>> > On Fri, 20 Sep 2002, Chuck Davis wrote:
>> >
>> > > Networkers,
>> > >
>> > > On an NT client, short of re-partitioning and creating additional
>> > > savesets, is it possible to direct subdirectories of a disk to a
>> > > separate pool?
>> >
>> > Local directives might be a useful tool for you.
>> >
>> > --
>> > Note: To sign off this list, send a "signoff" 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" 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" 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>>
>> *** eSafe scanned this email for malicious content ***
>> *** IMPORTANT: Do not open attachments from unrecognized senders ***
>>
>>
****************************************************************************
**********************
>> The contents of this email and any attachments are confidential.
>> It is intended for the named recipient(s) only.
>> If you have received this email in error please notify the system
manager or the
>> sender immediately and do not disclose the contents to any one or make
copies.
>>
>> ** eSafe scanned this email for viruses, vandals and malicious content **
>>
****************************************************************************
**********************
>>
>> --
>> Note: To sign off this list, send a "signoff" 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" 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" 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
