Thanks again for reply Fazil.

The backup server has only two interfaces, on disjoint networks, and as it is 
communicating correctly (most of the time, and when not it is on the same 
interface it would use if correct) the person running the backup server and 
myself felt that specifying that would be a long shot.

Interesting that you mentioned putting in a route statement on the server (the 
backup client) as that is exactly what I did earlier today (after a special 
early morning trip in to reboot to box so backups would start working again).  
That seems like a long shot also however, since this server cannot communicate 
with the backup server except on the correct interface; but what the heck, on 
the theory that at some point it tries the incorrect interface and from then on 
stuffs the wrong IP into some backup client generated data that does make it to 
the backup server in packets using the correct IP/interface, and that perhaps 
the static route will force Windows to never try the other and so never letting 
the backup client get the wrong IP to stuff into that data.  (Another couple 
months wait now.)

Any ideas why use of   "save -c <correct fqdn>" in the backup definition is not 
doing as advertised ?? 

Regards,
Roger

+----------------------------------------------------------------------
|This was sent by abell AT asu DOT edu via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER