Jump to content
Sign in to follow this  
Mayoff

Elem.c-812 workarounds

Recommended Posts

Guest

I spent a whole day updating my backup server and clients to Retrospect 5.0 only to find out that I can't backup my main file server due to the fact that it has to actually share files. So I just had to spend another half day switching back to Retrospect 4.3. So I spent 1-1/2 days and $200 just to end up right back where I started. I really don't want to be too derogatory here, but how could you not know about this bug before release? and when will the patch be ready?

Share this post


Link to post
Share on other sites
Guest

After several days of frustration I tried turning off personal file sharing on all of my OS 9 clients. I finally got a good backup. While this is quite a nuisance for the people in my company, all of whom rely heavily upon file sharing each day, it is a nuisance we are willing to put up with until Dantz supplies a patch.

 

 

 

While I share everybody's frustration with Dantz for releasing a product with such a major flaw, I don't see them as being any different from most other software manufacturers. In today's world of "I want the latest...AND NOW!" mentality most software companies don't see that they have any choice but to get the software out and hope they can patch the flaws before too many customers become irate. After all, how long were we sitting there going "When is Dantz going to support our OS X machines?" We got what we asked for. While it is far from perfect it is still better than anybody else is offering. Perhaps we are now reaping the rewards for being an impatient society.

Share this post


Link to post
Share on other sites

We were working fine with 4.3 as the backup server, OS X enabler and the OS X clients. The point being is that now there are a good majority of users where turning off file sharing is not an option. The enabler and the OS X client for 4.3 should have been extended so we can backup ALL our systems until such a time that Dantz fix's the problem and who knows how long that will be.

Share this post


Link to post
Share on other sites

They better not stretch it over the weekend, I've got way too much to do before the weekend hits. All our heavy backups are on the weekend.

 

 

 

I don't know how the project managers and developers at Dantz can sleep at night. I'd be all over this until it was fixed. Oh well, they must all be on vacation.

Share this post


Link to post
Share on other sites

beautiful!

 

 

 

i decided to go ahead and move up to OS X after trying Retr 5.0 in OS 9 and getting sooo many elem.c-812 errors.

 

So i upgrade our backup server to 10 and start from scratch logging our 50+ clients in, etc...

 

and now i have the same thing.

 

Kernel panic shmernel panic 'cause of an unsupported scsi card.....!

 

 

 

will elem.c-812 recur in os/x, or will i be safe by just replacing the scsi card?

 

 

 

we shall soon find out....

 

 

Share this post


Link to post
Share on other sites

--

 

After all, how long were we sitting there going "When is Dantz going to support our OS X machines?" We got what we asked for. While it is far from perfect it is still better than anybody else is offering. Perhaps we are now reaping the rewards for being an impatient society.

 

--

 

Better than anybody else? I can make as many backups using Retro 5 as I can with a plate of steamed yams.

 

 

 

It's our fault for hoping they'll ship a product promptly? Society at large is to blame for being impatient? Oh please.

 

 

 

Sure Dantz is under pressure to put out software promptly. Every developer is. However, I for one would have been fine waiting another week or 2 for a product that actually made backups. Retro 5 doesn't have a minor problem, it has a major, showstopping, crippling problem for many users, and the fact that it went out the door without this being caught amazes me, and makes me wonder what other surprises lurk underneath.

 

 

 

It wasn't the userbase who decided the OS X plugin would expire at the end of March. Dantz decided that the product would ship by a date on a calendar, not when it was tested, reliable, and ready.

 

 

 

If "we" are to blame for anything, it's the willingness to be beta testers for everyone with a "ship first, debug later" philosophy. It's not like Dantz even has a competetor to beat to market in this arena-unfortunately for us consumers.

 

 

Share this post


Link to post
Share on other sites

Any word on a patch yet? Or a timeframe/timeline for when it might be completed. I need to give my users an idea of how long to go without filesharing. thanks

Share this post


Link to post
Share on other sites

If you have to leave personal file sharing on then one workaround which seems to be working OK for me is to keep using Retrospect 4.3 with the problematic OS9 clients and only use Retrospect 5.0 for OS X clients (which don't give the error). For example, before I leave in the evening I launch Retrospect 4.3 and it runs an overnight backup script for all my OS 9 clients. When I come into the lab in the morning I quit 4.3 and launch 5.0 and run a script which does the OS X clients. It even looks like you can even write to the same backup set from both versions - however, it is probably safer to use separate sets while we wait for the fix for this problem.

 

 

 

Obviously this is not going to work for everybody and is a bit of a pain but it is better than no backups at all...(and a lot more productive than reading all the whinging going on here).

 

 

 

Adrian

Share this post


Link to post
Share on other sites

As soon as I upgraded the clients to 5.0 I consistently got these errors. Reinstalled the 4.3 clients and everything works great, WITH filesharing turned ON.

 

 

 

One iMac on a LAN running 9.2 and another iMac on AirPort running 9.2. Server also runs on 9.2.

 

 

 

...Tom

Share this post


Link to post
Share on other sites

I had suffered from he same problem in backing up my ASIP 6.32 server with hardware RAID 5. Here is what I did:

 

 

 

1) Increased RAM to 400MB for Retrospect. This helped at first, but the elem.c-812 problem reoccurred. Since I was planning on upgrading the machine Retrospect Server runs on to Mac OS X Server (this is one of my secondary servers and does not have RAID). At first, after upgrading the Retrospect Mac to OS X all went well in the tests I did that day. 2 days later a new problem surfaced.

 

 

 

