Jump to content

Recommended Posts

Our Retrospect backup crashes on almost a daily basis at the moment and we cannot see why. Most of the time Retrospect just quits out but once or twice a week it will crash the whole server and force a restart. When I view the server in the morning it opens at the OS X log in screen with an Error telling me that Retrospect has encountered an error and that OS X had to be restarted. When we go to the console logs there is no crash log created for Retrospect and the only thing that shows up in the crashreporter.log is:

 

"Sun Jul 29 18:14:49 2007 crashdump [117] : crashdump invoked as panicdump"

 

We are using Retrospect Workgroup version 6.1.126 running on 10.4.9 Tiger Server on a XServer G4. Can anyone help point me in the right direction or shed some light on this issue?

 

Much appreciated!

 

Leon

Link to comment
Share on other sites

Quote:

Can anyone help point me in the right direction or shed some light on this issue?

 


 

You have to start, by providing more complete information.

 

> We are using Retrospect Workgroup version 6.1.126 running on 10.4.9 Tiger Server on a XServer G4

 

Please provide the RDU that you're running, and _all_ the hardware being used. And the Type of Backup Set(s) you are using. Oh, and the product name is "XServe"

 

> Most of the time Retrospect just quits out but once or twice a week it will crash

> the whole server and force a restart

 

But you are not getting a kernal panic? How, then, are you forced to restart the server? What exactly are you seeing?

 

> The server is used for file sharing throughout the day and has no problems

> running other memory intensive apps.

 

Retrospect is actually quite the memory hog, so the fact that other programs run without error proves nothing. But given the lack of hardware information in your post it's impossible to know what might be going wrong.

 

Dave

Link to comment
Share on other sites

Thank you for your post Dave.

 

> Please provide the RDU that you're running, and _all_ the hardware being used. And the Type of Backup Set(s) you are using.

 

I think the RDU is 1.0.107 although this is the Device Access Version. The Driver Update Version field is blank. If this is not correct then please let me know where I can find it. The backup is writing to an LTO3 tape library on an Adic Scalar24 LTO3 attached via a ATTO UL3S 66S backing up around 3.5TB of data in total. The Xserve is a Dual 1GHz PowerPC G4 2 MB L3 cache per processor, 1 GB DDR SDRAM running 10.4.9. If more information is required please specify.

 

> But you are not getting a kernal panic? How, then, are you forced to restart the server? What exactly are you seeing?

 

What I meant by this is that the Xserve must have restarted itself as when I log on in the morning it is already at the login screen with an error message in a pop up window stating that Mac OS X had been restarted. There is no kernal panic screen being displayed asking me to restart. This may be because our Xserve is set to restart itself after a crash. Since these crashes are happening at night or on weekends we are not here to witness if this is a kernal panic or not.

 

> Retrospect is actually quite the memory hog, so the fact that other programs run without error proves nothing.

 

So if this is a memory problem causing a kernal panic then should this not be consistant? i.e. happen every time we run our backup? What do you suggest? Should I run diagnostics on the RAM?

 

Leon

Link to comment
Share on other sites

Quote:

The Driver Update Version field is blank.

 


Then you are not running an RDU, and need to be doing so because, in addition to providing additional driver support, EMC/Dantz/Insignia/whatever sometimes includes bug fixes in the RDU, too. So there is a chance that the absence of an RDU is a problem. The RDU updates are here, and I suggest that you update to the current RDU version (6.1.11.101):

RDU version history

 

You will see the RDU version given in the "About Retrospect" dialog field that is presently blank, and also in the Retrospect Log (Retrospect logs the RDU version and Retrospect version on each launch).

The RDU file goes in the Retrospect folder in your /Applications folder, just like the Retrospect app.

 

Quote:

The Xserve is a Dual 1GHz PowerPC G4 2 MB L3 cache per processor, 1 GB DDR SDRAM running 10.4.9.

 


That's a bit light on the RAM for a DP Xserve running Retrospect under Mac OS 10.4.x Server. I'd suggest 2 GB. There may be some bug that all of the paging is causing to surface. There is also the possibility that you are having memory issues, but your Server Monitor program should be logging ECC errors if that's the case. RAM issues on an Xserve are very rare because of the ECC, so I doubt that it's a bad RAM issue. But it could be a motherboard or I/O subsystem issue, or a bad cache on one of the processors.

 

Does your tape drive have any diagnostics that you could run for an extended time? Have you checked to see if your ATTO UL3S firmware and driver is up to date? Those updates are here:

ATTO updates

 

Apparently the current UL3S driver for Mac OS 10.4.x is v3.21, and the firmware is v1.6.6f0 (Released 7/15/2003).

 

Have you checked to see if your tape drive firmware is up-to-date? Hard to imagine how tape drive firmware could cause a Kernel Panic unless it's causing some poorly-tested driver or kernel routine to be exercised.

 

There's a possibility, with all the crashing, that you've got some corrupted preference files in /Library/Preferences/Retrospect

You might want to drag those files to the desktop (to preserve them, in case something goes badly wrong) so Retrospect won't seen them, and re-configure and re-enter license codes, etc. That would eliminate the corrupt preferences possibility.

 

And just as a rare outside possibility, have you considered power issues? Is the server on a good UPS?

 

Oh, one more thing: Do there happen to be any other devices on the UL3S single SCSI channel other than the tape drive? I saw an issue a couple of years ago with Retrospect causing the system to hang during its device discovery, worked around by putting our tape drive on a different SCSI channel from a RAID 1 mirror SCSI disk used by the OS. But that doesn't seem to be your issue because I never saw a panic, only a hang that I believe was caused when Retrospect's device discovery caused (occasionally) a SCSI transfer or interrupt to be dropped for the disk.

 

Just some thoughts for investigation.

 

Russ

Link to comment
Share on other sites

Thanks very much for the suggestions. Indeed there was no ADU file present so I have now downloaded Version 6.1.11.101 and placed it in the Retrospect applications folder. I will also try out your other suggestions and let you know.

 

Thanks again

 

Leon

Link to comment
Share on other sites

  • 3 weeks later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...