Hyper-active "Checking Media" on 1 Retrospect 6.1.230 server

[fredturner]

I'm only seeing this on one server of the several that I maintain, and I've tried unsuccessfully to track down any difference between it and the others. What's happening is, even w/ the list of sources for the "floating" backup server pared down to 1, the backup server still hyperactively scans each of the 3 media sets and the Action: constantly shows Checking Media. Other servers initially check media, occasionally Check source, but mostly just sit on Polling.

 

My irritation w/ this is that it didn't use to be this way, and this nonstop "checking media" causes a full CPU's worth of cycles to be used, therefore making my dual G4 server hover needlessly around 50% total at all times. It does this whether a media destination drive is mounted or not (using a rotation of three 1TB FireWire drives).

 

This particular server also has Retrospect 8 installed, but the Engine is not currently running. I'm not sure if there are other components that might interfere, but I can tell you that this problem appeared much later than the installation of Retro 8. I should also point out that everything seems to work well as far as actually backing up, although occasionally I get the dreaded "Cannot write file" or whatever error and have to quit and relaunch.

 

Any ideas?

Thx, Fred

 

Details:

Mac OS X Server v10.5.8

Retrospect 6.1.230, Server version

Power Mac G4/500DP, 704MB

3 x 1TB OWC FireWire 400 drives

[rhwalker]

You only comment on sources being pared down. I think that this is a destination issue.

 

The backup server tries to be accommodating if backup set destinations are missing. Perhaps it needs a destination that isn't there and it keeps trying.

 

Another possibility is a set of corrupt preferences (the config file in /Library/Preferences/Retrospect).

 

If this behavior truly didn't happen some time back (months? weeks?), try quitting Retrospect, copying the config file away somewhere (Desktop or whatever) so you could replace that if it's not the problem, restore an older copy of the config file from a time when you didn't see this problem (then move the restored old config file to /Library/Preferences/Retrospect after qutting Retrospect), relaunch Retrospect with the new config file, see if that fixes it. If not, well, put the old one back.

 

Russ

[fredturner]

Another possibility is a set of corrupt preferences (the config file in /Library/Preferences/Retrospect).

 

You nailed it, Russ. Took a look in the prefs folder and, sure enough, the Retro.Config file was 32.3MB...just a *wee* bit too big. Naturally, I should've known to make a dupe of the file long ago, but did not. All backed up copies of this file are 30+MB as well, so no chance of reverting that way. I'm about to go make some screen shots, etc, and then rebuild the config.

 

Are there any tricks you know of to export settings or otherwise shorten the rebuild process?

 

Thanks!

Fred

[rhwalker]

Took a look in the prefs folder and, sure enough, the Retro.Config file was 32.3MB...just a *wee* bit too big.

Yea, mine is about 300 KB.

 

Are there any tricks you know of to export settings or otherwise shorten the rebuild process?

Other than drinking lots of caffeine and typing fast, no, it's all wipe and type unless you've got a backup saved away.

 

I've been asking for many years now to have the config file be one of the following, in priority of preference:

 

(1) in plaintext readable format, perhaps as xml or some such.

 

(2) exportable to / importable from a plaintext readable format,

 

(3) publish the file specs so that I could write my own code to do (2).

 

Now that Retrospect 6 is dead, none of this will happen, and my input was disregarded for Retrospect 8. Sigh. At least Retrospect 6 has a manual and is pretty reliable. I only know of a couple of bugs, and I know their workarounds.

 

Russ

[fredturner]

Arrrrgggghhh!!! Just got it rebuilt, saved a copy of it, then after I let it start running again, took a look at the Config file...it is already 20MB!! None of my other Retrospect systems do this. Now I'm gonna revert to my copy and go step by step to see where the insta-bloat happens.

 

 

Now that Retrospect 6 is dead, none of this will happen, and my input was disregarded for Retrospect 8. Sigh. At least Retrospect 6 has a manual and is pretty reliable. I only know of a couple of bugs, and I know their workarounds.

 

Heard dat. Was so excited for Retro 8, but it's so much of an unfinished product and so slow that I can't bring myself to go to it full time.

 

Thx,

Fred

[fredturner]

Figured it out...partially. How's this for strange:

 

Got a mix of Mac & PC clients. I set up to only have the Mac clients backup using Backup Server...config file is 224KB. I add in Windows clients, and after the initial backup of each one via Backup Server, right as the status shows "Closing", *boom*-- config file bloats by exactly 4MB. So, after the first PC, it jumps to 4.2MB. After the 2nd...8.2MB.

 

WTH???

 

BTW, some Windows clients are 7.0.112, some are 7.6.107. Both seem equally affected. Mac clients are all 6.3.x.

[twickland]

Arrrrgggghhh!!! Just got it rebuilt, saved a copy of it, then after I let it start running again, took a look at the Config file...it is already 20MB!!

That may not indicate a problem. If you have lots of custom data and complex schedules, Retro.Config can be pretty big. Ours are all in excess of 100 MB.