Error Code: elem.c-923 Internal Consistency Check failed

[pentagonaf]

G5 running OS X Server 10.4.7 with Retro 6.1.125 and the clients are 6.1.130 with Drive Util 6.1.6.100

I started receiving the "Trouble in Retrospect" Internal consistency check failed: Assertion check at "elem.c-923"

 

I have rebuilt the set from scratch and when running I received the same error again. I don't know what is happening and could use some assistance.

Thanks

Bob

[fritzgreen]

Hi Bob,

 

I am experiencing the exact same error with no solutions yet.

 

There is a Knowledge Base article about this general type of error, but it does not nail down this one specifically…

http://kb.dantz.com/display/2n/articleDirect/index.asp?aid=6307&r=0.319607

 

In my case, I am backing up on a Dual G5 running 10.4.7 to an external firewire Maxtor HD. I am backing up volumes shared by a G5 XServe. (I had to abandon a SCSI tape drive because Retrospect stopped working with it when we updated to Tiger.) The new configuration was working fine until about a week ago when the error started, with no memorable changes to my system.

 

Two out of three of the XServe volumes will back up fine, but the third one always produces this error at the point where the matching is completed and Retrospect is ready to write to the backup set. I tested the catalog by performing a restore search as outlined in the article referenced above and did not encounter an error.

 

I have not tried running a disk utility on the volume in question yet, primarily because I'm afraid to do so WITHOUT a good backup of it, but I'm wondering if there is a problem with the volume I'm trying to back up.

 

Have you encountered any solutions yet?

 

Thanks! Fritz

[fritzgreen]

It might be safe to say that the elem.c-923 assertion check error is related to problems with the volume structure on the disk being backed up.

 

I successfully ran Disk Utility and TechToolPro 4 on the disk containing the volume that I was getting the error on. Volume structure problems were found and fixed. After that the backup of the volume worked without error.

 

It is ironic that we are told to make a backup of a disk before running a disk utility, but I needed to run a disk utility before I could make a backup!

 

Fritz

[fritzgreen]

I spoke too soon. After only one successful backup of the volume in question the assertion check error has returned!

 

I'm feeling frustrated this morning because I don't know what else to do. Why can't Retropspect just copy the files when I can manually copy them without issue?!!

 

Fritz

[J.Rosado]

Fritz,

 

I am also having the SAME problem when backing up to my 400GB Seagate Drive. I have trashed my Config.info preferences and rebooted, but no difference.

 

Any solutions?

 

--Miffed

[CallMeDave]

Quote:

---

Fritz,

 

I am also having the SAME problem when backing up to my 400GB Seagate Drive. I have trashed my Config.info preferences and rebooted, but no difference.

 

---

 

Fritz,

 

After your success using Disk Utility to repair the drive, did you run Disk Utility again to Validate the drive and see if the structural problems were back?

 

Miffed,

 

When you say "SAME problem," are intimating that every aspect of Fritz' limited reporting is the same as your experience? You also abandoned a SCSI tape drive? Yours was also working for a while without a problem? You also have a "G5" model Macintosh? You have two volumes that work fine every time, and a third that produces the error "at the point where the matching is completed and Retrospect is ready to write to the backup set?" You checked the offending volume with Disk Utility and repaired errors?

 

"Me too" posts do little to help find a cause or a cure. Posting your complete system information, and compete steps that you can use to reproduce the problem, are the first requirement of getting help from other users online.

 

Dave

[J.Rosado]

Fritz & Dave,

 

This is my computer's CONFIGURATION:

 

Machine Name: PowerBook G4 15"

Machine Model: PowerBook3,5

CPU Type: PowerPC G4 (3.3)

Number Of CPUs: 1

CPU Speed: 1 GHz

L2 Cache (per CPU): 256 KB

L3 Cache (per CPU): 1 MB

Memory: 1 GB

Bus Speed: 133 MHz

Boot ROM Version: 4.5.3f2

 

RETROSPECT Configuration:

 

Version: 6.1.126

Device Access Version: 1.0.107

Driver Update Version: 6.1.7.101

 

++++++++++++++++++++++++++++++++++++++

 

I have been faithfully using RETROSPECT for the past 9 years and have had great results with it over the years. That is until the most recent INTERNAL CONSISTENCY error messages.

 

I back up my entire FILE to a 400GB Seagate harddrive.

 

Its driver crashed on my so I ERASED the entire volume using Apple's DISK UTILITY software. After reconfiguring the drive, I checked to make sure it was recognized. I also, loaded the latest version of OS X 10.4.7 and made it a bootable harddrive as well.

 

