Jump to content
Sign in to follow this  
davidduff

"assertion check at 'elem.c-817' " - whats the status of this problem?

Recommended Posts

i just got a message saying "assertion check at 'elem.c-817' ". i think this was the first time i've seen it.

 

i was backing up an os x client on on os x server.

 

searched and saw discussion of this topic, much of it old, much of it seemed to center on issues relating to backing up os9 clients...

 

are there known causes of this? workarounds?

 

after hitting the assertion check problem, i tried repeating the same backup and the next time, i got the error "trouble matching <volume> on <client> to <backupset>, error -24201 (chunk checksum didn't match)."

 

so i am trying to re-build the catalog of my backup set, in hopes that that will fix the problem.

 

since rebuilding takes a lot of time, i'm sitting here pondering what might have caused this problem.... i've backed up the same client before with no problems... haven't changed my backup server config at all since the last time, when it ran ok.

 

however, there's a lot of stuff running on the server machine right now. lots of apps, plus the classic environment (which i don't use much, but something in turbotax 2002 decided it needed classic to read some help files or something...). so perhaps this somehow relates to situations where you're using lots of vm? perhaps running out even? .... just a thought.

 

 

Share this post


Link to post
Share on other sites

I'll agree with that.

 

This problem just started showing up when backing up a particular OSX client. It crashes my backup server every time with "Assertion check at "elem.c-817".

 

Can we get a fix soon? Please.

 

Paul

Share this post


Link to post
Share on other sites

same thing here. os x server with os x client.

every time this happens i pretty much give up on the backup set i'm using for the week.

 

very frustrating as we use this in out prod environment.

 

i'm using the latest version client/server.

 

any news about this recurring issue?!?!

 

 

Share this post


Link to post
Share on other sites

Yeah, What the heck is the deal here. Have not seen this one for awhile but after complaining yesterday about a different consistency check problem I started getting this one again except this one is more of a pain.

Share this post


Link to post
Share on other sites

The elem.c-817 issue is caused by a corrupt catalog file. Why is the catalog file getting corrupt? We don't know at this time. We are investigating the issue.

 

I would recommend creating a new backup set and see if the problem goes away. If it comes back again, it could be the result of a device communication problem damaging the catalog file.

Share this post


Link to post
Share on other sites

i had been erasing each tape before reusing it, but i guess i should erase each backup set each week before using it as well (to start with a fresh catalog).

 

a slightly inefficient use of my time, but doable, for me, something like:

1) creating a new backup set, say, "Week 5a" if I'm going to replace "Week 5" and erase each "Week 5" tape, renaming them "Week 5a"

2) add "Week 5a" to the list of sets my script will back up to.

3) go through the schedule and replace each instance of "Week 5" with "Week 5a"

4) Delete "Week 5"

 

So I imagine doing this each week will minimize the chances that it will happen...

hopefully some other type of error checking/detecting will be worked in so this stops.

Share this post


Link to post
Share on other sites

If you do a recycle backup it will erase the catalog, and it isn't necessary to erase the tapes once you have recycled the backup set.

 

Share this post


Link to post
Share on other sites

i had been doing only that but i was hesitant, especially with so many screwups, because say, i did a recycle backup on a friday/weekend which would take two tapes, then "normal" incremental backups on the following week's days when it would span onto a third tape. my thinking was that i'd like to start AS FRESH as possible because when i get a messup any day of the week it destroys that whole week's backups.

so then sometimes i'd finish backing up for that week on the previous week's set, which would work.

 

it IS saving the data that's important, after all, so i wouldn't be surprised of many users are more careful than necessary when using their backup system. the price to pay for losing it can be high (as in your job).

 

please don't post to me about why i shouldn't be extra careful with seemingly touchy software that i depend on.

please post if you have something to say that will help us with our unresolved issues.

 

jon

Share this post


Link to post
Share on other sites

what i meant in my previous post was "i have been erasing each tape even when a recycle backup will be done on it"

Share this post


Link to post
Share on other sites

Quote:

please post if you have something to say that will help us with our unresolved issues.

 


 

OK, I'll take a stab at this, by saying that you haven't provided very much specific information for anyone to work with.

 

>>i'm using the latest version client/server.

 

- What versions are those?

 

- What version of Mac OS is in use in each of the machines?

 

