Why is SuperDuper not running at scheduled time?

[Chris_Porter]

I expected to wake up this morning with a completed backup on one of my external hard drives, since the script calls for it to run every Friday morning at 12:30am. However, no backup was made, and after launching SuperDuper to investigate, I found that it didn't run at all, and neither had the backup for Monday morning (on another hard drive). How do I find out what was happening that stopped SuperDuper from running these backups? (what log should I check, etc). There didn't appear to be any problem when I woke up, and all external hard drives were on (but not mounted). I ran diagnostics on the externals, TechTools said they were just fine.

I have full backups scheduled for Monday, Wednesday, and Friday mornings. Only the Wednesday backup had been completed for this week! I need to know what's stopping the other backups from running.

[dnanian]

Do you have a wake event set for one minute before the scheduled backup time? See the User's Guide section on "Scheduling" for the various requirements...

[Chris_Porter]

Originally Posted by dnanian

Do you have a wake event set for one minute before the scheduled backup time? See the User's Guide section on "Scheduling" for the various requirements...

Yes, of course I do, this is a long-standing script (set of three scripts), and the computer is woken 5 minutes before scheduled backup. Normally the scripts have worked, so I need to find out why they haven't been working--what log should I look in, and what activities do I need to note that made Monday's and Friday's backup not work, but Wednesday's backup complete?

[dnanian]

Five minutes, though, is not one minute. It needs to be one minute, Chris...

[Chris_Porter]

Originally Posted by dnanian

Five minutes, though, is not one minute. It needs to be one minute, Chris...

Why does it need to be one minute, when it's worked for months and months with 5 minutes?
eta: It worked on Wednesday, with the 5 minute startup. It's worked for months with the 5 minute startup. I'm thinking this is not the issue.

[dnanian]

Because if it's more than one minute, your mac will sometimes go to sleep before we can start, regardless of your sleep setting... as you're seeing.

[Chris_Porter]

Originally Posted by dnanian

Because if it's more than one minute, your mac will sometimes go to sleep before we can start, regardless of your sleep setting... as you're seeing.

And this is a known random occurance, that hasn't happened to me before? I looked through the userguide, it gave no reason to start up one minute before. Perhaps this issue should be addressed. I know that after startup, the computer's not scheduled to sleep for 30 minutes, by settings in the Energy Saver. I'm unclear--is there a known fault with Energy Saver?

Are you sure there isn't some log that describes what is going on after startup so I can see why Friday's backup did not behave like Wednesday's backup? I'm really skeptical that the issue of going back to sleep is the fault, since it's not behaved that way in the past.

[factorypower]

I have a mac xserve and it is not honoring the schedule either and it is set so it Never goes to sleep... When I viewed the schedule there was no date and time listed in the "next scheduled backup" column. I clicked the schedule and then "OK" and it put the correct date in the column... This is the second time I have found it not running according to the schedule. I just shot an email off to support about this, and thought I would check here as well...

So my 2 cents on your issue is that my machine never sleeps and is experiencing similar issues...

[dnanian]

Actually, the manual does explicitly suggest this:

Usage tip
SuperDuper! does not have to be running for a schedule backup to
take place, but the user who scheduled it does have to be logged in,
with their account in front (if Fast User Switching is active), and the
screen must be unlocked.
If your Macintosh is asleep when the time comes to run the backup,
SuperDuper!’s scheduling won’t wake it up, so the backup won’t run.
The way to handle this is to use the Energy Saver Preference Pane in
System Preferences to schedule a wake (or “start up”) event for a
minute before the backup is scheduled to run.

OSX is a bit flaky about how it decides and when it decides to put things back to sleep, but based on my own research one minute is what you need, and that's why I suggested it.

[dnanian]

Your issue is a different one, and it sounds like you're not logged into the account that has the schedule. See the User's Guide for the various restrictions in that area...

[Chris_Porter]

Originally Posted by dnanian

Actually, the manual does explicitly suggest this:



OSX is a bit flaky about how it decides and when it decides to put things back to sleep, but based on my own research one minute is what you need, and that's why I suggested it.

Yes, I did actually read that, but since the backups have been working previously, I just assumed it actually meant you have to wake up the computer before SuperDuper starts, ie, the number was a guideline of minimum duration. I had no inkling OSX is flaky about going back to sleep immediately after waking up.

(Though, I can see why you wouldn't want to put that part in the UG about the OSX system being flaky. I do think you might say there's been some research on it, and one minute is the optimum, or something like that. I took it to be a guideline of minimum duration, since it never occured occurred me that if you wake up your computer, it would go back to sleep immediately, but rather would do so at the time you instruct Energy Saver to put it to sleep.)

Anyway, I will change to wakeup one minute prior to backup, and see if that "solves" the issue.

[dnanian]

Let me know!

[HUskerMn]

Sorry, I didn't realize that the log event would get deleted with the failed schedule, so, I don't have the log. It did say something about failed permissions and I wonder if this 'wake event' thing could have caused it. I've scheduled a wakeup for one minute before the new schedule at 12:30 am tonight just in case.

[dnanian]

Shouldn't have, but let's see what happens this next time through.

[HUskerMn]

I was proactive and checked the permissions on the backup drive. I surmised there might be something wrong since I just migrated everything (including the SuperDuper schedule) to a new machine. I was right. The ownership on the drive was listed as system which I think was interpreted as the old system because I changed it to my user and it ran flawlessly as it had before the migration.