Jump to content

Elem.c-812 workarounds


Recommended Posts

Hello,

 

 

 

Dantz has reproduced this error with Retrospect 5.0 and we will work on a solution for everyone. For now, you can use the following workarounds:

 

 

 

1) Turn off Filesharing on the Mac OS 8 or 9 client computer

 

 

 

or

 

 

 

2) Allocate a bunch of memory to Retrospect in the "get info" Window's Preferred Size. 50MB worked for my testing.

 

 

 

Another note:

 

It is possible that very large volumes (servers) will not be able to use the Memory Allocation Workaround. If you can not turn off FileSharing on the Client, then a local backup with Retrospect 5.0 may be an option until a fix is available.

Link to comment
Share on other sites

  • Replies 82
  • Created
  • Last Reply

Mayoff,

 

 

 

Unfortunately, neither of those seem to work. I have LARGE amount of memory dedicated to Retrospect in efforts to alleviate (256MB allocated) and the problem exists. Turning off filesharing is not an option on at least two systems (they are Appleshare IP servers).

 

 

 

Let me know if there are other workarounds - I will decrease the memory allocated from 256 -> 50 to see if that helps.

 

 

 

Thanks for the quick response and effort!

 

 

 

Patrick

Link to comment
Share on other sites

Increasing the memory allocation did not work for me either.

 

 

 

Turning off file sharing is not really an option here because people depend on it every day.. A couple of alternative workarounds that I have thought of include:-

 

 

 

* An applescript to turn off filesharing... can this be done? could it be triggered remotely? I would love to be able to run a single AppleScript on my machine each night that we go through all the clients and turn off file sharing. If people need it then they can turn it on themselves the next morning.

 

 

 

* Can I run Retrospect 4.3 and 5.0 in parallel on the same machine? ie I would setup a script in Retro4.3 to backup all the OS 9 clients (which cause the crash) and then a Retro5 script to backup the couple of OS X clients over lunch (or whenever...)? Would this work? Will I have to manually launch one or other of the applications? What problems might I encouter if I write to the same backup sets with both versions?

 

 

 

Any other suggestions would be most appreciated...

 

 

 

Adrian

 

 

 

PS Does anyone know Retrospect 5.0 crashes in the same way when run under OS X?

 

 

 

 

 

backup machine - G3/266, 384MB RAM, Sony SDT-S11000 (DDS-4), Adaptec 29160N, 15 clients (4 of which are OS X).

 

 

Link to comment
Share on other sites

I'm experiencing this problem as well. Retrospect has 150mb allocated to it in OS9 and the issue is still reproducable. One of my servers has a 300gig RAID5 array. That probably qualifies as "large." This morning I'm going to try mounting the server volume on the desktop of the backup server and then back it up that way. I don't think it will save the privs properly, but at least I'd have the data *and* the server would stay online.

 

 

 

For our workstations... well, I've been trying to get people to stop using personal file sharing for a number of other reasons. I guess now I can actually mandate it. '-)

Link to comment
Share on other sites

 

 

I'm in the same boat - people around here use file sharing to exchange files (rather than relying on a file server that has been provided for their use ;-) ) which, should be turned off as a security risk, but it will never happen .

 

 

 

So, is the Applescript option plausible? Can we write an applescript to deactivate filesharing on a client, backup the client, then reactivate filesharing?

 

 

 

Although, this still wont work with my AppleShare IP servers..

 

 

 

Thanks again for the continued work - backing up for the last week has been an 8hr/day job.

 

 

 

 

Link to comment
Share on other sites

OK, I did some more testing this morning and, at least for me, the elem.c-812 error only occurs when I try and backup clients using personal file sharing. Backing up my ASIP boxes (well, the one I could afford to test with) using the Retrospect 5 client worked fine three times in a row.

 

 

 

Given this, we were able to start backing up our servers again and just sent a note out to our staff saying if they wanted to be backed up they'd have to disable filesharing and use the central file server. I know this isn't a solution for everyone, but it is for us.

 

 

 

I'm still amazed that this wasn't caught during testing though, and I wonder what Dantz is prepared to do to mend the broken customer relations it has created.

 

 

 

 

Link to comment
Share on other sites

Yes, Last night was the first complete successful backup run on ALL our systems. Turning off file sharing on all OS 9.x machines solved our immediate problem. I too am dismayed that this was not discovered during beta testing. Please fix soon, some of our users require the ability to share files.

 

 

 

Peter Haase

 

Los Alamos National Laboratory

Link to comment
Share on other sites

Great....

 

 

 

Naturally, since none of the workarounds have worked for me - I assumed that it would be more widespread. I always tend to be the lucky recepient of the "un-fixable" problem.

 

 

 

Hopefully the patch will resolve my issue or I'm going to have to brainstorm a new backup procedure.

 

 

 

Appleshare clients on mine (running OS 8.x or 9.x) are crashing even with the new client that came with 5.0.

 

 

 

 

Link to comment
Share on other sites

>Naturally, since none of the workarounds have worked for

 

>me - I assumed that it would be more widespread. I always

 

