davidduff Posted April 9, 2003 Report Share Posted April 9, 2003 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 More sharing options...
pnord Posted April 17, 2003 Report Share Posted April 17, 2003 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 Link to comment Share on other sites More sharing options...
jquiros Posted April 29, 2003 Report Share Posted April 29, 2003 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 More sharing options...
Peter_Haase Posted May 1, 2003 Report Share Posted May 1, 2003 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. Link to comment Share on other sites More sharing options...
Mayoff Posted May 1, 2003 Report Share Posted May 1, 2003 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 More sharing options...
jquiros Posted May 5, 2003 Report Share Posted May 5, 2003 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 More sharing options...
mcswgn Posted May 6, 2003 Report Share Posted May 6, 2003 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. Link to comment Share on other sites More sharing options...
jquiros Posted May 6, 2003 Report Share Posted May 6, 2003 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 More sharing options...
jquiros Posted May 6, 2003 Report Share Posted May 6, 2003 what i meant in my previous post was "i have been erasing each tape even when a recycle backup will be done on it" Link to comment Share on other sites More sharing options...
CallMeDave Posted May 6, 2003 Report Share Posted May 6, 2003 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 More sharing options...
Mayoff Posted May 8, 2003 Report Share Posted May 8, 2003 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. Link to comment Share on other sites More sharing options...
jquiros Posted May 8, 2003 Report Share Posted May 8, 2003 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 More sharing options...
pnord Posted May 12, 2003 Report Share Posted May 12, 2003 I fixed the offending computer by starting it in single user mode (OSX) and running fsck. Still, that's no good reason for Retrospect to crash on the server end. Link to comment Share on other sites More sharing options...
CallMeDave Posted May 12, 2003 Report Share Posted May 12, 2003 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 More sharing options...
jquiros Posted May 13, 2003 Report Share Posted May 13, 2003 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 More sharing options...
jquiros Posted May 13, 2003 Report Share Posted May 13, 2003 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. Link to comment Share on other sites More sharing options...
AmyJ Posted May 13, 2003 Report Share Posted May 13, 2003 There are no Apple re-branded SCSI cards on the Dantz Mac OS X SCSI Host Adapter Compatibility List http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27381 Link to comment Share on other sites More sharing options...
CallMeDave Posted May 14, 2003 Report Share Posted May 14, 2003 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 More sharing options...
AmyJ Posted May 29, 2003 Report Share Posted May 29, 2003 To be notified when there are updates on the elem.c-817 error, please subscribe to the following mailing list: http://list.dantz.com/mailman/listinfo/assert_elem817 Link to comment Share on other sites More sharing options...
jquiros Posted June 11, 2003 Report Share Posted June 11, 2003 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 More sharing options...
jquiros Posted June 23, 2003 Report Share Posted June 23, 2003 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 More sharing options...
jquiros Posted July 22, 2003 Report Share Posted July 22, 2003 fyi, It has now been awhile since my last post. no responses to this issue, and the problems persist now and again. Link to comment Share on other sites More sharing options...
Mayoff Posted July 22, 2003 Report Share Posted July 22, 2003 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 More sharing options...
pnord Posted July 28, 2003 Report Share Posted July 28, 2003 Running fsck on the troubled client computer (and OSX system) allowed me to backup without the 817 error. I'm now seeing the 817 pop up when trying to restore files to a Windows 2000 computer. Link to comment Share on other sites More sharing options...
jquiros Posted September 16, 2003 Report Share Posted September 16, 2003 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.