Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Flaky execution of scheduled backups? No Sat. AM in "Daily"? (http://www.shirt-pocket.com/forums/showthread.php?t=1172)

DrDan in MA 03-21-2006 11:12 PM

Flaky execution of scheduled backups? No Sat. AM in "Daily"?
 
I've been having difficulties making SD! do backups regularly. I'm running SD 77 on a PBG4 and a Mini, each MacOSX 10.4.5 (all updated) and each with its own external, mounted, formatted FW HD with a previous Full Backup already present on that partition. I've got both systems set to wake up at 0320 each day, and a smart backup set to happen at 0330. Sometimes it works, but most mornings when I wake up, the backup has not happened! :( Howcumdat?

What more info can I/should I have supplied to make this question answerable?

OBTW, it appeared one Friday evening, when I scheduled a backup for DAILY at 0330, that the next scheduled backup was SUN at 0330. However, as I'd hoped, when I awoke on Saturday AM, the 0330 backup had happened. So this may be simply some feedback problem...

dnanian 03-21-2006 11:53 PM

Because you should set the wake time for one minute before the backup time.

There's a known issue with the "Next Copy" column but it's purely a display thing -- the backup will occur on the right day. We have the display problem fixed internally, and the fix will be included in the next update.

DaleMeyn 03-22-2006 08:22 AM

Just and addendum: I've noticed that when Energy Saver wakes my iMac up for the scheduled update, the iMac will go back to sleep before the update happens if the wakeup was too early, even if the programmed interval before going to sleep is set for 20 minutes. For example, if I set the computer to wake up 1 minute before SD! is scheduled to back up, it will happen, then the computer will stay awake until 20 minutes after the backup is finished. If I set the computer to wake up, and nothing is done, it goes back to sleep in a minute or so.

dnanian 03-22-2006 08:31 AM

That's exactly right. I don't know why Energy Saver does this, but it does... so, if you set for one minute before the scheduled time, we start running before it has an chance to forget that you wanted it to be awake. :)

DrDan in MA 03-22-2006 08:51 AM

Hmm... ah do bleev (IIRC) that I was experiencing the problem when the wakeup-call was at 0329, so I backed off 9 more minutes, hence 0320. However, I'll reset the wakeup to 0329 and see what happens, to report back in a day or three.

As ever, tnx for the feedback, dnanian; and also to you, DaleMeyn.

Glad the known issue is display only; as I said, the SAT 0330 backup (which was one of those that "took") did happen despite that buglet, so I guess that agrees w/the data. :)

DrDan in MA 03-24-2006 09:36 AM

Mixed results, to report, thus far. Both my Macs are OSX 10.4.5 and running the latest SD! (2.1v77), but there's only one that performs its backup consistently -- the Mini. As for my AL-PbG4, it's got a backup set for 0330 and a wakeup set for 0329 (like the Mini), but it hasn't done its thing for a couple of days. Yesterday's, well, perhaps because I hadn't mounted the external disk (an 80 GB partition of a LaCie 160GB) prior to going to bed. So last night, I was sure to have done that, but as of this AM, no log could be found.
Incidentally, this would be an appropriate time to note that it appears, to these not-on-the-code-side eyes, to be inordinately difficult to monitor what SD! has done recently. It seems to me that every different scheduled event has its own "subdirectory" in an INVISIBLE subdirectory, and if there's a given repetitive event, all successful execution logs of that event are kept together but majorly hard to get to. I haven't yet found a way of viewing all recent logs together, which would (imho) help me in figuring out what's been done and what's been missed. If my understanding of what I'm groping for is intelligible, what would be cool is if SD! had an easily-accessible, consistently-named, single, non-invisible subdir, within which all recent copy logs could be displayed. I suppose that each separate scheduled copy event could have its own subdir within this dir, and then I could just display the dir in time-ordered format to see which was the most recently executed event. Then I could dive into that subdir to see what just happened, while at the same time being able to retain easy access to, understanding of, and thus to get a larger context of, all other recent copy events. Does this sound like a reasonable enhancement?
While I was watching this CPU and later writing this, SD! successfully did a backup at 0800 after the CPU woke itself from sleep at 0759.
I'd scheduled the event at 0740 and had then manually put the machine into SLEEP mode, and left it alone till at 0759 it awoke with the LaCie drives still mounted...
The (smart) backup I'd just scheduled for 0800 was in fact, happily, successful, taking about 14':20" but, even though I'm virtually certain that I had asked that this event should SLEEP the AL-PbG4 at its conclusion, that didn't happen (maybe because I was "using" the CPU at that point, though I made sure not to touch TextEdit as the SD! run was finishing its copy and stopping). I couldn't verify that the SLEEP was supposed to happen, though, when I re-opened the event for inspection and editing. Strange, possibly irrelevant.

