doorknob Posted May 4, 2002 Report Share Posted May 4, 2002 Okay, I see tons of posts of Retrospect Server crashing... how about the clients? I have two OS X client machines which are rendered inoperable by being backed up. The specifics are... * Latest Retrospect server and clients, as of 5/3/02. * 10.1.4 on all machines (tho' it was on 10.1.3 a few weeks ago and it was doing the same thing) * One client runs Communigate Pro and shares 3 or 4 folders as "volumes" for backup. * The other client has about 400 user accounts - each defined as backup source. * The server backs up to an Internet volume (a SNAP server) - but the Retrospect server itself isn't crashing, so that's not terribly important. * The backups are on a 3 day cycle. And, quite effectively, it crashes my two OS X clients every three days. Sometimes the backups make it through all of the sources, THEN the client dies... other times it dies halfway through. By "die" I mean locked up... dead... kernel panic. Occasionally (very occassionally, the Communigate Pro machine w/ 3-4 backup sources won't crash). I've set both clients to "Read Only", thinking that might help. No such luck. I ran the EXACT SAME SETUP with Retrospect 4.3 and the beta clients, and NEVER EVER had a single problem. Not one. This is so fricking annoying that I've rigged a Linux machine to sit there, monitor the two machines and use X10 controllers to power cycle them if necessary. There is nothing unusual in the /var/log logs and nothing at all in /Library/Logs. I have a few NT and 2000 clients that work just fine. If I could get back the functionality I had w/ Retrospect 4.3 and the beta clients, I'd love to. I'm hoping that someone else will speak up with the same issues. (and I'm especially hoping to hear some sort of resolution, suggestions, etc. from the folks at Dantz). Sincerely, John Link to comment Share on other sites More sharing options...
nuclearice Posted May 5, 2002 Report Share Posted May 5, 2002 Sounds like the same issues a bunch of us are having with ASIP servers, and others with File Sharing... I know they are aware of the problems.... Hang in there...I am running all backups on all my ASIP servers with a separate machine, running Retro 4.3 now to eliminate the problems... You might skim through the posts and see if anyone has anything similar to you. I think you might find a few... Rick Link to comment Share on other sites More sharing options...
Guest Posted May 10, 2002 Report Share Posted May 10, 2002 *UPDATE* Some customers have reported problems when backing up AppleShare IP servers with both Retrospect 4.3 and 5.0. There is one problem reported with Retrospect 5.0 running on an ASIP server, where Retrospect is definitely not the cause: The ASIP server crashes when Retrospect 5.0 autolaunches or is launched from an alias. We have identified this to be a problem between Mac OS 9 and the ASIP software that may occur when any Carbon-style application is launched from an alias. We have duplicated this behavior using other Carbon applications, and we have reported the issue to Apple. Other reported problems currently under investigation include: Retrospect 4.3 running on an ASIP server asserts failure or hangs during the backup's copy phase. The ASIP server locks up when the first user logs in following a backup of the server with the Retrospect 4.3 client. The ASIP server crashes at the beginning of a backup with the Retrospect 5.0 client. Retrospect returns "error 1 (unknown)" for some files backed up from an ASIP server with the Retrospect 5.0 client. Due to the complexity of the AppleShare IP software and the difficulty in reliably reproducing these behaviors in a controlled environment, Dantz has been unable to establish that Retrospect is the cause of these problems. As such, we have opened a developer support case with Apple to determine the root cause of these issues. We consider this to be a matter of the highest priority, and we will provide additional information on these issues as soon as we have anything significant to report. Thank you, Dantz Technical Support Link to comment Share on other sites More sharing options...
doorknob Posted May 12, 2002 Author Report Share Posted May 12, 2002 Excuse me Dantz, Retrospect is crashing my OS X *Clients*... not Appleshare IP machines. While I understand that there are Appleshare IP issues as well, this has very little to do with my problem. I've even disabled File Sharing on both machines for good measure. Quite simply - Retrospect 4.3 running on OS 9 w/ the beta clients for OS X did not /once/ cause a system problem. Retrospect 5.0 running on OS X (which is incidental, because the Retrospect 5.0 Server HASN'T crashed on OS X for me) crashes the OS X clients each time it runs. Like clockwork. >Due to the complexity of the AppleShare IP software and the difficulty in reliably reproducing these >behaviors in a controlled environment, Dantz has been unable to establish that Retrospect is the cause > of these problems. I can happily reproduce MY issues for you every 3 days when the backup runs If you give me some non-time-expired copies of your beta clients, my issues would all disappear. As it stands, I have 400 public_html folders that occassionally get backed up and regularly have service disrupted. My only guess as to what could be causing the problem is the number of subvolumes used on the client. 400 is much higher than I'd guess most people use, and I have successfully backed up fewer subvolumes successfully. Thanks, John Ray Link to comment Share on other sites More sharing options...
CallMeDave Posted May 12, 2002 Report Share Posted May 12, 2002 In reply to: Retrospect 5.0 running on OS X (which is incidental, because the Retrospect 5.0 Server HASN'T crashed on OS X for me) crashes the OS X clients each time it runs. The specifics are... * The other client has about 400 user accounts - each defined as backup source. * The server backs up to an Internet volume (a SNAP server) - but the Retrospect server itself isn't crashing, so that's not terribly important. To be clear, you have 400 defined subvolumes in Retrospect's Volumes Database? I'd agree that's extreme. Why not define "/users" as a volume instead? Perhaps make custom Selectors to exclude directories you don't want to back up? (note that while the OS X Finder doesn't have Labels, Retrospect does respect them in Filters. The shareware XRay program _can_ assign lable tags to files and folders in OS X). To be clear, are you backing up to a File Backup Set via AFP on the SNAP server (as opposed to an Internet Backup Set that uses ftp)? Dave Link to comment Share on other sites More sharing options...
doorknob Posted May 12, 2002 Author Report Share Posted May 12, 2002 The reason for the 400 subvolumes is the ease of restores. For the people who handle restores, going in, picking the account to restore and clicking "Restore" is a much faster process than wading through the entire /Users set - and much less prone to operator error. I had originally tried /Users, but found that it was more of a hassle (and, for the sake of consistency, the backup would never actually make it through the entire /Users directory without hanging.) Regardless, aside from a memory leak, I see no reason why 400 is an unreasonable number to expect the software to handle. And, again, 4.3 and the beta clients had no problem with the same task. If there is a limit of "400 subvolumes or we'll crash your machine", I think Dantz had better build the limit into the software and documentation. Until that point, I'm only asking the software to do what it's advertised to do. (One point tho - it was the beta client that never made it through /Users without hanging. Perhaps I'll try it again now, but I'd much rather have the help-desk people deal with individual subvolumes than /Users) >To be clear, are you backing up to a File Backup Set via AFP on the SNAP server (as opposed to an Internet Backup Set that uses ftp)? I'm backing up to an FTP Internet Backup Set. There are absolutely no Appleshare volumes involved. --- John Ray Link to comment Share on other sites More sharing options...
CallMeDave Posted May 13, 2002 Report Share Posted May 13, 2002 In reply to: I see no reason why 400 is an unreasonable number to expect the software to handle. Mostly I was surprised since these definitions live in the Retrospect preference files, which historically have had the ability to become corrupted. I'd rather have a method that didn't require me to define 400 of anything, ever. YMMV. Dave Link to comment Share on other sites More sharing options...
doorknob Posted May 13, 2002 Author Report Share Posted May 13, 2002 Very good point --- John Link to comment Share on other sites More sharing options...
CallMeDave Posted May 13, 2002 Report Share Posted May 13, 2002 I gave a lot of thought to this last night. Especially the part: I ran the EXACT SAME SETUP with Retrospect 4.3 and the beta clients, and NEVER EVER had a single problem Each of the client machines that are now having a problem ran pre-release versions of the software? How thorough were you in removing all traces of the older software? The original beta client stored files in a different place then the later Macworld preview or the release, but I think that the process will still see the older files if they're there. There were lots of posts to the original Dantz discussion boards about the various locations of these files. Also, it would to know the specific configurations of the client machines that are crashing. What model of Mac, what pci cards if any, etc etc etc. Kernal panics on OS X are pretty rare; Dantz would need to know all the facts to figure it out. Dave Link to comment Share on other sites More sharing options...
doorknob Posted May 13, 2002 Author Report Share Posted May 13, 2002 >How thorough were you in removing all traces of the older software? /private/var/log/retro* /Library/StartupItems/retro* /Applications/Dantz* (Dantz Beta, I believe it was called) Checked through ~/Library/Preferences (for the installing user) and ~root/Library/Preferences as well. Don't remember if I found anything dantz/retrospect/pitond related or not. I think there was a "retroclient.state" file lying around somewhere... >Also, it would to know the specific configurations of the client machines that are crashing. >What model of Mac, what pci cards if any, etc etc etc. Kernal panics on OS X are pretty rare; >Dantz would need to know all the facts to figure it out. I don't really see that as the case. If Retrospect Server was crashing, I'd agree. But I would sincerely hope that the client operates at a high enough level that my PCI cards would be of no significance. Dantz... comments? Thoughts? That said, the machines are quite dissimilar. One is a B&W G3 400, with all storage ATAPI based. The other is y2k G4 500 w/ whatever Apple's BTO Ultrawide SCSI card was at the time. Rage 128s in both. 1 GB of RAM in each. I'm not sure if I mentioned this before, but the crash happens almost always immediately /after/ the backup has completed. Occassionally it will crash during the backup, but very rarely. >Kernal panics on OS X are pretty rare; On reasonably low-volume machines, I'd agree. We run a "medium" volume web server (multi millions of hits per day) that will rarely survive more than 10 days without a reboot. I wrote a little virus checker for CommuniGate Pro on OS X that attempted to use Perl threads. A cleanly compiled Perl 5.6 w/ thread support would take the machine down after 4-5 hours. Yes - I'm quite certain my threads cleaned up after themselves properly. I ended up using fork() with better results, but nonetheless, it's pretty simple to induce a kernel panic in OS X. (Of course, thread support in Perl is a mess, but running the exact same setup on a RedHat machine yielded no such trouble). --- John Ray Link to comment Share on other sites More sharing options...
jeffland Posted May 15, 2002 Report Share Posted May 15, 2002 Also Mac OS X client problems! Clean Mac OS X 10.1.4 on G4/733 using GigE via Cisco. Only other large process is Filemaker. This is the client. It has never had a beta Retrospect. Clean Mac OS X 10.1.4 on G3/400 also using GigE Stallion. Retrospect Server for X. Retrospect Server kills the client it knows about when I went to search and add a second Mac OS X client to the Server configuration. Very fun! When Filemaker introduced its server for X there was a issue discovered with G4s and GigE that prevented the server from being visible to clients. Filemaker admitted that the G4s had a unique speed "issue" and they would need to adjust the server. I wonder if this is also somehow related. I'd love to ask Dantz but my support options have run out. Link to comment Share on other sites More sharing options...
CallMeDave Posted May 15, 2002 Report Share Posted May 15, 2002 In reply to: Retrospect Server kills the client it knows about when I went to search and add a second Mac OS X client to the Server configuration. Wierd! What, exactly, do you mean when you say "kills the client?" If the Retrospect Client application window is open, what do you see in the Status box before and after you "search and add" another client from the Retrospect application? Dave Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.