-1028, clients "time out"

[chrisa]

The "older" office computers on our network (NuBus Power Macs, mostly 7100s running OSs 9.0.4 - 9.1, using 10 base T connection to ethernet) seem to have an issue with Retrospect where they stop responding after a cetain amount of time has elapsed. We had this problem with Workgroup 4.3 and now again with 5.0, but after stumping the Dantz tech support person (back when there were people there who would call you and follow up on questions for free!) I just switched those computers back to AppleTalk connections and let it be. Slower but it worked. Now with 5.0 I don't have that option anymore.

 

 

 

The TCP/IP on those machines is set to "active", and "load only when needed" is unchecked. They don't have energy savers active and they are either on and awake or running the Retrospect "shutdown" screensaver at the time of backup. All fixed IP addresses. The computers are found by Retrospect just fine - if you go to Configure>Clients they are there, but sometimes greyed-out. If you then go to Network, they are found and come up as responding. But then run the office backup script and by the time it reaches those computers they are "-1028 (client is not visible on network)". Unlike other client issues I've seen posted here, the client doesn't crash or hang as a result of any of this. You can generally successfully back them up as individual immediate backups, and sometimes it will make it through one of them in a script before the rest are not found. If you attempt an immediate backup of the network including these computers it will fail, error 519. The problem is only with these older Power Macs (never with our G3s or G4s or newer Powerbooks) and only when they have to connect via TCP/IP (as they do with v.5.0). Could there be some sort of conflict with the slower etherneting capabilities of these machines?

 

 

 

Any ideas? It is driving me batty...I'm sure there's something simple and silly I must have just missed. Please help!

 

-Chris

[chrisa]

any ideas??

 

this is a small non-profit, so new computers aren't an option (at the moment) and neither are nubus 100 base T networking cards for all our office computers. actually i did dig up one 100 base T nubus card and put it in one of the computers...now it backs up about 50% of the time......

 

 

 

but we got retrospect workgroup so our backups can run unattended! as it stands (since losing the appletalk option) i have to run the office script a couple of times and then run an immediate backup of whatever computers still haven't made it - and sometimes that takes a couple trys. every other tcp/ip application works fine on these computers, despite their slower connectivity. please tell me where retrospect's issue lies!? i can't keep spending so much time with the backups.

 

thanks!

 

chris

[IrenaS]

An error -519 means that the backup computer waited for 2 minutes with no response from the client. This isn't deemed reliable enough for backup data transfer, so the backup doesn't complete.

 

 

 

The -1028 means that the computers cannot establish a TCP/IP connection in the first place. At that point, I'd bet that you would be unable to ping between the two computers.

 

 

 

If you're getting these errors, then it's Retrospect telling you that there isn't a stable enough connection (or even that there isn't a connection at all), and it's possible that these computers aren't able to transfer the data reliably enough over TCP/IP.

 

 

 

Test this for certainly by, as a test, replacing a computer that works with one that isn't backing up reliably. Swap everything, including the network card and cables. If this works, then you've pinpointed the problem and will have to look for other options.

 

 

 

You could consider two backup groups; one 4.3 running an AppleTalk backup and the bulk of the backup running 5.0 over TCP/IP.

[chrisa]

just seems odd that the client can be so easily "woken up" (simply by going to Clients>Configure>Network) via retrospect, but that retrospect can't reactivate those clients if they "time out" during the backup. ping-ing those computers seems to work okay though the first packet is sometimes lost (10% loss) if the computer was in a "greyed-out" state in retrospect, but a second attempt returns 100%. I can generally back up the failed computers one at a time through immediate backup right after "activating" the connection from the Network menu. if i do that (one at a time so other NuBus office machines in the queue don't have time to "time out") then they generally back up fine. But is there a way to keep the TCP/IP connections from "greyingout"/"timing out"? even the newer computers grey out in retrospect when idle, but i guess with a faster/more reliable TCP/IP connection retrospect doesn't have trouble "waking them up". but why do they deactivate in the first place and can it be prevented? i'm very curious. since a fast ethernet card doesn't solve the problem completely i have to assume there is still an inherent issue in the older, slower machines.

 

 

 

yes, you're right. i could run a seperate 4.3 appletalk backup script (i assume i have to downgrade the clients?) i wasn't sure if running 2 versions on the same machine would cause retrospect confusion. can i use the same tape and set as i do for the rest of the office (with 5), or should i seperate?

 

 

 

of course the problem may solve itself soon as i just heard rumor of a pending donation of several 8500s but i'm still curious.

 

 

 

thanks!

 

chris

[IrenaS]

Unfortunately, the older computers don't deal very well with "wake-on-network-access" situations. You could try setting up a Backup Server script that runs during the night, and it would retry clients that it couldn't access the first time around.

 

 

 

Most people using the 4.3+5.0 strategy choose to run a new backup server. If you're running the backup on the same machine, you shouldn't use the same tape - I'd recommend keeping each backup and backup set separate.