Anyhoo, perhaps SD! has difficulty in REALLY awakening the LaCie drive when it's been asleep for hours? But there's no record of what might have happened at 0330 today... Hence my interest in a single spot for looking at logs...
Further idle thoughts: If SD! event X were written and saved at 1600 on a given day, so that it is "in place and ready" for later execution at, say, 2330 that same day, and something prevents that from happening, is there a mechanism for saying "HEY -- event X was supposed to happen but didn't, and here's (what we know about) why..."...?

dnanian 03-24-2006 09:54 AM

We rely on the system's wake and scheduling features to do their things. If those don't work reliably, it's hard for us to work reliably, and harder still to "work around" the problem, since we didn't "write" that part.

As far as logs go, there's no plan for an integrated log "folder", no. But we're always looking for ways to improve things, and I have various ideas in this area.

But, anyway. If the drive wasn't mounted, your backup would fail. Why the second one failed is something I can't explain, but if SD! wasn't "waiting to run" when you woke, it means it probably didn't wake at all, or went to sleep very, very quickly after waking.

If you're comfortable doing so, you can try to change your crontab to run the event at 3:30:30 by changing the "0" at the start of the line to a "30". Then, set your wake event to 3:30, and see if that works...

DrDan in MA 03-24-2006 03:30 PM

Hi Dave, thanks again for your prompt and helpful responses.

"We rely on the system's wake and scheduling features to do their things. If those don't work reliably, it's hard for us to work reliably, and harder still to "work around" the problem, since we didn't "write" that part."
I hear you on that.
As far as logs go, there's no plan for an integrated log "folder", no. But we're always looking for ways to improve things, and I have various ideas in this area.
Well thanks for letting me vent :) I've often found that developers have already thought of better ways to address issues than just plain end-users; glad you're already processing ideas for improvements in this area...
But, anyway. If the drive wasn't mounted, your backup would fail. Why the second one failed is something I can't explain, but if SD! wasn't "waiting to run" when you woke, it means it probably didn't wake at all, or went to sleep very, very quickly after waking.
Waitamminnit, I do remember times when I've awoken the system in the morning, and there was SD! all bright-eyed and bushytailed, already beginning its work. I didn't understand why that might have been... so what you're telling me is that those times represent occasions when OSX didn't even ever wake from sleep. If this repeats, I guess I'll bug the folx at AppleCare.
If you're comfortable doing so, you can try to change your crontab to run the event at 3:30:30 by changing the "0" at the start of the line to a "30". Then, set your wake event to 3:30, and see if that works...
OK, I don't mind doing this if it'll help, but your description doesn't help me enough, please add some specificity... I find that can't change the final 0 of 3:30 into 0:30 within the usual SD! edit screen, so I'm assuming (???) that if I get into the TERMINAL app and look for "CronTabs" I can edit one. If it's not too much hassle, could you pls point me to doc of just how I do this? ... and how changing the time that the SD! run will start from an integer to a fraction of a minute will help things out, if in fact it's the OS's problem for not having woken up at all? In other words, I don't understand where this is going or how I can help do this suggested test. :)

dnanian 03-24-2006 03:39 PM

I don't think the AppleCare guys are going to be of much help, Dan.

If you had a situation where, when you woke your computer SD! was there waiting, it did indeed start to do its thing, but the system decided it would be best to put it to sleep again. Which is frustrating. Tweaking the crontab will likely help.

Snag a copy of CronniX to edit the crontab, actually. It should let you change the "seconds" to 30 seconds past the minute, rather than the minute itself...

DrDan in MA 03-24-2006 09:55 PM

OK, I just snagged & installed CronnIX and used it to mod the crontab that I'd previously set for 0330 to start the SD! run. Now, if I did it all OK, SD! will launch at 03:30:30. I also changed my sys wakeup event to 0330 as you suggested. Now I see the method to your fix -- tighten up the interval between sys wakeup and SD! startup.