>tend to be the lucky recepient of the "un-fixable" problem.

 

 

 

pdelin,

 

 

 

Does this mean that you get the crash even when scanning machines where File Sharing (as set in the File Sharing control panel) is set to OFF?

 

 

 

Dave

 

 

 

 

Link to comment
Share on other sites

Nope - Just on the machines that are running AppleShare IP (6.2 and 6.3). The post above mentioned how they had a successful backup on their AppleShare IP machine (that only FileSharing enabled personal machines seemed affected) - so I was worried that only my AppleShare IP clients were experiencing the dreaded elem.c 812 and 817 problem.

Link to comment
Share on other sites

Well - I am 100% sure (or at least 99%) that it is the File Sharing goof - I turned File Sharing off on offending systems, and am having good success therein. However, I'm wondering, since some of you don't have this problem when backing up AppleShare IP servers - do you have (in the Advanced Options area) the script set to recognize that those volumes are in fact Apple Share IP volumes and to log clients off in order to backup "in use" files? I have this set to happen, but wondered if that may be causing my AppleShare IP crashes.

 

 

 

What a bear - we turned off 30 client machines today from File Sharing - was not the most fun experience.

Link to comment
Share on other sites

I recently upgraded my Appleshare IP servers to OS X server. I believe that a previous poster said that he was able to succesfully backup a Appleshare IP server but I think it was on a minimal conigured machine. I can tell you that there is no problem backing up OS X server. I too agree that turning off File Sharing on clients is a pain but at least I dont need to worry as much. Its just a shame that it took so long to get to this point.

Link to comment
Share on other sites

I wish I can say the same thing. I tried three times to backup my AppleshareIP server this morning, and kept getting the same error. I have not tried the memory allocation to Retrospect yet, I will give that a go. I cannot turn off File Sharing because it is an AppleshareIP server.

 

 

 

Jeff

Link to comment
Share on other sites

>Well - I am 100% sure (or at least 99%) that it is the File Sharing goof - I turned File Sharing off on >offending systems, and am having good success therein. However, I'm wondering, since some of you >don't have this problem when backing up AppleShare IP servers - do you have (in the Advanced Options >area) the script set to recognize that those volumes are in fact Apple Share IP volumes and to log >clients off in order to backup "in use" files? I have this set to happen, but wondered if that may be >causing my AppleShare IP crashes.

 

 

 

No. I don't have that option set up, and I still can't back up my AppleshareIP server. So, it is not that.

 

 

 

Jeff

Link to comment
Share on other sites

Well here I am again. After backing up 2 of our "smaller" ASIP boxes successfully, Retropect crapped out on the RAID5 array on our primary server (it did manage to backup the boot drive though). I got the machine rebooted via VNC from home, and thankfully it didn't crash the file server this time, but my tape drive generated a hardware error. It always does that after Retrospect craps out. I generally have to turn it off, eject the tapes, and put them back in. Then everything is "fine" in a relative sense.

Link to comment
Share on other sites

Whew *whipes brow* I'm glad (although sorry for our collective state of backuplessness) that it's appearing on other AppleShare IP servers. Both of mine crash regularly (the OS X server runs fine though) and upgrading to OS X Server is not an option (at least not simply for a backup problem - two copies of OS X server unlimited would be thousands of dollars to fix a problem caused by backup software - not a viable solution). Anyway, it continues to have the worst problems with the AppleShare IP servers, but regularly crashes on other OS 9 and previous clients with file sharing on. At this point, it's behaving somewhat better (still can't get through a day's cycle without _at least_ 4 or so crashes), but having all the clients turn off FileSharing can't be a permanent solution - they will need it back.

 

 

 

I am giving serious thought to the "AppleScript" solution that we could deploy on systems, turning off and then back on their FileSharing before and after the backup.

 

 

 

Anyway, seems like an awful lot of work, so I'll wait through this week for at least an update from Dantz (Dantz, hint hint - any updates? any time frame on an update? any information to disseminate to the masses?) before devoting more work to this situation.

 

 

 

 

Link to comment
Share on other sites

i was getting this error all the time until i increased the memory to retrospect. that seemed to help a lot. haven't had it crash while backing up yet, and it's gone through about 20 machines that i know have personal file sharing enabled.

 

 

 

of course, only time will tell.

Link to comment
Share on other sites

Messing with the memory didn't work for me. I too am now not able to backup my server running Appleshare IP. Not a good situation since it is my most important computer on the network.

Link to comment
Share on other sites

ABSOLUTELY UNACCEPTABLE.... here I am mounting all my shared volumes on the local drive of my Backup Server, just because this error got missed during release. MAN!!!! If Dantz doesn't get a patch out and soon, I'm gonna loose my job over this.

Link to comment
Share on other sites

well...it's now 1am...and I think Dantz owes me about 4 hours of sleep. I want that patch and I want it now... this is absolutely ridiculous that I have to do the workarounds and spend countless hours trying to get everything backed up.

 

 

 

this release should not have happened, plain and simple. that patch better be here before lunch...grrrr

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...