Backup Central

On Fri, 3 Dec 2004, George Sinclair wrote:

There are no error messages or strange warnings in the nsr daemon.log or
messages log files on the primary server.

Have you checked the nsr daemon.log and messages files on that slow poke
client? If not, you certainly should.

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

Hi,

We have this Linux client that is agonizingly slow to backup. It *WILL*
back up, but it takes hours, even to do an incremental, even against
something simple like /tmp. So if I launch a backup against this one
client from the GUI, for example, and I walk away, and I come back an
hour later, I will see nothing, I kid you not. Absolutely no activity
whatsoever. If I check group control window, the saveset 'All' is still
listed pending. Unbelievable! If I come back another hour later, same
thing. When I go home at night, though, and I come in the next morning,
it's done!

Its file systems are no bigger than any of our other clients. It's
running the same version of the OS (RedHat 7.3), and as near as I can
tell has the same setup. It's running the same version of the NetWorker
client software, too. Pinging the host produces normal timely responses,
same as other hosts on the network. Also, pinging machines from that
host works normal, too. This machine can access network with no problems
that I can tell, and the user never complains about being able to reach
other hosts, internet, etc.

This problem has existed as long as I can remember, so I don't know when
it first starting exhibiting this behavior. Here are its horrible
symptoms and some of the things I've tried to troubleshoot it:

1. Running the following commands on the client produce no output or
error messages to the console. They just hang:

nwadmin -s server
nwrecover -s server
recover -s server
save -s server -b pool -l i /tmp

2. Running a probe against the client from the primary server produces
nothing:
savegrp -pn c client group

3. Under save sets, changed 'All' to /tmp, placed client in its own
group and ran both full and incremental from GUI. Still nothing! Just
sits there. I can see that if a file system had like 50 million inodes
that maybe doing an incremental might take a while, but /tmp? Common!
Even a small file system like /var just sits dormant during backup. I've
seen huge RAID on other boxes run circles around this machine on a bad
day.

There are no error messages or strange warnings in the nsr daemon.log or
messages log files on the primary server.
I used rpm -e to remove the NetWorker client and then re-installed and
re-started the software. Still no luck. I moved the network cable (100
Mbit) to another port, still no luck. I even tried another network
cable, no luck. I shut down the host, and rebooted it. Nothing. I even
ran a check against the client index on the primary server as: 'nsrck
-L6 client'. No error messages or warnings, and it completed just dandy.
Didn't take long either. What and the heck is this machine's problem?!!!
It has plenty of memory, plenty of swap space, and it's doing NOTHING
when I've been running these tests. It's not like there's 100 users
logged in. Noone is logged in other than me. I've tried everything but
running something like ethereal (sp), but maybe I'm gonna have to start
analyzing packets here? Not too good with those kind of tools.

Any ideas on what to try?

Thanks.

George

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

You should try and run the Networker client (nsrexecd) manually in debug
mode (-D 9) and check if it ever receives the requests from the server
and whether it tries to reach back to the server.
The output is quite cryptic but might help you pinpoint to the problem.
Itzik