- Is it always the same Client that causes the assert?

 

- Does it happen every time on that particular Client?

 

- What specific hardware (tape drive, scsi host adapter, etc) are you backing up to?

 

>i guess i should erase each backup set each week before using it as

>well (to start with a fresh catalog).

{snip}

>so then sometimes i'd finish backing up for that week on the previous week's set, which would work.

 

You'll probably have better data security if you bring in another set of tapes so you don't recycle last week's to use this week. That way, if something _does_ go wrong this week (such as the tape drive shredding a tape), you still have last week's on the shelf.

 

Dave

Share this post


Link to post
Share on other sites

Dantz is investigating a problem that can result in damaged catalog files/backup sets under very specific conditions. We are hoping to nail this issue before our next product release.

Share this post


Link to post
Share on other sites

Quote:

Quote:

please post if you have something to say that will help us with our unresolved issues.

 


 

OK, I'll take a stab at this, by saying that you haven't provided very much specific information for anyone to work with.

 

hmm... let's see. "elem.c-817" - a few people who have posted are having that issue (and that means for each one posting here there are possibly 10, 20, 100 whose backups depend on the resolution of this?), and add a few who are probably (like i was) waiting for the next update to see if it solves this- or to see if anyone for sure finds a solution. seriously, though, this type of problem takes a lot of time. lots of client machines, lots of data, lots of variables. lots of patience.

 

>>i'm using the latest version client/server.

 

- What versions are those?

 

5.0.238 for the server.

5.0.528 and 5.0.536 clients (has stopped at each of these)

 

in the next few days i'll roll out the newer client version i just found out about (5.0.540), though of course it'll take a while to see if it's been resolved by that- now that i mention that i have a hunch someone may forget about this problem until i shout back about it.

 

i'll also go through the retro log and detail what client/os/retro client version, etc it happened on. that'll take more time, though and i need to take care of some other things so i'll post it within the next few days.

 

 

- What version of Mac OS is in use in each of the machines?

 

 

10.1.5 on the server, and 10.1.5 and 10.2.5 on the clients (one has 10.2.6) (has stopped at each of these)

 

clients include windows xp w/sp 1, and windows 2000 pro w/ SP 2,

and a few openbsd machines throwing data via ssh'd dump onto a non-primary volume (not the one retrospect and the catalogs are kept on) during hours retrospect is not running at, so restrospect can then throw those archives onto tape (elem.c-817 was around before this setup- try to trust me, it's harmless.)

 

- Is it always the same Client that causes the assert?

 

no, as stated above, happens on different ones.

i'll go through the logs and

 

- Does it happen every time on that particular Client?

 

no

 

- What specific hardware (tape drive, scsi host adapter, etc) are you backing up to?

 

the card: Express PCI PSC

in Apple System Profiler:

card name: Apple53C875Card

model: NCR,875

Rev 4

Vendor ID: 1000

 

the backup media: hp surestore dlt 1 tape drives

 

>i guess i should erase each backup set each week before using it as

>well (to start with a fresh catalog).

{snip}

>so then sometimes i'd finish backing up for that week on the previous week's set, which would work.

 

You'll probably have better data security if you bring in another set of tapes so you don't recycle last week's to use this week. That way, if something _does_ go wrong this week (such as the tape drive shredding a tape), you still have last week's on the shelf.

 

NOPE. you got it wrong, i don;t know how you misunderstood me, but you did. i use 5 weeks for the recycle period. in the case that, say, week 1a gives me an error like it did today (sigh, and i was backing up to a brand new backup set!), i'll probably add to last week's set (week 2) just to have a backup somewhere of things changed this week. week 1a is pretty much history.

 

thanks for the posting soliciting more info. fact is, dantz knows this as an issue. i have my own clients to deal with and test things i am responsible to them for. hopefully dantz can help me as one of their clients.

-Jon

 

dmesg follows in case it's helpful for more hw info:

 

=======

standard timeslicing quantum is 10000 us

vm_page_bootstrap: 92972 free pages

mig_table_max_displ = 64

