Jump to content

ArsonAndy

Members
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ArsonAndy

  • Rank
    Occasional Forum Poster
  1. I had the same error (elem.c-923) when backing up a Windows XP Pro ThinkPad to my Mac OS 10.4.7 PowerBook G4 running Retrospect 6.1.126 RDU 6.1.7.101. It was working fine until just a day or two ago. Then all of a sudden, the errors. After looking here, and trying several solutions (restart Retro client, restart ThinkPad, restart PowerBook, new backup set), I found something that worked. I deleted the client from the client list within Retrospect, then added it back. Just finished a backup without error. Hopefully it stays fixed... -Andy
  2. Just did the same thing, with a few differences: 1. Reboot 2. Login and look at Activity Monitor. This time there is one RetroRun and one RetroRunSL process. 3. Retrospect auto-launches some time later. Now there are two Retrospect processes and one RetroRun process. The RetroRunSL process has disappeared. 4. I get a popup from one of the two redundant Retrospect processes saying something about a backup failure possibly due to a power outage. The other process is dutifully backing up one of my network clients. 5. After quitting the redundant process, all seems back to normal.
  3. I keep getting this as well. I'm running Retrospect 6.1.126 with RDU 6.1.5.102 under OS X 10.4.6 on the original 17" aluminum PowerBook G4. I'm backing up to external FW hard drive. Just saw it a few minutes ago. I think it only happens for me after a reboot as well. Here is the most recent sequence of events: 1. Installed QuickTime 7.1 and Security Update 2006-003 (PowerPC) 1.0 via Software Update. 2. Rebooted as required by SWU. 3. Logged in as usual. 4. About an hour later, when my Backup Server Script was due to back up, Retrospect auto-launched. 5. Retrospect quit bouncing in the Dock, and I thought the problem was not going to appear. Then, a few seconds later, another Retrospect began bouncing. 6. I looked in Activity Monitor and had two Retrospect processes and two RetroRun processes. The parent of all four was launchd(1). 7. I quit the second copy of Retrospect, as the first had already begun backing up. There were still two RetroRun processes active. 8. I quit the other Retrospect process. There were still two RetroRun processes. After launching Retrospect again, finally one of the two RetroRun processes terminated. I do have my hard drive cloned to external FW hard drives, so I have multiple copies of Retrospect on external drives, but the two copies that were running both pointed to the same executable on my internal HD. Will try to do some more troubleshooting to gather more info.
  4. This is mostly an informational post, as I worked through the problem and came to a satisfactory solution for myself. I am posting this in hopes it may help others. I set up Retrospect to backup my RedHat 7.3 box (6.5.108 client) to DVD on my PowerBook (Desktop 5.1.175). I was backing up fine over AirPort with my AEBS configured as a bridge. I was also backing up an iBook over Airport. Then, I enabled NAT on the AEBS. Backups still worked from the iBook, but not from the Linux box. Figuring my AEBS was blocking the communication (I later verified this), I attempted plugging my PowerBook into the ethernet. It didn't work. I could ping, telnet, etc. and they were on the same subnet, but Retrospect would not backup the Linux box. So, naturally, I removed the client from the Backup Client list in the Desktop, then tried to add it back. It could not find it. I tried quitting and restarting the server and the client, removing /var/log/retroclient.state, and even reinstalling the client. Nothing. I used tcpdump to show that the Linux box was getting the multicast packets from the Desktop, but was not sending anything back. Then, I noticed it was trying to send a responses to the AirPort IP address, but ONLY when AirPort was "On." When AirPort was "Off" on my PB, absolutely nothing was sent back. I reconfigured my AEBS as a bridge and now it sees the Linux client and I am backing up over ethernet. However, it still only works if my AirPort is "On" even though it backs up over ethernet. I'm wondering if the multicast packet the Desktop sends out indicates what IP the client should respond to. Perhaps the Desktop had an old idea of what the correct IP is, and was setting this erroneously to the AirPort interface's IP address. Maybe deleting the Retrospect Desktop preferences or reinstalling the Desktop would have removed whatever state would be causing that, but I didn't try. Further testing with tcpdump shows that the IP address of the AirPort interface is in fact sent in the multicast packet. No matter what I set the IP to, that's what gets sent. If AirPort is "Off" then 0.0.0.0 gets sent.
×