yellow Posted July 31, 2003 Report Share Posted July 31, 2003 Latest version of Retrospect Server (pre-5.1), and latest version of Retrospect Client on a G4500 (10.2.6). Can connect to client from server, get a catalog of files/directories, but when it attempts to start backing up said client, the client kernal panics. From the Retrospect Logs ("null" replaces all identifiers) : - 7/30/2003 11:23:26 AM: Copying NullHD on null… 7/30/2003 11:23:26 AM: Connected to null Can't read file “retropds.22”, error -40 (file positioning error), path: “NullHD/Applications/Retrospect Client/Retrospect Client.app/Contents/Resources/retropds.22”. Trouble reading files, error 519 (network communication failed). 7/30/2003 11:35:26 AM: Execution incomplete. Remaining: 55419 files, 5.8 GB Completed: 30077 files, 442.8 MB Performance: 71.0 MB/minute Duration: 00:12:00 (00:05:46 idle/loading/preparing) The amount of Completed files that the Server gets is not a constant, I've had 400+ megs down to 660k. There is nothing identifiable in the panic logs on the client side. I've tried uninstalling/reinstalling the Retrospect client, rebuilting the directory catalog with DiskWarrior3, fsck'ing, and repairing the permissions. Still kernal panix on attempts to back the data up. Suggestions on the next step (pre having to rebuild the OS *shudder*)? Link to comment Share on other sites More sharing options...
CallMeDave Posted July 31, 2003 Report Share Posted July 31, 2003 Quote: Suggestions on the next step Suggest providing more specific information about the crashing machine. Any Norton software? Any SCSI cards? All hardware/software information would be helpful. Dave Link to comment Share on other sites More sharing options...
yellow Posted July 31, 2003 Author Report Share Posted July 31, 2003 No SCSI card, no Norton junk, no 3rd party peripherals. No updates applied since 10.2.6. No newly installed software. Nothing has changed. It's had 10.2.6 on it and been successfully backed up. It just suddenly started KPing for no apparent reason. Link to comment Share on other sites More sharing options...
shadowspawn Posted August 1, 2003 Report Share Posted August 1, 2003 My first suggestion would have been disk repairs, but you have already tried a few. Two others ideas: 1) Install Retrospect on the bad client and run the backup locally. Every file still gets accessed, but the client software is out of the picture. 2) Split the backup into pieces (using subvolumes) to see whether a seriously corrupt file is the problem. Link to comment Share on other sites More sharing options...
yellow Posted August 1, 2003 Author Report Share Posted August 1, 2003 Shame on my for NOT posting that the R* Server is running on 9.2.2. *sigh* I thought I almost had it.. I removed every trace of Retrospect, rebuild the directories with DW3, reinstalled the client, and managed to get 1.3 gigs backed upbefore it went belly up. Again with the: "Can't read file "retropds.22", error -40 (file positioning error), path: blah blah bah" What exactly is retropds.22?? Sadly, I don't want to hang the ATL off of the client machine and install Retrospect on it. My next step is to remove the disk and put it in a machine I know is working ok and trying to back it up from there. Link to comment Share on other sites More sharing options...
CallMeDave Posted August 2, 2003 Report Share Posted August 2, 2003 In all the time I've been watching this Forum I have never read of someone getting a kernal panic on a Client seemingly caused by a Retrospect execution. >What exactly is retropds.22?? - pitond is the unix process that communicates with Retrospect over the network. - retropds.22 is the unix process that delivers files to the remote Retrospect machine. The file positioning error has been around since one of the last 5.0 updates; it prevents that file (which lives inside the Retrospect Client application bundls) from being backed up, but Dantz always said it was a benign error. It has been fixed in 5.1. Moving the HD to another physical host is an excellent idea; please let the Forum know what happens. Chunking the backup into a few defined sub volumes would be an excellent next step, if moving the HD does not make a difference. Dave Link to comment Share on other sites More sharing options...
shadowspawn Posted August 3, 2003 Report Share Posted August 3, 2003 Quote: Can't read file “retropds.22”, error -40 (file positioning error), path: “NullHD/Applications/Retrospect Client/Retrospect Client.app/Contents/Resources/retropds.22”. Trouble reading files, error 519 (network communication failed). Just a clarification, the retropds.22 error and the 519 error (and client crash) are almost certainly not related. As Dave mentioned, the retropds.22 is a known issue but is believed to only prevent the backup of that particular file from the client. (And hence it is not possible to restore a fully functional Retrospect client if you have to restore the whole disk, because that file will be missing.) Link to comment Share on other sites More sharing options...
yellow Posted August 4, 2003 Author Report Share Posted August 4, 2003 So, after 6 hours of testing on Saturday, here's what I have so far: I've tried backing up as subvolumes, and thought I had it nailed down. /Users was fine, /Applications was fine, and then KP on /Applications (Mac OS 9). The culprit (I thought) was an old VPC Windows 95 volume. Removed and backed up /Applications (Mac OS 9) again and it was fine. Great! All fixed! Just for giggles, I tried backing up the whole thing as again.. kernel panic (missed seeing which file was last one it touched). *sigh* Back to the drawing board. So, I hung the disk in a Quicksilver 900MHz as another volume and backed the whole thing up and it worked like a charm. Final test before I give up and try to enjoy what's left of my Saturday (I work too much) is to boot from the disk in question and try backing that up thru the Quicksilver. Sooooo.. in the Quicksilver, I was able to back up the full volume (it was not the boot volume). So I made it the boot volume and tried it again. Again I was able to back it up. So it's likely the hardware original machine that's causing it to kernel panic. I'm going home. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.