-----Original Message-----
From: Legato NetWorker discussion=20
[mailto:NETWORKER < at > LISTMAIL.TEMPLE.EDU] On Behalf Of George Sinclair
Sent: Friday, December 03, 2004 18:30
To: NETWORKER < at > LISTMAIL.TEMPLE.EDU
Subject: [Networker] No response from client
=20
Hi,
=20
We have this Linux client that is agonizingly slow to backup.=20
It *WILL* back up, but it takes hours, even to do an=20
incremental, even against something simple like /tmp. So if I=20
launch a backup against this one client from the GUI, for=20
example, and I walk away, and I come back an hour later, I=20
will see nothing, I kid you not. Absolutely no activity=20
whatsoever. If I check group control window, the saveset=20
'All' is still listed pending. Unbelievable! If I come back=20
another hour later, same thing. When I go home at night,=20
though, and I come in the next morning, it's done!
=20
Its file systems are no bigger than any of our other clients.=20
It's running the same version of the OS (RedHat 7.3), and as=20
near as I can tell has the same setup. It's running the same=20
version of the NetWorker client software, too. Pinging the=20
host produces normal timely responses, same as other hosts on=20
the network. Also, pinging machines from that host works=20
normal, too. This machine can access network with no problems=20
that I can tell, and the user never complains about being=20
able to reach other hosts, internet, etc.
=20
This problem has existed as long as I can remember, so I=20
don't know when it first starting exhibiting this behavior.=20
Here are its horrible symptoms and some of the things I've=20
tried to troubleshoot it:
=20
1. Running the following commands on the client produce no=20
output or error messages to the console. They just hang:
=20
nwadmin -s server
nwrecover -s server
recover -s server
save -s server -b pool -l i /tmp
=20
2. Running a probe against the client from the primary server produces
nothing:
savegrp -pn c client group
=20
3. Under save sets, changed 'All' to /tmp, placed client in=20
its own group and ran both full and incremental from GUI.=20
Still nothing! Just sits there. I can see that if a file=20
system had like 50 million inodes that maybe doing an=20
incremental might take a while, but /tmp? Common!
Even a small file system like /var just sits dormant during=20
backup. I've seen huge RAID on other boxes run circles around=20
this machine on a bad day.
=20
There are no error messages or strange warnings in the nsr=20
daemon.log or messages log files on the primary server.
I used rpm -e to remove the NetWorker client and then=20
re-installed and re-started the software. Still no luck. I=20
moved the network cable (100
Mbit) to another port, still no luck. I even tried another=20
network cable, no luck. I shut down the host, and rebooted=20
it. Nothing. I even ran a check against the client index on=20
the primary server as: 'nsrck
-L6 client'. No error messages or warnings, and it completed=20
just dandy.
Didn't take long either. What and the heck is this machine's=20
problem?!!!
It has plenty of memory, plenty of swap space, and it's doing=20
NOTHING when I've been running these tests. It's not like=20
there's 100 users logged in. Noone is logged in other than=20
me. I've tried everything but running something like ethereal=20
(sp), but maybe I'm gonna have to start analyzing packets=20
here? Not too good with those kind of tools.
=20
Any ideas on what to try?
=20
Thanks.
=20
George
=20
--
Note: To sign off this list, send a "signoff networker"=20
command via email to listserv < at > listmail.temple.edu or visit=20
the list's Web site at=20
http://listmail.temple.edu/archives/networker.html where you=20
regarding this list should be sent to stan < at > temple.edu=20
=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D=
*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D
=20

*************************************************************************=
*************************
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=20
sender immediately and do not disclose the contents to any one or make co=
pies.

MBI - System Team
*************************************************************************=
*************************

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu
=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D*=3D

I think the key here is:

"2. Running a probe against the client from the primary server produces
nothing: savegrp -pn c client group"

When you run a probe against the client it should return something. If it
is successfull sometimes as you say shouln't a probe eventually return
something?

My guess is either:

a.) It is having some network issue; bad connection/packetloss/routing..
.it may be having trouble getting back to the server...ie. you can get to
it but it can't back to the server. Did you try traceroutes on the
client out the proper interface to the backup server/storagenode that your
data travels on?

b.) It is an client software issue. Does savefs -p work on the client?
This is what probe runs, the software should function on the client in
some manner. The client software have been stopped, /nsr/tmp cleaned out,
and software restarted? It is possible the system needs to be rebooted.


Robert Maiello
Pioneer Data Systems



On Fri, 3 Dec 2004 11:30:12 -0500, George Sinclair
<George.Sinclair < at > NOAA.GOV> wrote:

Hi,

We have this Linux client that is agonizingly slow to backup. It *WILL*
back up, but it takes hours, even to do an incremental, even against
something simple like /tmp. So if I launch a backup against this one
client from the GUI, for example, and I walk away, and I come back an
hour later, I will see nothing, I kid you not. Absolutely no activity
whatsoever. If I check group control window, the saveset 'All' is still
listed pending. Unbelievable! If I come back another hour later, same
thing. When I go home at night, though, and I come in the next morning,
it's done!

Its file systems are no bigger than any of our other clients. It's
running the same version of the OS (RedHat 7.3), and as near as I can
tell has the same setup. It's running the same version of the NetWorker
client software, too. Pinging the host produces normal timely responses,
same as other hosts on the network. Also, pinging machines from that
host works normal, too. This machine can access network with no problems
that I can tell, and the user never complains about being able to reach
other hosts, internet, etc.

This problem has existed as long as I can remember, so I don't know when
it first starting exhibiting this behavior. Here are its horrible
symptoms and some of the things I've tried to troubleshoot it:

1. Running the following commands on the client produce no output or
error messages to the console. They just hang:

nwadmin -s server
nwrecover -s server
recover -s server
save -s server -b pool -l i /tmp

