Announcement Banner
UNSOLVED

kfoote

updated

20 years ago

K

kfoote

23 Posts

0

1933

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
  • ble1

    6 Operator

    •

    14354 Posts

    •

    56186 Points

    698

    0

    Posted December 8th, 2006 14:00

    Issue One:
    report the new version of networker to the server...

    If you are referring to client information then therer have been few versions (based on license) where this never really worked. Same applies if you had module installed. Quickest way to find out version is to connect via nsradmin to nsrexecd of remote client and check the version. Simple script will do that. I heard that apparently this has works better than ever in 7.3.x, but since I never pay attention to that I can't comment that (but from experience can say that it did not work properly before).

    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.

    Are you saying that this server is also giving you wrong version via nsradmin? I doubt.

    Issue Two: (same server)

    Hm, I just tried that and can't replicate it. But if you can I would suggest to open that with support.
  • kfoote

    23 Posts

    698

    0

    Posted December 11th, 2006 08:00

    Hrvoje
    Thanks for the response .. here is a short update..

    Are you saying that this server is also giving you wrong version via nsradmin? I doubt.

    The server is infact reporting the wrong info for the client instance of NetWorker on itself.
    At this point Im not really sure if the install went a little bad or what.
    I used your suggestion and quered a few nsrexec processes on the client machines. The correct verison of Networker is reported (7.3.2.Build364 in my case) This is very strange.. Consequently EMC did not seem very concerned about this on my support call. ????

    Issue Two: (same server)

    I did some more looking into this problem myself. It seems that the full backup of this volume was broken down into smaller 2G chunks. I have seen this before when we first moved to 7.3
    Our large volumes were broken down into chunks of 2G and the name of the volume from networker perspective changed to <#>D:\
    This is very cumbersom to deal with when recovering but the data is there..

    Has anyone else seen this happen???
  • ble1

    6 Operator

    •

    14354 Posts

    •

    56186 Points

    698

    0

    Posted December 11th, 2006 09:00

    I used your suggestion and quered a few nsrexec
    processes on the client machines. The correct verison
    of Networker is reported (7.3.2.Build364 in my case)

    Ah I see.. so if you were looking at info from NMC I would simply say to ignore it. I did see that many times so no need to worry really.

    This is very strange.. Consequently EMC did not seem
    very concerned about this on my support call. ????

    Probably because there are at least 5 or 6 LGTpas for that and they are pretty old.

    I did some more looking into this problem myself. It
    seems that the full backup of this volume was broken
    down into smaller 2G chunks. I have seen this before
    when we first moved to 7.3
    Our large volumes were broken down into chunks of 2G
    and the name of the volume from networker perspective
    changed to <#>D:\
    This is very cumbersom to deal with when recovering
    but the data is there..

    Has anyone else seen this happen???

    I did :D I had that under HPUX for file system backup and made me wonder what is going on. It seems as if there is an issue with nsrmmd and communication it breaks a little bit. After nsrauth has been disabled I didn't see it since. If you didn't do that yet, steps have been listed in one recent thread (inside 30 days) so you may wish to check forum search option for that.
  • kfoote

    23 Posts

    698

    0

    Posted December 12th, 2006 05:00

    update: im not going to worry about my first issue. This is more of a nusance than anything else.. what good is showing a version number via NMC/nsradmin if it is not correct... thats just my two bits.

    However I will focus on my second issue. This is very strange to me. Below is the result of a mminfo command for todays date.. this illustrates how one of our large volumes is being broken down into smaller chunks.. I would like to get this issue figured out. I think this output is especially odd because the D:\ volume did not get broken down.

    C:\>mminfo -q "pool=Default,sscreate>12/12/2006,sscreate
    w" -r name,nsavetime,level,totalsize,sumsize -v -c OURCLIENT
    name save time lvl total size
    SYSTEM FILES:\ 1165913112 full 237437952 231 MB
    SYSTEM STATE:\ 1165913114 full 22862428 22 MB
    C:\ 1165913116 full 1165773224 1138 MB
    D:\ 1165913117 full 3073509148 3001 MB
    SYSTEM DB:\ 1165913115 full 866464 847 KB
    E:\ 1165913142 full 2048003268 2000 MB
    <1>E:\ 1165913145 full 2048001832 2000 MB
    <2>E:\ 1165913147 full 787106836 768 MB

    C:\>


    If anyone has pointers to emc docs or related posts that have to do with the interaction and what level the auth methods field has to do with this please let me know.. Thanks for any help you can shed on this issue.
  • ble1

    6 Operator

    •

    14354 Posts

    •

    56186 Points

    698

    0

    Posted December 12th, 2006 06:00

    As I said, disable nsrauth. Forum search gives you pointer to correct thread. Here it is (check Jodi's steps):
    https://forums.emc.com/forums/thread.jspa?threadID=45048&tstart=0
  • kfoote

    23 Posts

    698

    0

    Posted December 12th, 2006 08:00

    Where is EMC documentation for this... ???
    I have other 7.3.2 server and 7.3.2 client pairs that are not experiencing this issue...
    I generally don't want to change the nsrla data and make things not work at all...

    If this is known by emc then they should have published info related to this occurrence.
  • kfoote

    23 Posts

    698

    0

    Posted December 12th, 2006 08:00

    It appears I have found some documentation..
    Now to see where / why I have to change my configurations?
  • ble1

    6 Operator

    •

    14354 Posts

    •

    56186 Points

    698

    0

    Posted December 12th, 2006 09:00

    If you really wish to be masochistic to yourself simply open a case with support and you will get same response and that will make it official :D
  • kfoote

    23 Posts

    698

    0

    Posted December 12th, 2006 11:00

    Learning about legato is like going in circles..

    I neglected to look at daemon.log ok so now I know the error is some where related to ...
    hey guess what auth methods...

    12/12/06 00:35:58 nsrexecd: SYSTEM error: An error occured when a client attempted to acquire credentials: error: "A daemon requested the information for a user session, but the user session was not found
    in the list of valid sessions" session number: 24e:476, client ip address: 127.0.0.1, port number: 0, user id: (NONE).
    12/12/06 00:35:58 nsrmmd #4: GSS Legato authentication from MY-CLIENT failed...
    12/12/06 00:35:58 nsrmmd #4: RPC error: Authentication error
    12/12/06 00:35:58 nsrexecd: SYSTEM error: An error occured when a client attempted to acquire credentials: error: "A daemon requested the information for a user session, but the user session was not found
    in the list of valid sessions" session number: 269:478, client ip address: 127.0.0.1, port number: 0, user id: (NONE).
    12/12/06 00:35:58 nsrmmd #4: GSS Legato authentication from MY-CLIENT failed...
    12/12/06 00:35:58 nsrmmd #4: RPC error: Authentication error

    But now Im wondering if i leave auth methods alone and add a *@* entry to the Administrators line would that do the same trick?
  • ble1

    6 Operator

    •

    14354 Posts

    •

    56186 Points

    534

    0

    Posted December 12th, 2006 13:00

    It would not. Besides you would open a security hole which you don't wish to.