Jump to content

"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.

 

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

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?!?!

 

 

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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

Link to comment
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

 

 

 

Link to comment
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

Link to comment
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.

 

 

 

 

Link to comment
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.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

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?

Link to comment
Share on other sites

  • 2 weeks later...

 

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!

 

Link to comment
Share on other sites

  • 5 weeks later...

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.

 

 

Link to comment
Share on other sites

  • 1 month later...

Archived

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

×
×
  • Create New...