At 8:11 AM +0100 8/16/00, Ken Gillett wrote:
>Whatever the reason for these communication failure problems it
>worries me that (in my case) the LAN works perfectly for everything
>else, yet Retrospect falls down every time. I realise that it hits
>the network pretty hard, but this is no surprise and shouldn't it
>have been designed to cope with that in the first place?
>I'm pretty fed up with its inability to perform network backups over
>an otherwise perfectly functioning network. Maybe it's not happy with
>my 10baset hub
>Exactly what is the 519 error? How can it lose contact with a client?
>They're still physically connected and unless the network has crashed
>surely there's no reason why communication couldn't be re-established
>for the backup to continue.
error -519 is, in my experience, caused by a number of things. Sometimes a
screensaver will slow the client down enough to make the server drop the
connection, or maybe the user decides his machine is acting too slowly (not
knowing it's being backed up and that most people don't work at 1:30 AM)
and restarts the client. Old versions of Eudora used to cause 519s because
their "You have mail" dialog halted processing on the client. In nutshell,
519 is caused by any incident that causes the data stream between the
client and the server to be broken.
I'm curious as to the nature of Retrospect's relationship with Network
hardware, like switches and routers. We have several Cisco switches on our
network (over 200 Macs and about 50 Wintel) and Cisco has told us in the
past to do things like "disable the spanning tree protocol on the port that
feeds the offending Mac". We'd end up reenabling it and solving the
problem on the mac itself with software. My point is that _if_ Retrospect
is sensitive to these things, then there are dozens of little factors, on
our network anyway, that could contribute to a problem, even though it
appears to be working fine in all other respects. Retrospect is just using
a protocol, be it TCP or Appletalk, to do it's job, right? Maybe it's a
question of how Retro. _uses_ that protocol. Anyone from Dantz want to
jump in here?
and At 10:51 PM +1200 8/16/00, John Gee wrote:
>It would be nice if Retrospect behaved more like 56k modems, and
>automatically downgraded performance until a reliable connection was
>possible. Retrospect could go slower/safer but write a warning to the
>"Recovering from 519 error, establishing lower performance connection"
Good idea, but I think Retro. already behaves like that. I've sat in front
of a server, backing up a sick PC, and watched the transfer rate drop from
36Mb to 2 Mb/min. It never actually dropped the connection, it just took 3
hours to back the thing up! In my experience 519 is generated when the
valve is out-and-out shut off.
I think the log entry idea is a great one. Maybe a separate entry
for the xfer speed at the start and again at the finish of a client's
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]