2. Running a probe against the client from the primary server produces
nothing:
savegrp -pn c client group

3. Under save sets, changed 'All' to /tmp, placed client in its own
group and ran both full and incremental from GUI. Still nothing! Just
sits there. I can see that if a file system had like 50 million inodes
that maybe doing an incremental might take a while, but /tmp? Common!
Even a small file system like /var just sits dormant during backup. I've
seen huge RAID on other boxes run circles around this machine on a bad
day.

There are no error messages or strange warnings in the nsr daemon.log or
messages log files on the primary server.
I used rpm -e to remove the NetWorker client and then re-installed and
re-started the software. Still no luck. I moved the network cable (100
Mbit) to another port, still no luck. I even tried another network
cable, no luck. I shut down the host, and rebooted it. Nothing. I even
ran a check against the client index on the primary server as: 'nsrck
-L6 client'. No error messages or warnings, and it completed just dandy.
Didn't take long either. What and the heck is this machine's problem?!!!
It has plenty of memory, plenty of swap space, and it's doing NOTHING
when I've been running these tests. It's not like there's 100 users
logged in. Noone is logged in other than me. I've tried everything but
running something like ethereal (sp), but maybe I'm gonna have to start
analyzing packets here? Not too good with those kind of tools.

Any ideas on what to try?

Thanks.

George

--
Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

Yes. Nothing shows up in there during my backup tests until I cancel
(abort) the backup. At that point, I see something like:

12/03/04 hh:mm:ss nsrexecd: Recvd signal to kill process group -
pid=-####, sig=2

But I would expect that. Essentially, there are no useful messages in
the client's daemon.log file. And, the summary and messages files are 0
bytes.

George

Stan Horwitz wrote:

On Fri, 3 Dec 2004, George Sinclair wrote:

There are no error messages or strange warnings in the nsr daemon.log or
messages log files on the primary server.

Have you checked the nsr daemon.log and messages files on that slow poke
client? If not, you certainly should.

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

b.) It is an client software issue. Does savefs -p work on the client?
This is what probe runs, the software should function on the client in
some manner. The client software have been stopped, /nsr/tmp cleaned out,
and software restarted? It is possible the system needs to be rebooted.


I agree. I'd start there. If the program stalls, check with 'strace'
or something to see what it's doing.

Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Well, 'traceroute -i interface client' works fine from/to this host.
However, 'savefs -p' on this client produces nothing! Very interesting.
It works fine on other clients. I checked /etc/fstab, nothing unusual in
there. I stopped and restarted the client software, same problem.
Everyting under /nsr/tmp is 0 bytes so not sure that there's anything to
clean out? Here's what /nsr/tmp has in it:

nsr.res.lck
nsrla.res.lck
product.res.lck
sec (empty directory)

This is the same on other clients. I also changed the "Storage nodes"
field for this client from:

storagenode_server_name
primary_server_name

to:

primary_server_name

and then ran same backups, and same problem. Clearly, the fact that this
client can't even run 'savefs -p' and receive a response in a normal
period of time is a major question here. I suppose it must eventually do
something, however, as backups on this hsot will eventually run, it just
takes all night. Not sure what to do at this point.

George

Robert Maiello wrote:

I think the key here is:

"2. Running a probe against the client from the primary server produces
nothing: savegrp -pn c client group"

When you run a probe against the client it should return something. If it
is successfull sometimes as you say shouln't a probe eventually return
something?

My guess is either:

a.) It is having some network issue; bad connection/packetloss/routing..
.it may be having trouble getting back to the server...ie. you can get to
it but it can't back to the server. Did you try traceroutes on the
client out the proper interface to the backup server/storagenode that your
data travels on?

b.) It is an client software issue. Does savefs -p work on the client?
This is what probe runs, the software should function on the client in
some manner. The client software have been stopped, /nsr/tmp cleaned out,
and software restarted? It is possible the system needs to be rebooted.

Robert Maiello
Pioneer Data Systems

On Fri, 3 Dec 2004 11:30:12 -0500, George Sinclair
<George.Sinclair < at > NOAA.GOV> wrote:

Hi,

We have this Linux client that is agonizingly slow to backup. It *WILL*
back up, but it takes hours, even to do an incremental, even against
something simple like /tmp. So if I launch a backup against this one
client from the GUI, for example, and I walk away, and I come back an
hour later, I will see nothing, I kid you not. Absolutely no activity
whatsoever. If I check group control window, the saveset 'All' is still
listed pending. Unbelievable! If I come back another hour later, same
thing. When I go home at night, though, and I come in the next morning,
it's done!

