savefs: nothing to save

Hi Jasper,

      Could you run `nsrrpcinfo -p dest_hostname` from both client to the networker server and from the networker server? There are chances that the NetWorker server is able to talk to the client but the communication back is failing or blocker.

What do you mean with having added the aliases again? Were they deleted?

Very often "nothing to save" is related missing an alias for the specific client NW definition.

Some context from the past. Up until NW8, one could even run a probe backup and it would show in its output that when a nothing could be saved occurred, that it the at least in nw8 would show what the missing alias was. So that is in the time that a "probe" backup meant (what was it again "savegrp -P? at the time) was only a test backup, a dry-run, without actually performing a backup, it only verified connectivity. So had nothing to do with probes, that were also introduced later as well, so to run checks to determine if a backup is to be run yes or no, so that was added later as feature, using the same name "probe". The probe feature that existed before as a savegrp command option to only do a dry-run, was not moved into functionality of NW9 and beyond, so that no longer exists as such, while the backup yes/no probes still do. So one cannot do that dry-run test and get to see the missing alias, without actually have the backup fail while it runs into the issue.

So are the shortname, the FQDN name and possible other aliases added? For example does the system have more DNS entries? What other hostnames are stated within its own host file that might be missing as an alias?

What does for example nsradmin run locally on the client connecting to nsrexecd show what the hostname was at time when Networker was started the first time? As that is not updated, regardless of any change you perform on the client. We have seen cases that it stated "localhost" or even completely different client names, as a result of a system being cloned, without making sure the NW client config on client end was completely clean (by stopping NW client, having /nsr/res/nsrladb directory deleted and the starting NW again, after which a new nsrladb contents would be created as well as a new nsr peer certificate. Also any nsrports changes would have to be re-done. All part of the nsrladb contents on cliendt end).

# nsradmin -p nsrexecd
NetWorker administration program.
Use the "help" command for help, "visual" for full-screen mode.
nsradmin> . type:nsrla
Current query set
nsradmin> print

You should also be able to run this from the NW server end to the client (here assuming that it is a Linux backup server):

# sudo nsradmin -s -p nsrexecd
NetWorker administration program.
Use the "help" command for help, "visual" for full-screen mode.
nsradmin> . type:nsrla
Current query set
nsradmin> print

Look at the "name:" field in either nsradmin query and see if that is even a correct hostname for the client and if so, verify if that is added as alias to the NW client definition.

What is your saveset?  Does it fail against local fs or something else?  Have you tried save from client to see what you get?  In your case probe fails so it all starts with question what is your saveset (what do you use as saveset and then what it is on client end).

try with a particular sub folder if its taking data ; ask os team to validate how they mounted the drives /directory