elem.c-821 error when Mac OS X server backs up a certain Win98 client

[beth]

a little background:

Under Retrospect 5, I used to often get an internal consistency check error at elem.c-817. Dantz admitted to not knowing what caused this error, and set up a mailing list to announce the problem when/if they figured it out. They killed the mailing list when 6.0 for mac came out, saying essentially "upgrade and see if it works now". Recently we installed the trial version of 6.0 on our mac server (along with the new clients on one of our macs and one of our windows 98 boxes). I still get an error, but this time it's reported as elem.c-821 .

 

when I see the problem:

The problem reproducibly occurs when (with a mac/Jaguar server, running Retro 6.0) retro tries to back up a particular Win98 client. It occurs when scanning the hard drive prior to backing up any files. The error/crash occurs regardless of what files are being backed up, and even for a backup of "No Files". It occurs whether it is a script or a server script, regardless of whether verification is on, in general it happens no matter what options are selected or what script is used to back it up. (I have created and tested several very simple backup scripts to try to isolate the problem). It doesn't appear to be related to the time of day or to any other variables I can figure out.

 

All other clients, including Win98, Win2k Pro, and Mac/Panther, back up just fine.

 

I will try:

- using a disk check utility on the client volume (the server has already been checked), however this hasn't helped in the past

- dividing the client disk into subvolumes and dealing with each of those individually.

 

the computers involved:

The server is running the new (trial) Retro 6.0 for OS X. The operating system is OS X 10.2.8 (Jaguar), hardware is a G4 , 700+ MB ram, backing up to a file (on an external drive).

 

The particular client involved is Windows 98. It's running the new (6) client that came with the trial server we installed. It's a celeron 500MHz, 128MB ram, ~10-gig HD. There is only one volume, C:.

 

 

I would like to hear if anybody else is experiencing this error, and whether dantz plans to do anything about it (since it seems to me to be a known error with a different name).

 

-beth

[AmyJ]

Hi Beth -

 

Under the prior version were you seeing the assert only when backing up this one Windows98 client? Generally speaking, asserts are unrelated to one another.

 

That the problem only occurs on this one client, despite all other clients working sucessfully (including other Win98 clients) would tend to point towards a problem with the client machine.

 

I would start with reinstalling the Retrospect Client (uninstall/reboot/reinstall), the NIC drivers, and the TCP/IP protocols. I would follow that up with a good disk utility to check the volume for problems, along with trying new network hardware (NIC, cable, port). You can swap the cable port easily enough by switching with a client that is backing up reliably.

 

On an industrious day I would swap the hard drive, put a base OS and Retrospect Client on it and see if the problem came back.

 

~Amy

[Gordon Lyon]

I was experiencing the same assertion check "elem.c-817" error running Retrospect 5.1 on a Mac OSX 10.4.x G4. It is currently backing up 12 x Mac OS 8.6 workstations, 1 x Mac OSX 10.4 workstations and 1 x Windows XP and 1 X Windows 2000 workstation. After running successfully for a few months both Windows machines started giving me the elem.c-817 error. Reinstalling the client made no difference, however removing (forgetting) the network clients and then re-adding the client seemed to fix the problem. Of course I needed to add the clients back into the backup script afterwards. This may be only a temporary solution but at least they are currently bing backed up.

[rhwalker]

You really should be running Retrospect 6.1 on Mac OS 10.4.x - that's what's supported. For starters, Retrospect 5.1 won't back up 10.4 metadata.

 

Russ