\^[[31mC\^[[32mO\^[[33mL\^[[34mO\^[[35mR\^[[0m video console at 0x84000000 (832x624x8)

IOKit Component Version 5.5:

Thu May 30 14:39:38 PDT 2002; root(rcbuilder):RELEASE_PPC/iokit/RELEASE

_cppInit done

IODeviceTreeSupport done

Recording startup extensions.

Copyright © 1982, 1986, 1989, 1991, 1993

The Regents of the University of California. All rights reserved.

 

using 983 buffer headers and 491 cluster IO buffer headers

PCI-Lynx revID:2

CMD646Root starting probe

CMD646Root: starting

CMD646Root publish below

CMD646Root found kids

CMD646Root: started

AppleLynx: powering on FireWire

Local FireWire GUID = 0x50e4ff:0xfe561950

FireWire bus reset!!

USBF: 20.839 [0x16c7c00] USB Generic Hub @ 1 (0x6)

devfs enabled

dlil_init

IOKitBSDInit

From path: "/pci/@d/pci-ata@1/ata-4@0/disk@0:6,\\mach_kernel", Waiting on <dict ID="0"><key>IOPathMatch</key><string ID="1">IODeviceTree:/pci/@d/pci-ata@1/ata-4@0/@0:6</string></dict>

dlil_input_thread 1620dc0

ADB present:0

USBF: 21.331 [0x16c7800] USB Generic Hub @ 2 (0x1100000)

Got boot device = IOService:/GossamerPE/pci@80000000/AppleGracklePCI/pci-bridge@D/IOPCI2PCIBridge/pci-ata@1/CMD646Root/ata-4@0/CMD646ATA/ATADeviceNub@0/IOATABlockStorageDriver/IOATABlockStorageDevice/IOBlockStorageDriver/Maxtor 91303D6 Media/IOApplePartitionScheme/untitled@6

BSD root: disk0s6, major 14, minor 6

devfs on /dev

USBF: 22.637 AppleUSBKeyboard[0x16f9400]::start USB Generic Keyboard @ 3 (0x1110000)

Jettisoning kernel linker.

Resetting IOCatalogue.

Number of Descriptors: 256. Total Size: 4096

Size of IODBDMADescriptor: 16.

Ethernet(BMac): Link up at 100 Mbps - Full Duplex

IOKernelDebugger: Debugger attached

USBF: 39.433 AppleUSBMouse[0x1751800]::start - USB Generic Mouse @ 4 (0x1120000)

86008000: VRAM found 86000000:01000000

.Display_Rage128-0102802f: user ranges num:1 start:86008000 size:111080

.Display_Rage128-0102802f: using (832x624@75Hz,16 bpp)

BMacEnet: Ethernet address 00:50:e4:56:19:50

ether_ifattach called for en

Root power domain receiving initial preferences

 

 

 

Share this post


Link to post
Share on other sites

I fixed the offending computer by starting it in single user mode (OSX) and running fsck. smirk.gif

 

Still, that's no good reason for Retrospect to crash on the server end. mad.gif

Share this post


Link to post
Share on other sites

Quote:

I fixed the offending computer by starting it in single user mode (OSX) and running fsck.

 


 

Which machine is "the offending" one?

 

Is it the computer running the Retrospect application?

 

The machine running OS X 10.1.5, with a SCSI host adapter you identify as:

Apple53C875Card ?

 

Since Apple doesn't make SCSI cards, what's it say on the card itself?

 

And knowing the model of Macintosh you're using would help round out the record, too.

 

Dave

Share this post


Link to post
Share on other sites

Quote:

Quote:

I fixed the offending computer by starting it in single user mode (OSX) and running fsck.

 


 

Which machine is "the offending" one?

 

Is it the computer running the Retrospect application?

 

The machine running OS X 10.1.5, with a SCSI host adapter you identify as:

Apple53C875Card ?

 

Since Apple doesn't make SCSI cards, what's it say on the card itself?

 

And knowing the model of Macintosh you're using would help round out the record, too.

 

Dave

 


 

check out http://www.versionchecker.com/dyn/moreinfo/mac/8873 about the scsi card. i was the one that has that card. i think apple did make scsi cards.

 

i have elem.c-817 errors every once in awhile. also, when i tried to backup to the same script i had gotten an "-817" error, it then gave me an "elem.c-822" error. i consider a catalog shot after any elem.c error, i just tried to re-back up to it in order to see what happened.

 

i'm not going to take the card out now to tell you what it says on it. tight schedule, and besides, the number above should be sufficient for any dantz guru.

 

about fsck fixing the offending machine. how many times have you backed it up since? my experience has been that different clients will cause the elem.c errors. was your problem always with the same client? and then running fsck on it fixed the retrospect issue? make sense. i wish my issues were that simple and that this sheds some light on the problem.

 

 

 

 

Share this post


Link to post
Share on other sites

p.s. Dave, maybe you should read people's posts more carefully (as to who says what and what it is they are saying)

 

 

 

it is nice to have dantz' aknowledgement of the problem and the reassurance that they're working on it.

Share this post


Link to post
Share on other sites

Quote:

p.s. Dave, maybe you should read people's posts more carefully (as to who says what and what it is they are saying)

 


 

Gosh, you're right.

 

"pnord" posted with absolutely no details and asked for a fix, while "jquiros" posted details only after being prompted to do so, after cautioning others not to post unless the information met some specific level of helpfulness.

 

I'm _sure_ that it's my fault for not gleaning the relevant data on the first several reads, since it was so carefully arranged.

 

Apple has never manufactured PCI based SCSI host adapts. They have provided such cards, manufactured by others to Apple's specifications, in some machines. But if you're using a card that is not supported in Retrospect (as AmyC suggests), it's not surprising that you're having issues.

Share this post


Link to post
Share on other sites

now using an Adaptec Power Domain 29160. finally got the ok to buy it. i expected the typical (and most times necessary) "oh no we won't help you unless" bs and i got it, so now we'll see if the problem goes away.

 

in any event, like i said before, it's encouraging that dantz has stated the problem exists and that it's being worked on.... i'm looking forward to feeling like the hw part of our strategy is solid.

 

yes, i'm on the mailing list, too :-) so i'll be patient.

 

 

 

p.s. callmedave thanks for the noise. maybe next time you'll be able to make helpful noise, hm?

Share this post


Link to post
Share on other sites

 

Ok, a coupel weeks have passed. Using all SUPPORTED hardware, software, performing best practives, etc.

guess what?

 

This past weekend's backup gave me a surprising "Trouble in Retrospect. elem.c-817" error.

At least we spent the money on the card to make sure that wasn't the problem, right?

 

...waiting for a solution from DANTZ on this. It's been a fre YEARS of using Retrospect for X! this is outrageous. If it weren't for needing to have other people be able to retrieve stuff in the event I'm not here, I'd be using my own open-source based, resourceFork-taking into account solution!

 

shame on you, dantz.

 

I like your products but don't see the reliability needed for operation in a production environment. please fix this ONE issue with your otherwise great product!

 

Share this post


Link to post
Share on other sites

fyi,

 

It has now been awhile since my last post. no responses to this issue, and the problems persist now and again.

 

 

 

Share this post


Link to post
Share on other sites

Dantz engineering has been working hard to identify and resolve these error messages.

 

Our research has shown several possible causes and solutions for these errors:

 

1) Hard Disk B-Tree issues: Several users have reported that they have identified hard disk corruption which has resulted in the elem.c assert errors during backup. If your error appears to happen when accessing specific users on the network or specific hard drives, it is recommended that you check these disks with a hard drive diagnostic tool such as Apple's Disk Utility or Norton Utilities. Repairing a problem disk drive may reduce or eliminate your elem.c errors.

 

2) Bad RAM or other memory problems on the backup computer has also been a problem for several Retrospect customers. Replacing the RAM in the backup computer or moving Retrospect to another Macintosh has been an effective way to eliminate these errors for some users.

 

Dantz is aware that other causes for these error may exist and we will continue our investigation and let you know of any new developments related to this issue.

 

 

Share this post


Link to post
Share on other sites

Running fsck on the troubled client computer (and OSX system) allowed me to backup without the 817 error. mango.gif

 

I'm now seeing the 817 pop up when trying to restore files to a Windows 2000 computer. confused.gif

Share this post


Link to post
Share on other sites

A few weeks ago one of our HP DLT 1 tape drives failed. It was under warranty and HP sent a new one.

Since then, I've seen no errors, and I'm crossing my fingers that that's what the problem was: A faulty tape drive that degraded until it was *totally* unfunctional.

 

Jon

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  

×