arcDoRead: can't install tyce, error -802 (typed-space is corrupt)

[curioffl]

Following a crash of my Retrospect (Multi Server 7.6.123) machine I get:

 

 

tyceInstall: LmRepair failed, code 14

arcDoRead: can't install tyce, error -802 (typed-space is corrupt)

 

on about half of my backups (even after soft reboot). They do not seem to be client related (a client that backs up to multiple sets might only do this on one of them), and upgrading a client, forgetting and readding a client, and recycling a set seems to not have an effect either.

 

The strange thing is, this seems not to have an effect on the backups. I can still backup and I can still restore.

 

Anybody know what this is, and whether I should be concerned? I found only one forum post and the fix was to restore to an old config.bak file... so I did that, one from a week before the crash (and before the first occurrence of this error) and it did not help.

 

Thanks.

 

Ron E. James D.O.

[Mayoff]

this may be debug logging and not a real error. Does the log show a red > next to the error?

[curioffl]

No, but it stopped.

 

The last backup to end with the error finished at 3:14pm yesterday. I did one thing right after that time and one thing right before then which may have had an effect (though I can't think how). Though many backups ended with this error, they appeared otherwise completed and functional, with the exception of two:

 

One is a very large backup to a remote hard drive on a Windows computer. That Windows computer has compression turned on for the folder that Retrospect writes to. The hard drive itself is 1TB (889GB usable) and has some other backups writing to it. The particular backup set took about 500GB compressed, but was over 9XXGB from Retrospect's perspective. Setting the allowed size to 100% would only give 1TB (not sure if that's Retrospect internal or because of the drive) but any backup immediately asked for media, and logged the error. I decided to copy a few snapshots elsewhere and recycle the set... but even a restore would result in Retrospect asking for more media (after restoring a few megs) and recording the error. (That's a heart-dropping thing... when Retrospect appears intent on not restoring.) Since the backup seemed useless, and since this large backup represents only two weeks of files, I took a chance and recycled it (at 2:44pm) and ran a new backup (I'll know if that was the right choice in 13 days).

 

The other thing was that a Linux client was a failing to run at all and was sending the error in its warning mail. (None of the others were, they were only recorded in the operations log, and I would not have known about the error at all if it weren't for this Linux client.) I went to look at its backup set (after noticing the lack-of-restore on the big one) and Retrospect gave me the "Where's the catalog?" behavior. Rather than try a repair, I copied the catalog file to a -orig, and I renamed the backup set's folder to -orig, then I deleted the backup set altogether and made a new one with the old name and assigned it to the scripts, and ran a backup (at 3:25pm) which worked fine. I noticed before I deleted the old set that it had a date on it (in Retrospect) of 4/27 (though it had not sent any error mails) though it should be backed-up to daily and though the mysterious error did not turn up till 5/7 following and overnight stop error on the Retrospect machine. (Looking now, the files in the -orig folder are dated daily including after 4/27 and the operations log shows completed backups to 5/6... but still it said 4/27 for the set's date in Backup Sets window).

 

One of those two actions seems to have resulted in the error no longer recording.

 

Maybe there was some sort of error that resulted in the Linux machine's backup set not updating Retrospect fully (and so the date remained 4/27) but the error was unexpected by the software (which did not record a problem in the operations log initially) and so it had no error mail to send. This new error came along and many scripts were recording it, so when Retrospect reached the same failure on the Linux machine's script it found this other error text to mail? That would make sense except that the log and files indicate completed runs prior to the error... also the behavior after the error was similar to a corrupted catalog error which Retrospect expects. It also doesn't explain why switching sets would make an error disappear that had not appeared for most of the time that the set was ostensibly in error.

 

I don't know... it's weird. I did those two things though and the error that I recorded 100+ times between the morning of 5/7 and the afternoon of 5/9 suddenly stopped.

 

*Shrug* - thanks for the response though.

 

Ron E. James D.O.