Jump to content

Retroconfig file fragile and corrupted easily and WAY too damaging when lost


Recommended Posts

For the second time in two months my retroconfig file has been hosed by Retrospect crashing. The first was caused by a tape drive crashing the server constantly. Now, it was caused by two kernel panics that Retrospect caused when trying to recycle media on a backup set stored on disk.

 

I tried it once, and it panicked. I rebooted and tried again, panic. I was going to go in a third time and tell it not to try that, but I can't get in again because the retroconfig is now hosed.

 

So later tonight I will go reregister the software. I will add back in every single client by hand. I will reconfigure all disk options on the clients. I will recreate all backup items off of the local RAID. I will recreate all scripts and try to get my (probably corrupted now also) catalog files to work.

 

I will waste about 3 hours of my time again. For absolutely no good reason.

 

So maybe you should investigate the recycle media option for data sets saved on hard disks. It panics the machine. And no I am not going to try a third time just to make sure.

 

Also--it might be a really good idea to rethink the retroconfig file. It contains too much stuff. Mine is around 50 megs which seems crazy for a config file. Why not store client config info in one spot, registration in another, and the other 49.9 MB of whatever in a big file by itself. The retroconfig file is *obviously* very susceptible to corruption. It puts every single egg in one basket. I dread launching the software every time it crashes because i seems statistically likely that it will mean a start from scratch configuration of the product again.

Link to comment
Share on other sites

Quote:

For the second time in two months my retroconfig file has been hosed by Retrospect crashing. The first was caused by a tape drive crashing the server constantly. Now, it was caused by two kernel panics that Retrospect caused when trying to recycle media on a backup set stored on disk.

 


 

Can you provide a description of your hardware/software setup?

 

 

Quote:

So later tonight I will go reregister the software. I will add back in every single client by hand. I will reconfigure all disk options on the clients. I will recreate all backup items off of the local RAID. I will recreate all scripts and try to get my (probably corrupted now also) catalog files to work.

 

I will waste about 3 hours of my time again. For absolutely no good reason.

 


 

No good reason other then you didn't have a backup of this critical file.

 

Quote:

So maybe you should investigate the recycle media option for data sets saved on hard disks. It panics the machine. And no I am not going to try a third time just to make sure.

 


 

I've done scores, and scores of recycle backups to File Backup Sets, and never, ever seen a panic. Such panics are almost always hardware related; knowing your system configuration might help point out what's going on.

 

Quote:

The retroconfig file is *obviously* very susceptible to corruption. It puts every single egg in one basket. I dread launching the software every time it crashes because i seems statistically likely that it will mean a start from scratch configuration of the product again.

 


 

As with any other valuable file, a backup would allow you to fall back to the last saved version. There would certainly be no need to start from scratch if you'd burned a CD copy of this a week or a month ago, especially if you have as unstable a system as you describe. We Duplicate our Retrospect preference folder, as well as all our catalogs, to another location as part of our nightly backup script.

 

It's all about disaster recovery, no matter what the cause.

 

Dave

Link to comment
Share on other sites

Sorry about the quasi-rant. You are correct about needing to backup the retroconfig file separately. I am going to begin backing this file up through a network share whenever changes are made, and keep backing it up with the server data tri-weekly. I hope a total corruption of the file will not happen again--but I didn't expect it to happen again the second time either.

 

I still think that Dantz should spilt this information up into several files. Apparently the config file is accessed while Retrospect is running, and can be corrupted during a crash. Having so much information in one place isn't an intelligent practice.

 

I have tracked down the problems in my system (I think). After the Retrosepct software hosed itself, I got a chance to go through the server very carefully, because it was already out of service at that point.

 

The problem was with an ATTO UL3S-33 card being used in conjunction with a UL3S-66 card in our Xserve. Apparently when these two cards are used together something bizarre and bad happens. I replaced the offending card with an ancient ATTO UL2S card and things are running more smoothly than at any time before. I have ordered a new adaptec 31960D card to replace both cards in the system with next week.

 

Hopefully things will settle down now. For the first time since purchasing the software/hardware the server made it through an entire backup cycle (25 network machines and local drives/RAID) without freezing or rebooting itself.

 

Hopefully no more kernel panics either. I will eventually try backing up to disk again but I need to watch Retrospect work correctly for a few months before feeling confident enough to make big changes again.

 

So. The problems were hardware related, but Retrospect didn't handle the failures with grace. It can't compensate for the hardware flaws of course, but it should protect itself better than it does. I should post this to the suggestions board too.

 

Thanks for your help.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...