Its file systems are no bigger than any of our other clients. It's
running the same version of the OS (RedHat 7.3), and as near as I can
tell has the same setup. It's running the same version of the NetWorker
client software, too. Pinging the host produces normal timely responses,
same as other hosts on the network. Also, pinging machines from that
host works normal, too. This machine can access network with no problems
that I can tell, and the user never complains about being able to reach
other hosts, internet, etc.

This problem has existed as long as I can remember, so I don't know when
it first starting exhibiting this behavior. Here are its horrible
symptoms and some of the things I've tried to troubleshoot it:

1. Running the following commands on the client produce no output or
error messages to the console. They just hang:

nwadmin -s server
nwrecover -s server
recover -s server
save -s server -b pool -l i /tmp

2. Running a probe against the client from the primary server produces
nothing:
savegrp -pn c client group

3. Under save sets, changed 'All' to /tmp, placed client in its own
group and ran both full and incremental from GUI. Still nothing! Just
sits there. I can see that if a file system had like 50 million inodes
that maybe doing an incremental might take a while, but /tmp? Common!
Even a small file system like /var just sits dormant during backup. I've
seen huge RAID on other boxes run circles around this machine on a bad
day.

There are no error messages or strange warnings in the nsr daemon.log or
messages log files on the primary server.
I used rpm -e to remove the NetWorker client and then re-installed and
re-started the software. Still no luck. I moved the network cable (100
Mbit) to another port, still no luck. I even tried another network
cable, no luck. I shut down the host, and rebooted it. Nothing. I even
ran a check against the client index on the primary server as: 'nsrck
-L6 client'. No error messages or warnings, and it completed just dandy.
Didn't take long either. What and the heck is this machine's problem?!!!
It has plenty of memory, plenty of swap space, and it's doing NOTHING
when I've been running these tests. It's not like there's 100 users
logged in. Noone is logged in other than me. I've tried everything but
running something like ethereal (sp), but maybe I'm gonna have to start
analyzing packets here? Not too good with those kind of tools.

Any ideas on what to try?

Thanks.

George

--
Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

Well, 'traceroute -i interface client' works fine from/to this host.
However, 'savefs -p' on this client produces nothing! Very
interesting.

This is a linux client, right? Can you run 'strace savefs -p'? Does
the output start and then hang, or does something else happen?

Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

'strace savefs -p' produces some output and then hangs. I never get the
prompt back. Ran same on another client, and it completes there just
fine.

George

Darren Dunham wrote:


Well, 'traceroute -i interface client' works fine from/to this host.
However, 'savefs -p' on this client produces nothing! Very
interesting.

This is a linux client, right? Can you run 'strace savefs -p'? Does
the output start and then hang, or does something else happen?

--
Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

'strace savefs -p' produces some output and then hangs. I never get the
prompt back. Ran same on another client, and it completes there just
fine.

Exactly. What are the last bits of the display? Is it trying to open a
file or access some resource?

Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Here are the last couple of lines from the output:

