We are going to try that next, just waiting for my colleague to run it.

We have no name resolution issues; all DNS name resolution is correct and consistent on server and client.  The only thing not resolving is the old default gateway which was changed 5 months ago; we have been unable to find any reference to it anywhere though Networker mentions it in the error logs.

One more thing, running the savefs command locally returns the correct savesets!

Back to the basics ...

Try to backup a disk/directory manually from the client using the command line (save).

If it fails, add more verbosity or increase the debug level to retrieve more info.

To avoid (tmp) name resolution issues, you can also use hosts tables.

Problems accessing the Networker client resources are also tempermental, from backup server:

>nsradmin -p 390113 -s clientname

NetWorker administration program.

Use the "help" command for help, "visual" for full-screen mode.

nsradmin> p

Lost connection to NSR server: RPC send operation failed; errno = Broken pipe

Rebound to specific service

RPC send operation failed; errno = Broken pipeNo resources found for query:

                        name: ;

                        type: ;

nsradmin> . type:NSRLA

Current query set

nsradmin> p

Lost connection to NSR server: RPC send operation failed; errno = Connection reset by peer

Rebound to specific service

RPC send operation failed; errno = Connection reset by peerNo resources found for query:

                        type: NSRLA;

nsradmin> p

                        type: NSRLA;

                        name: clientname;

              nsrmmd version: ;

             nsrsnmd version: ;

NW instance info operations: ;

       NW instance info file: ;

          installed products: ;

                auth methods: "0.0.0.0/0,oldauth";

           max auth attempts: 8;

               administrator: No privilege to view administrator list;

                        arch: Windows Server 2003;

                 kernel arch: INTEL_PENTIUM;

                    CPU type: INTEL_PENTIUM;

                machine type: server;

                          OS: Windows Server 2003 5.2;

           NetWorker version: 8.1.2.6.Build.478;

              client OS type: Windows NT Server on Intel;

                        CPUs: 4;

                     MB used: 30806;

                  IP address: IP addresses;

nsradmin> p

Lost connection to NSR server: RPC send operation failed; errno = Connection reset by peer

Rebound to specific service

RPC send operation failed; errno = Connection reset by peerNo resources found for query:

                        type: NSRLA;

nsradmin>

Supposedly no firewall, tracert output shows it going one hop to core switch and another to backup server.

I can confirm a save from the command line on the client works successfully (using backup network which is also configured in the server network interface field).

Looks weird. Maybe the backup network is (indirectly) the troublemaker.

AFAIR this only transfers the backup data - all 'standard' communication will still use the 'normal' domain network.

Maybe you want to check this.

I also do not have a straight answer. So far I can only suggest that you update the software to the latest version supported (NW 8.1.3 for Windows 2003).

This is one of the weirdest ones I have seen Bingo!  Anyway, I have an update.  We set a dummy hosts entry for the old gateway IP address and the backup does not give those errors anymore.  It is still not successful but we can now return probe information but here is the weird part, it will only do it if logging is set to -vvv, if I use -D9 logging it does not probe successfully.

If you changes are recent it might be that NetWorker is holding on to the old ip configuration. I would suggest you run the following command on the backup server

dbgcommand -p pid flushdnscache - where pid is the proccess id for the nsrd

We have reinstalled the software but could look at upgrading it though I am not confident that will address the problem.

We'll take a look at this, though the change was nearly 5 months ago, not too sure how long this data will be cached for...