Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 Oh, right. but I'm wishing to avoid that. All the computers I run here are OSX-booting only. We have been off OS 9 since 10.1 was released. Certainly, if there was *no other option*, I'd move the machines back to OS 9 (or, more likely 10.1.5 if that's supposed to work.) If Dantz Q/A has duplicated this, they should be able to figure out a solution. Right? Link to comment Share on other sites More sharing options...
Mayoff Posted March 19, 2003 Report Share Posted March 19, 2003 Yes, with your help finding a solution should be possible. The question is, when will the solution be rolled into the product and made available. I don't have the answer to that question. Amyc will be contacting you directly to get some more details about your error logs. Link to comment Share on other sites More sharing options...
Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 Cool. You can't believe how bad this infects us. We have to constantly monitor the backup servers now because we can't be sure they are just running by themselves. And I have a week's vacation coming up in April. :-/ Link to comment Share on other sites More sharing options...
Mayoff Posted March 19, 2003 Report Share Posted March 19, 2003 Is it possible to schedule the backups to run later in the evening so you are less likely to experince a restart during the backup process? Link to comment Share on other sites More sharing options...
Maser Posted March 19, 2003 Author Report Share Posted March 19, 2003 I've thought of that -- just changing the backup server script to not start any backups between 4:00 p.m. and 8:00 p.m. But that doesn't address the user who starts his full backup at 3:30 p.m. and doesn't stop the backup until he shuts down at 5:30 p.m. for the day because the backup hasn't finished. (I have this right? backup server doesn't terminate the backup -- it just won't start *new* backups during inactive times, right?) And the *worst* thing I could do is publicize this (ie, telling my users not to shut down during a backup). While I tend to trust my users, the last thing I want to see is to have somebody try this by firing up the client to start a backup ASAP and then shutting down 5 minutes after their backup starts. Just for the fun of it. It's a bug in the program somehow. Some buffer must be getting overflowed or something somewhere. Anything that can be done to release a patch for this would save us money (as time=money here.) I need to be able to do consistent, frequent backups. I can't if the backup server is "off" for extended periods of the day (either intentionally by modifying the times the backup server is active or *unintentionally* when a user can bring down the program.) Link to comment Share on other sites More sharing options...
resound01 Posted March 27, 2003 Report Share Posted March 27, 2003 I'm experiencing a similar problem, although, it seems to happen everytime my OS X Retrospect Server tries to back up a specific Windows XP client. I'm using the most current patch of Retrospect Server for OS X, and I've tried both the 5.6 and 6 clients on the XP computer. This has been compounded by the problem where RetroRun fails to work (basically Retrospect crashes everytime it's manually run when it gets to the script for this one XP computer, and it won't autolaunch). Do I need to point out that this is an enormous headache? The retrospect.crash.log reports this everytime the crash occurs (which seems to be on every attempt): Date/Time: 2003-03-27 12:51:59 -0500 OS Version: 10.2.3 (Build 6G30) Host: <my computer>.med.tufts.edu Command: Retrospect PID: 1269 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x201a4801 Thread 0 Crashed: #0 0x001c6b08 in 0x1c6b08 Thread 1: #0 0x9000514c in syscall #1 0x90515d6c in BSD_waitevent #2 0x9051573c in CarbonSelectThreadFunc #3 0x90020d48 in _pthread_body Thread 2: #0 0x9003eaa8 in semaphore_wait_signal_trap #1 0x9003e8c4 in _pthread_cond_wait #2 0x9051dc30 in CarbonOperationThreadFunc #3 0x90020d48 in _pthread_body PPC Thread State: srr0: 0x001c6b08 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x20000000 lr: 0x001c76d0 ctr: 0x001c7610 mq: 0x00000000 r0: 0x201a4802 r1: 0xbfffc4e0 r2: 0x00490000 r3: 0x201a4801 r4: 0x19f34000 r5: 0xbfffd548 r6: 0xbfffd54c r7: 0x60340f00 r8: 0x00301d00 r9: 0x00c07208 r10: 0x00006048 r11: 0x00be1811 r12: 0x0048f3e0 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x4d636864 r17: 0x00000001 r18: 0x00000000 r19: 0x0306f1fe r20: 0x00000000 r21: 0x00015a78 r22: 0x00000000 r23: 0xbfffd548 r24: 0xbfffd54c r25: 0x0147804b r26: 0xbfffc518 r27: 0x00000009 r28: 0x00000001 r29: 0x4019f340 r30: 0xbfffc51c r31: 0x00000004 Link to comment Share on other sites More sharing options...
mcswgn Posted April 1, 2003 Report Share Posted April 1, 2003 Quote: But that doesn't address the user who starts his full backup at 3:30 p.m. and doesn't stop the backup until he shuts down at 5:30 p.m. for the day because the backup hasn't finished. (I have this right? backup server doesn't terminate the backup -- it just won't start *new* backups during inactive times, right?) No. If the backup server is scheduled to not run from 4pm to 8pm, then it will terminate an ongoing backup at 4pm. There is also a "Wrap up" time, that specifies a period prior to absolute stop during which new backups won't be started. You would probably have to set wrapup time to be fairly short or computers that are only on during the day would never get their backups started--but then you will have to deal with a lot of backups that terminate in the middle. I'm not sure there is a great solution here. Link to comment Share on other sites More sharing options...
Maser Posted April 1, 2003 Author Report Share Posted April 1, 2003 Thanks. Hadn't really thought of that as a possible *short-term* workaround. I'm really counting on Dantz to address this in the next release. :-/ Link to comment Share on other sites More sharing options...
Maser Posted April 9, 2003 Author Report Share Posted April 9, 2003 FWIW -- today -- for the first time -- I've had two Mac OS X clients do this. I saw one backup issue a "net retry" message briefly, then Retrospect quit outright. I've been unable to contact the user (a laptop user who left -- so I'm not sure how he disconnected from the network). Something is overriding some "buffer" depending on where the backup is in progress when the client disconnects from the network (however they do it.) AARGH! Link to comment Share on other sites More sharing options...
Maser Posted April 11, 2003 Author Report Share Posted April 11, 2003 10.2.5 did *not* fix this problem. Unfortunately... Link to comment Share on other sites More sharing options...
Maser Posted April 11, 2003 Author Report Share Posted April 11, 2003 I know I'm being a pain, but... I'm watching all my backup servers crash *every day* -- frequently many times a day -- this week. Windows (and now Mac clients) are restarting/shutting down during backup in backup server and it's killing the backup server outright. Is there any way you can check with Q/A to find out: 1) If the problem will be resolved in the next version? 2) If not, if they can make an honest recommendation as to what would resolve my problem if it's a hardware issue? (ie, replacing the SCSI cards, or something...) I'm going to pull my hair out over this one soon. - Steve Link to comment Share on other sites More sharing options...
mick2up Posted May 21, 2003 Report Share Posted May 21, 2003 I just posted the same thing today and just came across your message. I am just as frustrated. Our only difference is that I don't back up ANY Windows clients...just OS X and OS 9. So it is NOT something to blame on Windows. Link to comment Share on other sites More sharing options...
jolshefsky Posted May 22, 2003 Report Share Posted May 22, 2003 (I'm cross-posting from Retrospect Unexpected Quits without a note in log) This is may be a solution for some of you (although it implies that a clean install should work.) I'm having the same problem as resound01--at least a similar crash log. In a nushell, the problem is that Retrospect 5.0 Desktop on Macintosh OS X 10.2.6 Jaguar would start a backup, scan all the files, check the folder permissions, then crash, leaving behind only a Retrospect.crash.log file with debugging data. I started hunting around and found that the installer for 5.0.238 would NOT overwrite the application in /Applications/Retrospect 5.0. I checked the version using Get Info on the application file and found it was still 5.0.201. I tried installing to a different directory then copying the Retrospect 5.0 folder into /Applications. I got past the point where the crash would occur, but haven't yet had a chance to check to make sure it finishes okay. The Get Info now reports 5.0.238. Good luck if this helps at all. I had a 10GB backup run for 11 hours without incident before I had to stop it and go to work. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.