stat64("/nsr/debug/nowritev", 0xbfffe078) = -1 ENOENT (No such file or
directory)
stat64("/nsr/debug/noreadv", 0xbfffe078) = -1 ENOENT (No such file or
directory)
stat64("/nsr/debug/nodelayeor", 0xbfffe078) = -1 ENOENT (No such file or
directory)
geteuid32() = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
bind(5, {sin_family=AF_INET, sin_port=htons(22485),
sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
connect(5, {sin_family=AF_INET, sin_port=htons(7938),
sin_addr=inet_addr("##.##.###.###")}}, 16

It hangs right at the ", 16"

I substituted '#' for the actual ip address that was shown. I should
note that this is the ONLY ip address listed in the output, AND it's not
the client's ip, the storage node or the primary server's ip. Oddly,
it's some other machine that has no connection with backups whatsoever
and is currently unreachable by ping. In fact, I think it's powered off.
When I run 'strace -o /tmp/foo savefs -p' on another host (one that's
acting normally), I see three different ip addresses listed: primary
server (many times), client (once), and the machine that the client is
ypbound to (many times). Not sure if that's any relation to why it shows
up in the output since it has no direct affiliation with the backups
(it's not a storage node server or anything), but from what I can
observe, the only IP address that's showing up in the output that I get
on this weird host is an ip for a host that's not even alive.

George

Darren Dunham wrote:


'strace savefs -p' produces some output and then hangs. I never get the
prompt back. Ran same on another client, and it completes there just
fine.

Exactly. What are the last bits of the display? Is it trying to open a
file or access some resource?

--
Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

sin_addr=inet_addr("##.##.###.###")}}, 16

It hangs right at the ", 16"

I substituted '#' for the actual ip address that was shown. I should
note that this is the ONLY ip address listed in the output, AND it's not
the client's ip, the storage node or the primary server's ip. Oddly,
it's some other machine that has no connection with backups whatsoever
and is currently unreachable by ping. In fact, I think it's powered off.
When I run 'strace -o /tmp/foo savefs -p' on another host (one that's
acting normally), I see three different ip addresses listed: primary
server (many times), client (once), and the machine that the client is
ypbound to (many times). Not sure if that's any relation to why it shows
up in the output since it has no direct affiliation with the backups
(it's not a storage node server or anything), but from what I can
observe, the only IP address that's showing up in the output that I get
on this weird host is an ip for a host that's not even alive.

Is the IP in /etc/hosts? Does that IP or name exist anywhere within the
files in /nsr/res on the client?

It's obviously doing something with the address and then timing out.
Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

No, but here's what I discovered. The wrong ip was listed in the
client's /etc/hosts. The correct host name was listed but with the wrong
ip. The DNS, however, lists the correct one. This wrong ip address is
also the one that was showing up in the output from the strace command,
and it appears twice in the /nsr/res/nsrla.res file after two resource
identifier entries:

resource identifier: 4.#.###.#.###.###.###.##.IP-ADRESS(61)

resource identifier: 6.#.###.#.###.###.###.##.IP-ADRESS(1)

With the exception of the first digit, and the numbers in parenthesis,
everything else on both lines is identical.
I should also note that /etc/nsswitch.conf uses the order: files nis dns
for hosts. I changed the ip address in the client's /etc/hosts file to
the correct value (no reboot) and EVERYTHING works now! I can also run
the GUI tools and command line tools like mminfo, and they no longer
hang. I guess prior to the fix, the host at some point would get around
this hurdle and finally back itself up but it would take a long time.
Probably eventually timed out and used NIS or DNS but might bounce
aroudn a long time?

How should I correct the wrong entries in nsrla.res? Can I manually fix
that or is there a better way? Also, is it necessary? What do those
preceeding numbers before the IP indicate?

Thanks.

George
Darren Dunham wrote:

sin_addr=inet_addr("##.##.###.###")}}, 16

It hangs right at the ", 16"

I substituted '#' for the actual ip address that was shown. I should
note that this is the ONLY ip address listed in the output, AND it's not
the client's ip, the storage node or the primary server's ip. Oddly,
it's some other machine that has no connection with backups whatsoever
and is currently unreachable by ping. In fact, I think it's powered off.
When I run 'strace -o /tmp/foo savefs -p' on another host (one that's
acting normally), I see three different ip addresses listed: primary
server (many times), client (once), and the machine that the client is
ypbound to (many times). Not sure if that's any relation to why it shows
up in the output since it has no direct affiliation with the backups
(it's not a storage node server or anything), but from what I can
observe, the only IP address that's showing up in the output that I get
on this weird host is an ip for a host that's not even alive.

Is the IP in /etc/hosts? Does that IP or name exist anywhere within the
files in /nsr/res on the client?

It's obviously doing something with the address and then timing out.
--
Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu

How should I correct the wrong entries in nsrla.res? Can I manually fix
that or is there a better way? Also, is it necessary? What do those
preceeding numbers before the IP indicate?

I don't think you need to do anything. The resource identifier is a
unique string created partially from an IP address. Although the IP may
no longer be in use, the identifier is still valid.

Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

But what would happen if we re-used that IP address (the one in the
nsrla.res file) on a new client?

At some point, it will get used again. The ip address for the client
itself, though, will probably remain in use on that client longer than
the one that's being used as part of the resource id will remain unused.
Would the algorithm that NetWorker uses to generate that from the IP
produce the same number again? Does it store that on the server
somewhere, too?

George

Darren Dunham wrote:

How should I correct the wrong entries in nsrla.res? Can I manually fix
that or is there a better way? Also, is it necessary? What do those
preceeding numbers before the IP indicate?

I don't think you need to do anything. The resource identifier is a
unique string created partially from an IP address. Although the IP may
no longer be in use, the identifier is still valid.

--
Darren Dunham ddunham < at > taos.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
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
should be sent to stan < at > temple.edu