Problems with schedules randomly not working
 

I'm a Mac IT consultant, and I have a number of customers using SuperDuper for scheduled backups. I also use it myself at home to back up my server. On every machine I try it on, I seem to have an issue where at some point the schedules will just stop executing. The machines are set not to sleep and not to spin down the hard drives, but it doesn't seem to help. The fix, once I realize it's happened, is to delete and recreate the schedule. I've also noticed that using the Copy Now button on the Scheduled Copies window will almost certainly break it. This problem has been observed on the following versions of OS X on a number of different machines:

10.4.x Client PPC
10.4.x Client Intel
10.5.x Client
10.5.x Server

My own server is a dual 867mhz Power Mac G4 (Mirrored Drive Doors) running OS X Server 10.5.4. It's backing up both its internal boot drive to another internal drive, and a Firewire attached data drive to another Firewire drive (on the other port). I've experienced the problem with both of these backup sets.

If you set these schedules to run 'a few minutes from now', when they're in this state, do they run? I'm not aware of anything that would mysteriously stop all your users' schedules like this, save for things like erasing the externals outside of SD! or something like that.

It is a pretty strange problem. Some of it may be users who aren't listening to what I tell them and either shutting the machines down or logging out. My server though I can verify that's not happening since it runs 24/7 and has very little direct user interaction.

What is it that triggers the automatic copies in SD? Does it install a daemon that launches it, or is there a launchd job set up, or what? Maybe I can narrow down the problem if I know what it is that's supposed to make these schedules happen.

It uses cron, and a user-specific crontab.

The first time I looked at crontab -l it was blank. I deleted and recreated the schedules in SuperDuper, then got then did crontab -l again and got following (dummy host name substituted)

0 2 * * 0 open file:///Network/Servers/server.example.com/Volumes/Data/Network\%20Homes/download/Library/Application\%20Support/SuperDuper\%21/Scheduled\%20Copies/Smart\%20Update\%20Server\%20HD\%20Backup\%20from\ %20Server\%20HD.sdsp/Copy\%20Job.app
0 3 * * * open file:///Network/Servers/server.example.com/Volumes/Data/Network\%20Homes/download/Library/Application\%20Support/SuperDuper\%21/Scheduled\%20Copies/Smart\%20Update\%20Data\%20Backup\%20from\%20Data. sdsp/Copy\%20Job.app

So, it seems like SD! is creating little custom app bundles that are stored in ~/Library/Application Support/SuperDuper/Scheduled Copies. I checked and those were present (at least after I had recreated the schedules). The question is, why was the crontab blank? If that's getting dumped for some reason, it would explain why the schedules stop.

I don't know: no 'standard' part of OSX deletes the crontab, but perhaps something else you're installing, that's common between you and your clients, is doing so?

The only thing I can think of is that with my server it's a problem related to the account being an Open Directory account. Maybe since it's not a local user account, the crontab is flushed whenever it logs out or the server is rebooted. I've set it up so SuperDuper is running from the local admin account (which was usually not logged in). If that solves the problem, my suspicion will be that my users are having trouble because they aren't following directions. They may be shutting the machine down, putting it to sleep, logging out, or something.

Along those lines, are there any plans to get SuperDuper's automated backups to run as a daemon so they will execute even if the user that configured them isn't logged in? This is pretty easy to do using a launchd job placed in /Library/LaunchDaemons. All you'd need is a headless version of SuperDuper to call with that job and make the backup.

A daemon version is something we're considering for the future, yes. But, everything is 'easy to do' when you don't have to actually do it. ;)

True enough. I'm sure Chernobyl looked great on paper.

Having the same problem.
 

Because I've been having the same problem on a PM dual-core G5/2.3 (10.5.5) of backups not always happening, I wrote a script to check:

The script confirms that I am occasionally missing backups. My solution is the same as the OP in this thread -- cancel the scheduled backup and recreate it. After than, things work normally for a while and then die again.

You might want to just use Growl to notify on backups instead of writing a special script.

But: when it fails, you get no errors? Does "Copy Now" in the scheduled copies window work? What about setting the backup time to 'a few minutes from now' on the schedule that seems to be failing/not running?

I'll switch the setting in Growl -- had missed that that it was an option to tell me the copy succeeded (wish it would do either succeed or fail). SuperDuper! is enabled in the Growl Pref Pane.

Copy works perfectly normally. I don't get any errors (or a growl notification) when a scheduled backup fails, it just doesn't happen.

OK, so... next time it does this, please try editing the time for the backup to see if that runs...

If I set it for 5 minutes later, it works. There are a number of warnings of the type:

but the backup seems to be fine. This time, I erased ALL previous schedule lines, closed the schedule window, re-opened it to get a new schedule sheet, and entered a new schedule to the blank page. The previous ones always said that the last backup was back in May. Now the new one has it right.

There was also this message in the System Log (might be related):

So far since moving SD!'s schedules to the local user account, it hasn't stopped, though sometimes it takes several weeks before the problem arises. I am hopeful this solved it though.