52973:recover: Didn't recover requested file

Hello,

We run Networker 8.1 build 162

When I tried to perform a Directed Recovery via the Networker User I also get the similar error message:

52973:winworkr: Din't recover requested file

Is there a log I can look at to get more information as to why it was unable to recover the files?

Is the number of files that you are trying to restore very large ? If yes, then it might be that the connection is getting times out. Try doing a SSID restore on the target server.

b162?  Hm.... first patch (8.1.0.2) had build 212 and current one is 490 (8.1.2.7) or even more if you check latest release on support site (eg, 8.1.3.0).  I think any "first" release is something not to use, especially since at least 3 SPs have been released since - just too many issues fixed since.  I would make an update first.

While I agree it would be ideal to be on a more recent version, unfortunately I do not have this option. I work for a government military agency and we need to fill out lots of paperwork and follow specific processes (like testing) even for simple upgrades. Furthermore, in my environement we simply don't upgrade when something doesn't work as intended. Without proper testing, one should never upgrade and hope to fix an issue as another functionality may break which could introduce more potential problems. This means a "simple" upgrade needs to ne tested and takes time and man hours and is no longer simple. Unless needed, or unless you can confirm that a newer release specifically addresses this issue, then your suggestion is not a feasible path at the moment.

My question was regarding the error 52973 and if more information can be obtained in a log file or somewhere else. Unless this code does not represent anything specific it would be nice to know what "52973" signifies. Understanding the issue is key in finding a solution and "52973:Didn't recover requested file" dones't give much information to what is going wrong.

P.S. I get this error from the client(gui) and via the command-line when running them from the source client.

Sorry, but I can't buy a story about military env, test blah blah and at the same time have env which uses first release which always has something that you would not desire in your release management.  Obviously, someone has to make better plan as far as release management and adoption goes.  This also minimizes any potential support headaches later.

I'm not 100% sure, but you can easily test it - I suspect number you see is just PID of the process reporting it (and reasony why you see two different numbers might be due to different threads/processes). The error number you get is 22, but only support engineer close to code can say for sure what it is (for example, systems calls wise that would be "Invalid argument" on Linux, but I can't be sure here which OS your server is).

Some questions:

- do you always get failure on the same file?

- your directed restore; was it also with -a or did you do browsable restore?

I'm not asking you to "buy" anything, and quite fankly sir, you can believe what you like. I never talked about a military environment and I'm not sure why you have gotten so "salty" by my rejection to simply upgrade and hope it fixes this issue. To be clear, the current version we run works great and we have not had many other issues. I'm simply trying to learn about the error code and trying to rule out if something in my environment is causing the issue.

I don't really care to continue any more discussion with you sir, good day.

This is related to a clientid issue. Please let me know whether The client was renamed in the past ?

Hello and thanks for your reply!

Yes it's very possible the client was renamed at one point or even deleted and re-added using the same name if the server got replaced.

The client was renamed in the past and the old name was added to the aliases field of the new client resource in NMC. After renaming, the old client file index /nsr/index/oldcleint_name still existed. Backups write properly to the new index /nsr/index/newclient_name, however, it is suspected, that recover is still trying to get file info from the old /nsr/index/oldclient_name index directory

• Check that you can ping both server interfaces interfaces from client.
• Check that you can ping both client interfaces interfaces from server.
• Check that you can ping the client's aliases from the backup server.
• Check you can connect to each client interface using nsradmin -p nsrexeced -s
• Within nsradmin, check the output of: 'p type: NSRLA' matches for each client interface address - in case one routes to a different client accidentally

Check below Primus for "How to identify and resolve most client ID issues"

https://emc--c.na5.visual.force.com/apex/KB_HowTo?id=kA0700000004cN1