I then created a new "easyscript" from Retrospect. This created the "Assertion check at "elem.c-923"." Internal Consistency error message.

 

I have deleted the RETRO.CONFIG (6.0) file from my Preferences and deleted the "com.dantz.Retrospect.plist" from my USERS/Library folder.

 

I rebooted. Retyped my SERIAL NO. in Retrospect. I deleted my previous backup set + .cat files from my 400GB Seagate Drive. I created a new "easyscript" in Retrospect.

 

the SAME problem persists and it does not allow me to complete the NORMAL Backup.

 

I am totally MIFFED.

 

What else should I do?

 

Josh Rosado [Miffed]

[rhwalker]

Quote:

---

I back up my entire FILE to a 400GB Seagate harddrive.

 

Its driver crashed on my so I ERASED the entire volume using Apple's DISK UTILITY software. After reconfiguring the drive, I checked to make sure it was recognized. I also, loaded the latest version of OS X 10.4.7 and made it a bootable harddrive as well.

 

 

---

How is this Seagate hard drive connected to your computer? It's a bit unclear from your post whether the Seagate is an external drive, or whether it's your internal boot drive and you are trying to do a "file" backup to your boot drive.

 

Have you tried defining a subvolume and backing that up just to see if a minimal backup works for a small set of files?

 

You indicate that you have been running Retrospect for 9 years. Were you running it previously on this computer? You might have hardware issues.

 

Just a few suggestions.

[CallMeDave]

It's probably not related, but Retrospect stopped using Device Access files with the release of 5.0.x.

 

Device access is now handled entirely via the License Manager.

 

 

Dave

[ibeatty]

Greetings.

 

Alas, I also have suddenly started seeing the dreaded elem.c-923 error. I've been running Retrospect without problems for months and months, and I didn't make any changes near the time that this started. All of a sudden, I started finding that when I check my backup server in the morning, Retrospect will have died with a last gasp of "elem.c-923!"

 

The log doesn't show anything useful. It has the last successfully completed backup, then a blank line, then the "Internal consistency check failed" entry with no timestamp. So I can't tell if it's associated with the start of backing up another client, or something that happens while scanning, or what.

 

Details:

 

I'm running Retrospect 6.1.126 on Mac OS X 10.4.3 on a 400 MHz G3 iMac ("smoke" translucent body) with 384 MB RAM. It's acting as a dedicated network backup server, backing up via firewire to a Granite Digital hot-swappable drive enclosure into which I place IDE drives. Retrospect has 20 network clients registered, though four of them aren't turned on very often. Most of the clients are desktops backed up by a script that runs overnight but not during the day; a few are laptops backed up by a script that runs 24/7; and one is a server backed up during a specific interval in the early morning, after the desktop script is done.

 

I alternate between two backup sets, each one on a different 250 GB IDE drive that gets inserted into the drive enclosure. I've had the elem.c-923 with both backup sets.

 

Suggestions? Wisdom? Thanks!!

 

:ian

[ArsonAndy]

I had the same error (elem.c-923) when backing up a Windows XP Pro ThinkPad to my Mac OS 10.4.7 PowerBook G4 running Retrospect 6.1.126 RDU 6.1.7.101. It was working fine until just a day or two ago. Then all of a sudden, the errors.

 

After looking here, and trying several solutions (restart Retro client, restart ThinkPad, restart PowerBook, new backup set), I found something that worked. I deleted the client from the client list within Retrospect, then added it back. Just finished a backup without error. Hopefully it stays fixed...

 

-Andy

[danmoriarty]

I just started having this problem too, and I'm looking for answers. I run Retrospect 6.1 on Mac OS 10.4, on an XServe. I am 22 tapes in to a large photography backup set that grows daily, so it would be extremely time-consuming and a last resort to go back and re-do this backup. Each tape hold 80 GBs...

 

What can I try? The only change I've had lately is that I had a number of tapes being stopped in mid-backup because Retrospect was saying "dirty heads" and so I took the advise of a different post here to "forget" these half-done backup sets in Retrospect and try again. That worked, I was able to forget tapes 19 and 20 of the set, and start fresh with new tapes. But maybe that had something to do with bringing this error up?

 

I ran disk utilities, fixed permissions. Not sure what else to do.

[MacWright]

here's my me too post:

 

MacOS X 10.4.6/ Dual 2 GHz PPC G5/ 4.5 Ram

Retrospect 6.1.123

Driver Update 6.1.4.103

2- Sony SDX-500C Ait drives

notes:have used this yet up for a long time without many problems, haven't installed any new OS updates recently, and no changes to the hardware configuration, scsi or firewire chains.

 

