Unsolved
This post is more than 5 years old
8 Posts
0
4514
client is not properly configured on the NetWorker Server
Hello,
Networker Server- Windows 2008, networker 7.6.4
Trying to do a recovery on a Redhat RHEL5_64 client (headnode of cluster) and I get the following error when I try to recover a file : Error: 'client (Client_name); is not properly configured on the NetWorker Server.'
It does put me in the command line recover console and let me ls -al files and 'add' files to be recovered, just complains when I actually try and 'recover'
The reports on the server show this client backs up just fine. When I get in the command line recover I can browse the files available for recovery. rpcinfo -p from server to client or client to server seem to work fine. nslookup of the client works fine. Client name and FQDN are listed in the alias field on the server.
The server does have two active NIC cards one NIC on primary network and the other NIC is set just for communication to the clusters compute nodes on a 10.XXX.XXX.XXX network. Not sure if the second NIC is causing a problem or not, but the command line recover console connects just fine, just complains when I try to recover.
Ideas?
Thanks,
Joe
gautamgp
226 Posts
0
March 26th, 2016 10:00
Check the logs on the client, it should tell you which name/IP it is looking for.
crazyrov
4 Operator
4 Operator
•
1.3K Posts
1
March 29th, 2016 02:00
Hi jwhite,
Assuming that the linux system that you are running the recover on is configured as a host on the respective NetWorker server.
Try this. on the client system where you want to run the restore run the following command,
printf ". type: nsrla\nprint\n" | sudo nsradmin -p nsrexecd -i-
What ever hostname you find under assigned to "name:" put it on the aliases of the client instance configured on the backup server.
Or, Even easier way to get around this would be to,
- Stop the services
- rename /nsr/res/nsrladb
- start the services
- retry the restore.
HTH
ble1
2 Intern
2 Intern
•
14.3K Posts
0
March 29th, 2016 02:00
Check alias field of NSR client.
Joemh53
8 Posts
0
March 29th, 2016 11:00
Hey,
So i looking at this peer info and not sure how but there is info about domains and machines that are not a part of my closed network. Not sure if I used a client from the corporate guys who manage larger network where I work or what. Downloaded fresh client software from EMC and just want to start over on client side.
I unistalled the networker client software, before I reinstall can I just rename /nsr directory to /nsr.old, as the 'rpm -e' does not remove the directory? After that just reinstall the client, starting fresh?
Thanks,
Joe
ble1
2 Intern
2 Intern
•
14.3K Posts
0
March 29th, 2016 14:00
You don't have to rename whole /nsr. /nsr/res/nsrladb will be enough to be renamed/removed. Note that this will also cause new auth code for the machine to be created so you will need to remove old one from the backup server. However, with NW7 recommendation was to use oldauth and if this is your case then you should not have issue with these auth keys between machines.
What I would do in your case is:
a) run savefs -s -vpn on client
b) if you get error for , go to server and do nsrls (same as in error; do not add or remove domain for example).
crazyrov
4 Operator
4 Operator
•
1.3K Posts
0
March 30th, 2016 08:00
Nope not required. Renaming the nsrladb should clear out any residual peer information from earlier connections. As H suggested you might need to delete the peer information on the backup server too incase the backups fails with errors like "connection refused".
Joemh53
8 Posts
0
March 31st, 2016 10:00
Hello,
I removed the client and renamed /nsr/res/nsrladb. Did a rpm re-install with client downloaded from EMC.
Re-ran printf ". type: nsrla\nprint\n" | sudo nsradmin -p nsrexecd -i- and the info looks normal now. I can even do recoveries.
Thanks for all the help.
Joe
ble1
2 Intern
2 Intern
•
14.3K Posts
0
April 1st, 2016 03:00
The only time I have seen this with recover was when entry in nsrladb for hostname was not corresponding to real host (in my case it happened after system admin created baseline distro with already initiated nsrladb so each new host would get same nsrladb including same hostname inside which didn't match reality).