Jump to content

Bypassing errors

Recommended Posts

I use Retrospect to backup the Macs in our company to UNIX disk space via FTP. This process has worked quite well, with a Retrospect Event Handler script helping me keep track of which machines are backed up, when, what errors they've seen, etc.




Lately I've started seeing more and more "error 220" messages, indicating a problem connecting to the UNIX servers. This coincides with a change made to the servers around the time these errors began to appear. This leaves me with a couple of problems I don't seem to be able to resolve.




First, when one of these error messages appears, Retrospect halts in its tracks and stays halted. This means if I am out of the office, a critical server might not get backed up for days, as it's just sitting there with an error message on the screen. It halts even if I've told Retrospect in its preferences NOT to stop on errors.




Second, when one of these errors occurs and I am not instantly aware (which is most of the time, since the Macs are scattered across 3 buildings of 2-6 floors each), I have no way to know the exact time of the error. All the Operations Log tells me is that the backup started at X date/time, had Y error, and ended at Z time. From the data in the log, the error could have occurred any time between the start of the backup (e.g. 8pm on Tuesday) to the end of the backup (e.g., when I saw no response from the machine by Friday at noon).




Because of the first issue, any time an error crops up that machine stops backing up.




Because of the second, I can't work as easily with my UNIX admins to pinpoint the cause of the error since I can't really pinpoint the time it occurred. It might have happened a few minutes after the backup began, a few hours, etc. Those hours could make all the difference between understanding why the error occurs and what can be done about it.




Can anyone offer help/suggestions for dealing with these issues?

Link to comment
Share on other sites

  • 4 months later...

Error 220 (server is not responding) is considered a fatal error and the backup will stop. The same thing will occur if backing up to a tape drive and the tape drive issues a hardware error. Essentially, there is no more backup device available (in this case FTP). Retrospect cannot continue past this error for clear reasons - there is no place to store the data...




The question of when the error occured - or more correctly how to notify you when it does occur - can be solved by using the Retrospect AppleScript Event Handler for email notifies in the Retrospect application folder. The setup will allow the program to email you when a backup fails. Is the error 220 time stamped in the log? The email report should go a long way towards helping you pinpoint the time of the errors.




The overall fix would be to determine why the FTP server is losing communication with the backup serer.





Link to comment
Share on other sites


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

  • Create New...