Backups stop happening with no notification

[sjmills]

From time to time, I realize that I've seen no emails reporting backup successes or failures. I go to Retrospect (11.5.2 right now) and see that no scheduled backups are running when they *should* be, and they haven't run for a few days or a few weeks. Why does the engine fail so catastrophically? This is a *very serious issue*! I see a couple files in Console named RetroEngine_2014-11-18-233330_Tube.cpu_resource.diag and RetroEngine_2014-12-18-233356_Tube-2.cpu_resource.diag (the 2nd one was just generated after I rebooted my Mac Pro and forced the backups to start again by pausing and then resuming all jobs (because for some reason they wouldn't start automatically like they should've at 23:30). And now both backups are stuck at "Preparing to execute" even after 20 minutes.

 

I've attached both logs. Anything else I can provide? I'm running 10.10.1, and I just turned off Instant Scan before the reboot, because I'd previously turned it off in an older version of Retrospect because I hate how much CPU and disk i/o it uses when I need it.

Archive.zip

[Don Lee]

I have seen similar behavior in Retro 10, but only the proactive backups stop running. (scheduled backup scripts continue to run), and a reboot is unnecessary. Restarting the engine is sufficient. This is also fairly rare.

 

If I could figure out what triggers it, I would post the scenario. It appears to me that it does not happen when Retro is "just running". It seems to be triggered when I am re-arranging media sets, adding scripts, etc.

[sjmills]

Just adding a comment so I can follow this topic, because the Follow This Topic button isn't working (OS X 10.10 in Safari).

[Don Lee]

I saw this again tonight - engine version 11.5.3, running on Mac OS X 10.8.5.

 

I include a screenshot of the console. Note that there are several volumes that need to be backed up days ago, and have not run, yet there are other volumes from the same pro-active backup scripts that HAVE been backed up.

 

Odd.

 

I'm sure that if I restart the engine, this will be OK, and the backups will resume, but it is both frustrating and odd that this happens without any warning. At least one of these has not been backed up since April 2nd, which is a long time.

 

Note that for these 3 volumes that are "stuck", the last activity on them was an error. 2 got "-519 comm failed", and VM3 had the usual assortment of"sharing violations" and  "mismatched" data in the compare.

[Don Lee]

The machine "joy" appears to be stuck because the client is stuck. Screenshot included. It looks like it has been in this state for days.

 

I'll reboot the client, but first - kill "retroclient" process on client. (done) That kills the "preparing for backup", but still leaves the "on/off" switch in the client dimmed so I can't turn it on or off.

 

Back to the console - "refresh" of the client fixed the on/off switch in client control panel.

 

Client is "on" now. Rather than restarting engine, I'll wait until morning and see if it has recovered its sanity.

[Don Lee]

I found a problem with the "VM3" machine, and the two other "stuck" volume backups were caused by a single client being stuck.

 

I did not reboot that client, but only killed (sudo kill xxxx) the retroclient process.

 

All is well now. My error.

[Don Lee]

I'm seeing this problem again. Proactive scripts scheduled with the target time long past, and the status "not yet determined". They don't run until I restart the engine. I think there is a bus in there somewhere.