Retrospect crashes servers after RAM upgrade

[Janet]

We have been running into a Retrospect problem when attempting to upgrade RAM on two servers to 1 GB.

 

 

 

Server configirations:

 

B&W G3, 512MB RAM, OS 9.1, ASIP 6.3.3, Micronet 250MB RAID (5), Retrospect 4.3 client loaded.

 

Dual G4, 512MB RAM, OS 9.1, ASIP 6.3.3, and a Sledgehammer (Rorke) 700 GB RAID (5), Retrospect 4.3 client loaded.

 

 

 

Problem:

 

When upgrading RAM on both servers to ANY amount over 512MB then running our Retrospect scripts, the servers crash (lock up completely) immediately after the first user logs in. When we take the machines back down to 512MB it works just fine. (NOTE: Only the Retrospect client is loaded on each of the servers as Retrospect backs up over the network -the application is running on a seperate machine.)

 

 

 

One of the first things we tried was to install RAM variations less than 1 GB of RAM, (ie 768MB) with the same results. We then purchased different RAM from another vendor with the thought that it could have been that particular type of RAM which caused the problem. The results were the same.

 

 

 

After having contact with Dantz on this issue, it was suggested that we gather information about the crash by running MacsBug on the servers. However, when the crash happens, and the create 'standard log' command is entered, it locks up the MacsBug program, forcing us to reboot - and no log is ever saved.

 

 

 

We would really like to improve our server performance by increasing the RAM, but have been working on this issue longer than six months with no positive results. Currently waiting to hear from Dantz on a next possible test or fix . We'd appreciate any input anyone may have on this. Thanks in advance!!

 

 

 

-janet

 

 

[Mayoff]

We are still investigating this issue.

 

 

 

The problems reported fall into, but are not limited to, these main

 

categories:

 

 

 

1: AppleShare IP or Retrospect crash when Retrospect is running a

 

backup. This may happen during scanning, matching, copying or comparing. Retrospect may also quit with an assert at elem16.c-438.

 

 

 

2: AppleShare IP hangs when the first user logs in via Mac Manager (not AppleShare) after Retrospect has backed up the server.

 

 

 

We have found that the following does help reduce these crashes:

 

 

 

1) Try allocating more memory to Retrospect via the get info Window in the finder

 

 

 

2) Turn off Sherlock Auto Indexing on the server

 

 

 

3) Configure Energy Saver (or Retrospect if the backup happens locally) to Restart the server every day following the backup or before the first users arrive in the morning.

 

 

 

4) You can try to perform a backup of the server while AppleShare itself is disabled, but this WILL prevent you from copying any AppleShare privileges.

 

 

 

5) If you backup is local to the server, try backing up the server as a client.

 

 

[Janet]

thank you for the response.

 

 

 

Just a few more notes with regard to our situation, in the event it is helpful to Dantz.

 

 

 

-We are not running Mac Manager on either server.

 

-Since we are running the backups as a client on the servers, increasing 'RAM' to the Retrospect application does not seem to apply.

 

-Have turned off Indexing

 

-Since we are a 24/7 shop turning off ASIP for backup is not an option unfortunately. Neither is rebooting as we have Oracle systems that are constantly in communication with our ASIP servers.

 

 

 

So for now we are just running at 512MB of RAM. Our servers and back-ups work flawlessly at this RAM configuration. No problems with it what-so-ever, again ONLY when we increase RAM does the problem begin.

 

 

 

Thank you for any continued help.

[AmyJ]

Dantz has been investigating several problems that customers have reported when backing up an AppleShare IP server with Retrospect 5.0. Reported problems include:

 

 

 

1) The ASIP server crashes when Retrospect 5.0 autolaunches or

 

is launched from an alias.

 

 

 

2) The ASIP server crashes at the beginning of a backup with the

 

Retrospect 5.0 client.

 

 

 

3) Retrospect returns "error 1 (unknown)" for some files backed

 

up from an ASIP server with the Retrospect 5.0 client.

 

 

 

Our investigation has revealed that these problems result from using Carbon APIs with AppleShare IP software. Problem #1 occurs when any Carbon application is launched from an alias, confirming our contention that it is not a Retrospect issue. Retrospect 5.0 uses HFS+ file system calls, as specified by Apple, which stimulate bugs in the AppleShare IP software, resulting in Problems #2 and #3.

 

 

 

We have reported all of these problems to Apple, but Apple's development efforts are now focused on Mac OS X Server. Without a commitment by Apple to address these problems, we have no choice but to suggest that our customers consider replacing AppleShare IP with Mac OS X Server.