I did put a new tape in yesterday but the back ran fine, today I arrived to error:

"Trouble in Retrospect: Internal consistency check failed: Assertion check at "elem.c-923"

 

what or where is "elem.c-923"? and the real curiosity is why does this appear to be a new error that has just occurred in the last couple months?

 

Any solutions yet?

 

thanks, J

[MacWright]

follow up info:

 

short version - even with the "elem.c-923 execution incomplete" error it appears to have completed the backup, how do I check?

 

longer version:

 

after dismissing the error message and not restarting Retro or the rebooting, the sequence of scripts continued and successfully copied a small folder from disk to disk without any problems. Feeling all warm and fuzzy about Retro again I reran the offending script and it appeared to copy effectively but it only copied the files that were just copied disk to disk.

 

The problem is that I received an "Execution incomplete" because of "ele.c-923", it seems to have copied the files but I can't manually check everything to be sure and Retro assumes that the files have been backed up...... what would you do.

 

Here's the log to help clarify:

 

? Retrospect version 6.1.126

automatically launched at 10/5/2006 10:00 PM

+ Retrospect Driver Update, version 6.1.4.103

 

+ Normal backup using Bkup_A_Fotos at 10/5/2006 10:00 PM

To backup set 05-17-04 A…

 

- 10/5/2006 10:00:24 PM: Copying Backup_260gb on 260gb_int_A… (**this is the first report of the error)

Internal consistency check failed:

Assertion check at "elem.c-923"

10/6/2006 7:18:50 AM: Execution incomplete. ( **tells me that the execution is incomplete but I don't know what is incomplete )

Completed: 189 files, 2.5 GB

Performance: 4.5 MB/minute

Duration: 09:18:26 (00:05:37 idle/loading/preparing)

 

Quit at 10/6/2006 7:19 AM

 

(** and now Retro runs a quick disk to disk of 179mb of files and then I ran the same script from above but it only copied the 179mb of files)

 

? Retrospect version 6.1.126

automatically launched at 10/6/2006 7:19 AM

+ Retrospect Driver Update, version 6.1.4.103

 

+ Duplicate using retro_bkup at 10/6/2006 7:20 AM

 

- 10/6/2006 7:20:03 AM: Copying RetrospectCatalogBkup on Macintosh HD…

10/6/2006 7:20:36 AM: Comparing retrospectBackupA on 260gb_int_A…

10/6/2006 7:20:45 AM: Execution completed successfully.

Completed: 2 files, 179.1 MB

Performance: 524.1 MB/minute (335.7 copy, 1193.8 compare)

Duration: 00:00:42 (00:00:01 idle/loading/preparing)

 

+ Normal backup using Bkup_A_Fotos at 10/6/2006 7:21 AM

To backup set 05-17-04 A…

 

- 10/6/2006 7:21:26 AM: Copying Backup_260gb on 260gb_int_A…

10/6/2006 7:32:37 AM: Comparing Backup_260gb on 260gb_int_A…

10/6/2006 7:33:45 AM: Execution completed successfully.

Completed: 2 files, 179.1 MB

Performance: 114.3 MB/minute (83.9 copy, 179.0 compare)

Duration: 00:12:19 (00:09:11 idle/loading/preparing)

 

 

I appreciate any thoughts, or random acts of help. regards, j

[MacWright]

>There is a Knowledge Base article about this general type of error, but it does not nail down this one specifically…

http://kb.dantz.com/display/2n/articleDirect/index.asp?aid=6307&r=0.319607

 

I've also hunted for info on this specific error code and none seems to be posted. Is it safe to say that if it's not contained in the knowledge base that you need to use a paid support system to get this info? or does anyone from EMC/Dantz frequent these forums?

 

thanks, j

[nekr0phage]

Hi,

 

You're not likely to find specific information on most assertion failures, as they are typically due to an inability to handle a specific scenario, not a generalized error.

 

The first recommendation for troubleshooting assertion failures is typically to pull the configs - remove Retro.config(6.0) from /Library/Preferences/Retrospect while the application is not running. Then, launch Retro, enter your license code, setup a test backup and see if the problem is gone.

 

This will be more difficult if the problem is intermittent, but clean configs should be the first step. If the problem persists you'll need to isolate what triggers the assertion: a particular client, a certain backup set, backing up to a tape drive, etc.

[MacWright]

Thanks,

 

btw..... that response would be a great addition to the searchable knowledge DB.

 

regards, j

[rdzman]

In my case, this error was caused by a client (Windows) whose clock was way out of sync with the clock on the backup server. Fixing the client's clock and restarting Retrospect on the backup server cleared up this repeatable crash for me.