2) Now when I backup my ASIP server, the ASIP server freezes. Every time. I will try backing up by mounting the ASIP volumes instead of using the Retrospect client when I can do so safely (right now I would interrupt too many people trying to get their work done). I am considering upgrading the RAID ASIP server to Mac OS X later this month, a few months ahead of schedule. The good news is that Retrospect Server itself does not quit or freeze under Mac OS X.

 

 

 

3) However, something else caught my attention. 2 nights ago my 4D Server rebooted itself during backup, and there was a file showing that it was disconnected from a Mac OS X server before rebooting (I forgot to dismount it from the server after copying some software to it). Last night the backup of this 4D Server also failed. The 4D server did not reboot itself but it lost all TCP/IP connectivity (it could not see anything over TCP/IP and nothing could see it, using a variety of software). Restarting the 4D Server fixed the problem.

 

 

 

My ASIP and 4D servers have one element in common: both run under Mac OS 9.04. I just upgraded the 4D Server to Mac OS 9.1 and I will see if it has any problem after the next backup. It is possible that my ASIP server should be upgraded to Mac OS 9.1 and ASIP 6.33. I have been reluctant to do so because my RAID is formatted with Remus Lite 1.4 and I am concerned that there might be a conflict between Mac OS 9.1 and Remus Lite. But upgrading to Mac OS 9.1 would be much simpler than jumping this machine to Mac OS X Server at this time.

 

 

 

--Paul Chernoff

Share this post


Link to post
Share on other sites

Interesting thought. I also am running AppleshareIP under 9.0.4 and it will freeze each time Retrospect 5 tries to back it up. Lets see what the patch, which supposedly will be released today, does. If it still fails with the patch, I will try updating that machine.

 

 

 

Jeff

Share this post


Link to post
Share on other sites

I think my thesis about my 4D Server was wrong. I checked my switch configuration and I had accidentally set the port for the 4D Server to full duplex. Due to a problem with the Macs this resulted in extremely slow connectivity. In addition, the energy saver somehow got turned on, so the 4D Server had gone to sleep. I don't think I can blame anything with it on Retrospect. But we still share the same problem on backing up an ASIP Mac.

 

 

Share this post


Link to post
Share on other sites

no big deal about the wait, yes it slipped through the barracades of beta testing, but its not the end of the world. id just like to hear a little bit from dantz though please for reassurance ("yes we are close to a patch", "no, please tell your users it will be another month"). please?

 

 

 

i just want a little info - throw a dog a bone.

Share this post


Link to post
Share on other sites

I sure hope they are working through the weekend to get this resolved. During the week Eric and Irene said we would hear something by Friday. Well, Friday passed without a word from Dantz.

 

 

 

Jeff

Share this post


Link to post
Share on other sites

Not at all amused by Dantz right now. Not only is their product proving to be, quite literally, worse than beta, but my post got deleted. I was very careful not to break any of their forum rules, I didn't carelessly bash Dantz, I just listed the problems I was having and explained the resulting difficulties which have arisen due to thes problems.

 

 

 

Oh, and I asked for an apology. Maybe that was it. Forbid I expect an apology from Dantz for this past week.

 

 

 

$349 and two full nights of manually restoring and piecing together data from old tapes because 5.0 doesn't work (elem.c-812 consistently, on both OS X machines and OS 9 boxes, ASIP and OS X server 10.1.3)....but maybe that isn't worth an apology?!

 

 

 

Anyway, I hope we do see a patch soon, as in, very, very soon. This is the worst final version of anything I have ever used, including Quark 4.0.

Share this post


Link to post
Share on other sites

Fortunately I am backing up all of our servers and clients without any problems now for a couple of days. I did a couple of things. Replaced my Adaptec 2906 with a ATTO UL3S SCSI card just because I don't trust Adpatec. Other details Of our backup server are:

 

 

 

Power Mac G4

 

512 MB RAM

 

Mac OS 9.1

 

Retrospect 5.0 Server

 

Backing up ~ 80 systems every day - Win NT, 2000 Servers, Mac OS 9x clients, OS X Servers and clients.

 

 

 

*Personal File sharing disabled on ALL 9.x clients.*

 

 

 

I will not upgrade the backup machine to OS X. I feel there are some nasty lurking problems yet to be discovered. Luckily I upgraded our only ASIP 6.3 server to OS X server a few weeks ago or else I would be spending more time at the office and praying that no machine would experience a fatal disk crash. Pretty rare these days but it does happen. Even though I have no complaints at the moment I am still upset and the way users are being kept in the dark. Its pretty rediculous and pathetic. Hopefully there will be a solution coming soon for those of you that are still experiencing problems.

 

 

Share this post


Link to post
Share on other sites

I called up on Friday and was told it would be finished within a week. However, that being said, I would take that with a HUGE grain of salt. I have a feeling the guy on the other end of the line was feeding me whatever story of the day was on tap for this patch. Didn't seem to have any concrete evidence that it was almost fixed. I was told I would be called and e-mailed as soon as it was ready.

 

 

 

In the meantime, I've got 40 - 50 clients that are NOT BACKING UP DAMNIT!

 

 

 

Sorry, but I'm getting a little ticked off here.

Share this post


Link to post
Share on other sites

I can tell you that the elem-c.812 error is a Mac OS9 problem ONLY.

 

 

 

My backup server is running OSX and, while slow, does not get this error at all. I'm backing us mostly OS9, some OSX, some Win2K. Almost all the OS9 systems have file sharing turned on.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×