Will Backup Run on Password-protected Computer
 

I want to set up an automatic SuperDuper backup. I understand, if the computer is asleep, automatic backup will not run. The solution is to schedule a wake from sleep just before the backup is to start. What about a password protected computer? Will the backup start if there is no one there to enter the password?

I ran an experiment to determine if the backup would run without entering the password when the machine wakes from sleep as programmed. The backup did run as requested. I have SuperDuper configured to do a smart backup into a sparse image file. I expected subsequent backups, after the initial image was created, would be relatively rapid but that does not appear to be happening. I am 6 hours into this incremental backup at this point.

I'm surprised it ran: my experiments showed that it wouldn't, which is why it's documented that way (in the Scheduling section of the User's Guide), but perhaps something has been changed since then.

As far as the image goes, I don't really have the information to comment. You're sure you did a Smart Update? What are you hosting the image on?

I'm not sure what you are meaning when you refer to the the scheduling documentation. This documentation refers to the need to open 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. I did that. My machine is password protected. I was not there to enter the password. Are you indicating that the machine will not wake up unless the password is entered? There was a problem with this backup as documented in my request for support (Case 102026). The problem seemed to happen one hour into the backup.

I am backing up to a 2 TB Seagate drive which is connected to my Airport Extreme router via its' USB port. The computer is wirelessly connected to the Airport Extreme router.

Well, your Mac isn't supposed to fully wake unless you provide a password, and in our earlier tests it wouldn't run scheduled copies. This is mentioned in the Scheduling section.

We'll continue with the other issue in email...

Is there any way to provide the password in the wake up scheduling? I was unable to find any mention of the password in the scheduling instructions. I must be missing it.

I finally found the reference to needing the machine unlocked for the backup to run. I have to be more careful in reading the documentation. In any event, the backup runs but stalls.

There isn't, no. And your 'stalling' seems to be due to a very large Windows virtual disk (see the support reply).

For awhile I recorded programs with EyeTV on a password protected system that would wake from sleep, if recording started before the password dialog timed out and allowed the system to return to sleep. I eventually disabled the password protection because of occasionally getting zero-length recordings that seemed caused by the system going back to sleep instead of continuing to record.

I'm wondering why SD! scheduled copies wouldn't work similarly, assuming the system remains awake and continuing to wait for a password. Maybe it's permissions-related?

That's the general issue: the timing was iffy, and if the backup didn't get recognized as starting right away, the Mac would fall asleep quickly, etc. It just wasn't terribly reliable as a mechanism.

If you recall, I indicated that the backup ran last night until it reached the virtual machine file (visible in the terminal output). I made a second attempt this morning while I was logged in and watching. The backup seemed to stall while it was reading the virtual machine file again. Is there anything different about the "smart" backup that would result in a problem not seen in the full backup? Also, does the failure of a backup to complete leave the backup file corrupted and unsuitable for further backup attempts?

No, they're doing exactly the same thing when they copy the file. A backup failure does not leave the image (in your case) corrupted, unless -- of course -- the network connection failed (etc) which can corrupt a file...

Thanks for the affirmation.

After many months I'd eventually stopped trying to get Elgato's acknowledgement of how that timing could impact EyeTV. Mention here just once how it might similarly impact SD! and a succinct, thorough, satisfying response arrives only 11 minutes later. :)