Jump to content

dkatz42

Members
  • Posts

    33
  • Joined

  • Last visited

dkatz42's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Did you change the time zone perchance? Dantz continues to insist that this should cause files to be backed up again because the creation/modification times change, though under OS X this information is actually stored as UTC (without timezone interpretation) so it should be trivially detectable. I have to leave my timezone alone as I move back and forth to avoid this problem, sigh.
  2. Versions: Retrospect Workgroup 6.0.193 running under Mac OS 10.3.3 on a DP G5, Retrospect Client 6.0.108 running under Mac OS 10.3.3 and OS 10.2.8 on various G4 machines Problem: Occasionally (once a month to once a week) certain clients will stop backing up. The only indication this is happening is to notice that the Backup Server screen says ASAP on the next backup, and eventually the client complains that it hasn't been backed up in seven days. Bringing up the client app, the display says "in use by root" but the server doesn't seem to think so (and there's no other server, and it stays in this state indefinitely.) If you query the client status from the server, the status reports back as "busy." An attempt to unhang the client by clicking the "off" button or option-"off" changes the client status to "connected", which then persists indefinitely. The only way to recover is to become root and kill pitond, which results in the status in the client app changing to "not running". Then click the "on" button and it all works again. The server log entries corresponding to this client appear as follows: + Normal backup using Santa Cruz Server at 4/17/2004 6:35 To backup set Santa Cruz Server… - 4/17/2004 6:35:03: Copying Santa Cruz Server on Santa Cruz Server… 4/17/2004 6:35:03: Connected to Santa Cruz Server 4/17/2004 7:19:59: Comparing Santa Cruz Server on Santa Cruz Server… 4/17/2004 7:20:09: Execution completed successfully. Completed: 22 files, 7915 KB, with 0% compression Performance: 4.5 MB/minute (2.3 copy, 46.3 compare) Duration: 00:45:06 (00:41:42 idle/loading/preparing) + Normal backup using Santa Cruz Server at 4/18/2004 9:16 To backup set Santa Cruz Server… Can't access volume Santa Cruz Server on Santa Cruz Server, error -1028 (client is not visible on network). 4/18/2004 9:16:21: Execution incomplete. The log window on the client shows the last successful backup (the 4/17 run in this case) as the last entry in the window, with no mention of the 4/18 attempt. The server log shows no entries after the above entry (no indications of successive attempts.) The backup started as soon as I killed and restarted pitond on the client. Other times when this has happened the server log showed a 505 error as the last entry for the wayward clients. It looks like pitond is left in a state where it thinks it has an active connection, even though that connection is long gone (does it use TCP keepalives? It should!) This happens often enough so that I need to manually check the server every couple of days lest my backups grind to a halt. Manually intervening for the significant number of clients I operate is painful (and unacceptable.) Anybody else see this? Dantz, if you need any more information, please feel free to contact me here or by email.
  3. I do a fair number of full restores (doing brain transplants between various machines for a variety of reasons) and the smoothest way I've come up with is to boot the machine being restored in Firewire Target mode (hold the 'T' key down) and plug it directly into the backup server as a disk. Then use Disk Utility to wipe the target disk, and do the restore. Then bless it using the Startup Disk preference pane on the server. Works every time.
  4. I recently upgraded to a G5 and have been seeing similar problems. Sometimes I get large numbers of compare errors; other times I get checksum errors in the catalog. Exiting Retrospect doesn't help, but rebooting the computer does. Very disurbing. I'm running 10.2.8 on a DP 2GHz G5, with the latest 5.1 and drivers installed, backing up to the same external FW drive I used on the G4 with no problems whatsoever. I'm guessing either a G5 problem or a 10.2.8 problem. Ugh.
  5. Perhaps I'm missing something, but I can't get the drive to work. Is there something beyond the standard Apple drivers required for OS X? The drives no longer ship with Toast, but rather with Charismac Discribe, for what that's worth. The web site says: Macintosh: This drive is supported with the following minimum extensions: Toast 4.1.1 (must have version 4.1.1 installed) Toast CD Reader 4.1.1 Toast FireWire Support 1.0.1Retrospect SDAP Support 1.2 How do these extensions relate to OS X? What exactly do I need to use this drive under OS X? Thanks for responding, by the way.
  6. Is the EZquest 48x12x48 FW CD-R/W supported under OS X? There is some cryptic note in the qualification for this drive stating the requirement for a bunch of extensions, which seems to imply an OS 9 requirement. It doesn't say a peep about OS X. What is the scoop?
  7. I do something like this on occasion, though it won't do exactly what you want, and it's not for the faint of heart. Basically I periodically chop the end off of the backup data file, rebuild the catalog, and then do a backup. This actually gets rid of newer backups rather than older ones, but you end up with the newest data (and it reduces the size of the file.) If you know roughly how big the data file was at the time of the original backup you can get rid of most of the redundant backups. Basically I run the backup data file through the Unix "split" utility, patch the file type and creator with a handy freeware utility so that the truncated file looks like a Retrospect file again, run the catalog repair function on it, and then back up to it. Ugly and manual, but it does the trick. It'd be much nicer if you could simply go into Retrospect and delete whatever snapshots you wanted to delete and then compress the data file, of course.
  8. Cool tip, thanks. If you look hard enough, you can find most of Unix...
  9. Sorry about the confusion... The fact that the second volume contains OS 9 is immaterial; it's just that there are two independent volumes. All of the Retrospect stuff is OS X only, and I only run OS X. By "configuring both volumes" I meant that I left the default (both volumes selected) and then set up the script to have both volumes as the source. I fixed the problem by going back to the client configuration and noticed that there were three volumes listed (uhoh), with the OS 9 volume listed twice. I deselected one of the OS 9s and reselected the OS X, and fixed the scripts.
  10. Periodically (weekly) I log into my server and notice that Retrospect isn't running. Looking at the log, there is no message of any kind (no "shut down" message, etc.), which leads me to believe that Retrospect exited abnormally. Is there somewhere else I can look for some indication as to what caused Retrospect to fail? A system log, perhaps? Hard to open a cogent bug report without some other information. Mac OS 10.1.5, Retrospect 5.0.205. (Any hope of a maintenance release soon? There's got to be a bunch of pent-up bugfixes by now...)
  11. I have a client on which I installed OS X and OS 9 as two separate volumes. I dutifully configured both volumes when I logged in the client, and set the source in the script to back up both as well. For the most part this seems to work fine. However, every once in awhile the settings get corrupted (my guess, anyhow) such that it ends up with the first volume listed twice, rather than the two volumes. It then goes and backs up the first volume twice, ignoring the second. This corruption seems to be at the client configuration level; if I open the client configuration screen, it shows the same volume listed twice (and this is echoed back to the scripts.) This has happened three or four times since I started running Retrospect 5. Both server and client running OS 10.1.5, Retrospect 5.0.205.
  12. There are real problems with running any OS 9 client against Retrospect 5 under OS X if there is any packet loss at all (more likely with wireless or Internet connectivity.) There is a thread on the subject from a few weeks back, and I provided very detailed debugging info but have not heard anything at all in reply. I'm punting and using it as an excuse to finally upgrade the rest of my office to OS X, which I needed to do anyhow, but it's the coward's way out...
  13. In the case where it declares the 519, it does move on. It's the case where it doesn't declare the 519 that it hangs. In any case, it shouldn't be declaring a 519; the software is broken.
  14. Should have read your post more closely, sorry... I'm having a little trouble parsing your chart--do OS X <-> OS X operations work reasonably well? I would expect some degradation of speed over OS9 <-> OS9 due to additional overhead introduced by all of the good software and hardware stuff that makes the system more stable. The OS X TCP is very clean and straightforward (and *extremely* well tested, unless Apple did something really stupid like touch the code.) Judging from "netstat" output, Retrospect is using the standard kernel services and not doing something bizarre like opening a raw IP socket and implementing TCP in the application. I've run into serious problems running an OS X server against an OS 9 client (see the thread on remote backups hanging) and after running tcpdump and pawing through the results have discovered that there is something really horrible going on in the client/TCP stack under OS 9, which may or may not be triggered by something that the OS X server is doing. In that case, if a packet from the client is lost, the client fails to send anything further after the retransmission of the lost packet (while ignoring the offered TCP window.) I don't know anything about the OS 9 TCP/IP stack, nor the level of the interface that the applications see, but there is clearly something rotten there. Perhaps you're seeing a different version of similar symptoms. The TCP stream can be enlightening if you're a masochist. The number of retransmissions, the offered windows on each side, and the delay between packet receipt and acknowledgement transmission can give some hints on the dynamics. Assuming that the link is clean and the Ethernet parameters all match, a healthy TCP should never run more slowly at 100Mbps than at 10. In this case it sounds like a timing-related bug in either the OS 9 TCP or the applications.
  15. Woops, looks like the forum software thought that the ifconfig flags were markup tags and stripped them from the post. The flags were UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST...
×
×
  • Create New...