Hopefully when I awake Sat. morning, I'll find a backup completed & waiting. I know that Sat. AM is not "showing up" in the display of SD!'s intentions (it still sez that the next backup will be SUN 0330) but we both know that it'll try on SAT morning.
I wondered whether having "changed the crontab behind SD!'s back" would cause SD to complain or display what was afoot, but no problems displayed themselves when I looked at SD!'s scheduled backup screen...
Film at 0700ish... :)

dnanian 03-24-2006 10:23 PM

Sounds good. Let's see what happens!

DrDan in MA 03-25-2006 03:30 PM

Well this is strange data. Last night, the Mini's scheduled backup didn't happen, witness that when I awoke it from its sleep around 0700, there SD! was, all rarin' to go. I cancelled that run, but soon just started it again by hand. (Incidentally, imho it would be useful, if it isn't done yet, for there to be logs created from SD! copies that are initiated by hand... (??? Is this there already and I've just missed it???)

Now comes the the really strange data. :confused: I was up late last night to watch what happened at 0330 (I'd scheduled a sys wakeup for 0330 and used CronniX to change the crontab for an SD! run from 03:30:00 to 03:30:30. I'd been working on other stuff but put the AL-PbG4 to sleep manually at 03:27.

Promptly at 03:30:00 the system awoke from its brief slumber, with the external LaCie drive mounted. I use iPulse to monitor the sys and time, and watched 03:30:30 come and go with no launch of SD!.
As far as SD! is concerned it "believes" it has a scheduled copy set for 0330, witness its text in the SCHEDULE window, under What's going to happen? -- Daily at 3:30AM, "Backup-all files will be used to copy Al-PbG4 to LaCie80Gb. Smart update will...

However,

CronniX reports that the CronTab of DrDan is
Minute [] 30:30
Hour [] 3
Day of month [x] *
Month [x] *
Day of week[*] (All)

and that the cmd to be executed is
open file:///Users/DrDan/Library/Application\%20Support/SuperDuper\%21/Scheduled\%20Copies/Smart\%20Update\%20LaCie80Gb\%20from\%20AL-PbG4.sdsp/Copy\%20Job.app
with the "Prepend "/usr/bin/open" box not checked.
So I watched the seconds tick by... and to my surprise, promptly at 03:31:00 SD! was launched, and the successful run of SD! began at 03:31:15 and went until 3:49:29.

Perhaps the crontab at 3:30:30 kept the PbG4 from resuming its sleep, but SD! wasn't capable of starting except on a minute boundary, hence its start was rounded up?

One tiny piece of external evidence for that hypothesis is that despite the internal display of this event as being scheduled to start at 0330, the log of this run has the filename 2006-03-25 03/31/15 -0500 (when it actually started) and was last modified at 03:59 (when it ended). The title bar of this log reads
Smart Update LaCie80Gb from AL-PbG4.sdsp - Sat, Mar 25, 2006 at 3:31AM

Is anything here of any value? :)

dnanian 03-25-2006 04:12 PM

Well, that's strange. You have to recognize that we don't do the launch -- cron does. If it didn't launch us at 30:30, it must be because cron is only running at minute boundaries, unfortunately. Rats.

One more thing to suggest. Snag a copy of NMS Sleep Assist from Version Tracker. Set up a "sleep hold" for SuperDuper... maybe that'll prevent things from sleeping on us... worth a try.

DrDan in MA 03-25-2006 07:03 PM

OK I've got NMS Sleep Assist 2.3Beta3 installed, but (and I hate to ask) :o I need some more hints as to what to set. Are you suggesting, say, that I forget CronniX (since there seems to be no granularity less than a minute for crontabs), set a normal energy-saver sys wakeup at 03:29, and then that I somehow (guidance needed here?) tell NMS Sleep Assistant to hold off sleeping for awhile (say a min or three) and schedule an SD! run for 03:30? I see where I can put custom holds on a per-app basis. Assuming SD! is in the right place (/Applications) what do I put where? :confused:

And am I the only one with flaky SD run startitude? If so I guess my M.O. as "Worst-Case-Dan" is still alive. :D

dnanian 03-25-2006 07:17 PM

No, leave things exactly as-is. But, set up a "Sleep Hold" in NMS Sleep Assist for "SuperDuper!:0", "SDCopy.root" and "Copy Job:0".


All times are GMT -4. The time now is 06:39 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.