Jump to content

Backup Error -1028


Recommended Posts

Hello Everyone,

 

 

 

I am using MAC Os 9.X with Retrospect 4.3 for all of my Mac's. This is the problem... I was able to add everyone on the network to the CLIENTS section via TCP/IP and everyone was RESPONDING.

 

 

 

Now I have created the Script and it runs correctly ever night. The problem is some of the clients are NOT VISIBLE on the network and they do not backup?? The thing that is funky is they are visible and then they dissapear and it gray's out?? I have tried adding them via the address also and the same issues arrises? I have also watched them become unavailable during the day so this is not a time of day issue?

 

 

 

Any Ideas?

 

 

 

Thanks.

 

 

 

mccannma@staff.abanet.org

Link to comment
Share on other sites

  • 2 weeks later...

I've been seeing this problem intermittently on various different Mac workstations, all running Retrospect Client v4.3 (our server is v4.3 as well) but it seems to be getting worse. Nearly all our OS 9.1 workstations get shut down prior to backup (so that they're at the Retrospect screen saver screen), and most of our clients back up OK, but a couple of our clients *never* back up successfully, failing with the -1028 error every time (although they're pingable at the time of failure and the Retrospect Server sees them when it builds its available client list), while others will back up fine 4 out of the 5 nights of the week, then fail on the 5th night with the "-1028 not visible on network" error (this is happening to one of our Mac file servers, which doesn't get shut down prior to backup). The problem seems to be worse when running unattended scripts, as opposed to running a manual backup, although it occurs during manual backups on occasion too.

 

 

 

It was suggested by a Dantz tech that the problem might be in the UDP packet sent by the server to the client as a test to see if the client is available. With some clients the first sent UDP packet does not get picked up by the client (perhaps due to the Open Transport implementation in OS 9?) but subsequent packets are noticed. The tech suggested making sure the "TCP/IP active only when needed" checkbox was unchecked in the TCP/IP control panel (makes sense to uncheck this) but that had no visible effect on the problems we are seeing. We also made sure that the packet wasn't trying to cross hubs, so this isn't it either. It might help if the server sent more than 1 UDP packet as a test, if that's indeed what it's doing.

 

 

 

To answer the question posted here by Irena, the clients that are not shut down and which are having the problem do say "Ready" in the Retrospect control panel. It's of course impossible to check the control panel on a machine that's shut down and in backup mode without rebooting it and changing the test environment.

 

 

 

I would love it if the Dantz folks came up with a solution to this problem; it's really killing us.

 

 

 

Cheers,

 

John P.

 

 

Link to comment
Share on other sites

  • 2 months later...

Be certain that the clients are set to never sleep. Also be certain that no other automatic preocesses are set to execute on that client at the time of the backup.

 

 

 

If you leave the client on (not in screensaver mode) does it persist?

Link to comment
Share on other sites

All of them are set to stay awake, and there is nothing else running on them. Sometimes they are in Retrospect screen saver mode, and sometimes they are just on. During the day, I can get on the Retrospect server machine and go to Configure>Clients. Some of them display normal, and some are grayed out. If I then go from there to Network, it shows some of those clients that were grayed as normal and "Responding." (The client responds to a ping as well.) But if I try to configure one, I get the -1028 error client not visible message. By the way, if I leave the "Clients on Network" window up, different clients will appear then drop off that screen. If I Add by Address, I can access the client, and it will work - for a while. Then it will drop off again later.

Link to comment
Share on other sites

I am seeing this error on several clients as well. When the backup server attemps to connect to a client for configuration, the retrospect control panel will say "connected" then revert back to "waiting for first access", so there is some communication happening that then drops off.

 

 

 

We're on a university campus and the only thing the problem clients have in common is that they are physically further away from the server. I'm going to follow up with the network folks here to see what the network topology is between my backup server and the problem clients.

 

 

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...