Unsolved

This post is more than 5 years old

23 Posts

1910

December 8th, 2006 07:00

7.3.X server with some issues

hello all
looking for some help on a few issues im having with our main networker server.

server data
OS w2k3 sp1
NetWorker 7.3.2-Build.364 (just got the media)
Management console Not installed on this host (we use a central NMC located on another server)

Issue One:
I have been going through our client list for this server and updating the NetWorker install on each host. This is usually a straight forward thing. The next time a client contacts the server it should report the new version of networker to the server... (this is how it has alwase worked) However for some reason or another this is not getting updated to the NetWorker server. I think this is related to the server rather than the clients. Furthermore the server itself is listed as its previous Networker level rather than my (just the other day) install of 7.3.2.Build.364
There are no errors reported (other than our normal files in use etc) to this effect on either client or server logs.
Another note on this issue we have other networker servers and there clients are all reporting the correct version data via the gui and nsradmin.

Issue Two: (same server)
client info
OS w2k3 sp1
NetWorker version 7.3.2.Build.364 (see previous issue though)

I have not verified this on anything other than one client so far. Here goes. Client does a full save once a week then incrementals the rest of the week. Data is getting backed up (not sure if its the full ammount though) anyway from the client if you change the browse time to a full date you are do not see anything under the volume level (ie: i can see D:\ but nothing below). This is not good!! on incremental days you can see a file tree under D:\ but most files are 0 byte place holders it looks like.
The best I can tell this happened when the server went to 7.3.2.Build.364 ....

Any help / ideas would be appreciated.
I think i'll open up a call to emc as well.

thanks
-kpfoote

23 Posts

December 18th, 2006 05:00

Xander
Actually this just started happening when we _did_ up grade all the clients to 7.3.2 the server was upgraded as well (7.3.2). Pervious version in this environment was 7.3.1, which to my knowledge did not break things up in this fasshion in our setup.

I am curioius about what this error / occurance really does to the indexes. We have another server / client setup (7.3.2 everywhere) that only handles the linux / unix machines and the <#>volume notation does not seem to effect the client browsability of these savesets. But on on M$ backup environment the <#>volume really wrecks the browsability and usability of the savesets. Are these savesets then not valid? Can the indexes for the client be rebuilt correctly?

Also I would like to get to the bottom of how this issue is solved. It seems that changing the auth methods: entry in NSRLA worked but is this documented / explaind somewhere by EMC?? Why would I have to do this in my M$ environment but not my linux/unix env .. that doesn't make sense.

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

December 18th, 2006 06:00

I am curioius about what this error / occurance
really does to the indexes.

Nothing. It does slow down a performance a bit during restore process as it does during backup, but that's all. Of course, you get more entries in mdb. Those familiar with NW 5.x will know exactly what I'm talking about.

...usability of the savesets. Are these savesets then
not valid? Can the indexes for the client be rebuilt
correctly?

Yes as long as each of 2GB chunk is correct. By looking at pssid you see all ssids which are part fo your whole ssid that you would expect to have in first place.

Also I would like to get to the bottom of how this
issue is solved.

This has been already discussed.

It seems that changing the auth
methods: entry in NSRLA worked but is this documented
/ explaind somewhere by EMC?? Why would I have to do
this in my M$ environment but not my linux/unix env
.. that doesn't make sense.

It is, but it is not in public search area yet. That's why support knows about it anyway. Just because you saw it in one environment doesn't mean it does not apply to it. I had that for pure UNIX environment for example.

23 Posts

December 19th, 2006 06:00

I was going to start a new thread but it still seems pertanent to this issue... sort of

Will the data under Program Files\Legato\nsr\res\nsrladb on the server get recreated if I delete this?
I am not sure but I believe a legato support rep told me this..
Im wanting to get acurate information from all my clients as to what versions of NW client software they are running and I thought some clean up / rebuild of nsrla data would help in this effort, not sure though.

For what its worth the <#> issue seems to be resolved at the moment.
server is set to oldauth only clients are still default.

6 Operator

 • 

14.4K Posts

 • 

56.2K Points

December 19th, 2006 07:00

Server is keeping keys of all clients inside and unless you are using nsrauth I believe it is safe to delete it. However, if you are using oldauth then I see no point of deleting it in first place. Besides, if you delete I suspect it will be recreated with nsratuh as default choice again. Check that once again with support (especially the reason behind).
No Events found!

Top