Auto backup to local, encrypted sparsebundle fails but manual backup works?

Question

Auto backup to local, encrypted sparsebundle fails but manual backup works?

I configured Time Machine to back up to an encrypted sparsebundle using the instructions described here: http://forums.macrumors.com/showthread.php?t=434960 I was happy to see that the instructions worked beautifully for Snow Leopard and the initial Time Machine full backup worked without a hitch.

However, the next day I was disappointed to note that Time Machine had not performed a single automatic backup. Examining the system log via Console.app showed me the following single-line entry:

*11/20/10 Nov 20, 3:14:29 AM com.apple.backupd-auto[3183] Not starting scheduled Time Machine backup - time machine destination not resolvable.*

I tried to invoke a backup manually by using the Time Machine menu item and selecting "Back Up Now," and this worked just like the first time without any problem. It also left the following (very correctly-functional-looking) lines in the system log:

*11/20/10 Nov 20, 3:15:30 AM com.apple.backupd[3333] Starting standard backup*
*11/20/10 Nov 20, 3:15:32 AM hdiejectd[3339] running*
*11/20/10 Nov 20, 3:15:33 AM com.apple.backupd[3333] QUICKCHECK ONLY; FILESYSTEM CLEAN*
*11/20/10 Nov 20, 3:15:36 AM com.apple.backupd[3333] Disk image /Volumes/Achilles Time/Achilles.sparsebundle mounted at: /Volumes/Time Machine Backups*
*11/20/10 Nov 20, 3:15:36 AM com.apple.backupd[3333] Backing up to: /Volumes/Time Machine Backups/Backups.backupdb*

(And then there were some other lines, which I've truncated because they all look great.)

The thing to note is the 2nd and 4th lines, where hdiejectd is running and where backupd looks for the volume mounted at */Volumes/Time Machine Backups*. It seems Time Machine is automatically recognizing the ComputerName.sparsebundle (in my case Achilles.sparsebundle), mounting it to "/Volumes/Time Machine Backups" and then carrying on as normal.

So my question is, if it can do this when I manually start a backup, why can't it do this for scheduled backups automatically?

I've looked at various plist files, specifically the ones at

/System/Library/LaunchDaemons/com.apple.backupd*
/Library/Preferences/com.apple.TimeMachine.plist

but nothing seems out of place--at least not to my inexpert eyes.

I realize that using Time Machine to back up to a local, encrypted sparsebundle is "not officially supported," but I don't think it's too far-fetched a thing to do, is it? Any and all guidance, especially resource to become better oriented within Time Machine internals, would be appreciated. Thanks in advance.

Mac OS X (10.6.5)

Posted on Nov 20, 2010 3:35 AM

Reply

Answer 1

JLMMac

Level 1

0 points

Nov 21, 2010 9:17 PM in response to Meitar Moscovitz

I'm having the same problem.

Reply

Answer 2

baltwo

Level 9

62,362 points

Nov 21, 2010 10:02 PM in response to Meitar Moscovitz

Then, I suggest the macrumors forums where the hint started.

Reply

Answer 3

Nov 21, 2010 10:24 PM in response to baltwo

That's a good idea, too. Consider it done:

http://forums.macrumors.com/showthread.php?p=11462333#post11462333

Thanks.

Reply

Answer 4

baltwo

Level 9

62,362 points

Nov 21, 2010 10:37 PM in response to Meitar Moscovitz

Reply

Answer 5

Nov 22, 2010 10:02 AM in response to Meitar Moscovitz

I'll add a "me too", and if you move the backup disk to another machine, and let it be accessed via sharing, it works again (reselected it via TM Preferences) ... obviously not an acceptable solution.

And this started in 10.6.5, been using encrypted sparsebundles for more than a year without issues

Message was edited by: eidolonical

Reply

Answer 6

Nov 22, 2010 10:23 AM in response to eidolonical

As a temporary workaround, add a crontab entry to run every hour and invoke

<PRE>
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
</PRE>
without arguments. You could also create a LaunchDaemon if desired.

Reply

Answer 7

Nov 22, 2010 2:52 PM in response to eidolonical

Yet another workaround - seems to work ok for the desktops.

<PRE>
/System/Library/LaunchDaemons/com.apple.backupd-auto.plist
/System/Library/LaunchDaemons/com.apple.backupd-wake.plist
</PRE>
I've removed the -auto, and -wake arguments (delete the line), from the above files, and the backups function pretty much as expected.

After boot/reboot unless you explicitly select the TM Volume where the sparsebundle resides, the icon does not change to the TM icon. You will also get the "The identity of the backup disk has changed since the previous backup" popup, just say hit "use this disk". Its interesting that the identity has not changed and all the UUID's are correct, and only when using arguments to backupd-helper does it fail. Bizarre.

Reply

Answer 8

Pondini

Level 8

38,863 points

Nov 22, 2010 9:20 PM in response to eidolonical

eidolonical wrote:
. . . You will also get the "The identity of the backup disk has changed since the previous backup"

Yes, the usage of one of the elements in the plist was changed in 10.6.5, breaking a number of hacks.

See: http://discussions.apple.com/thread.jspa?threadID=2651772

Reply

Answer 9

Nov 22, 2010 10:01 PM in response to eidolonical

Thank you for this nudge, eidolonical. I can confirm that adding a LaunchDaemon to invoke the job works. For those unfamiliar with launchd but who feel comfortable using Terminal, here's a suggestion for a simple thing to do to work around this issue.

*Step 1:* Copy the "com.apple.backupd-auto.plist" file to make your own Time Machine helper file using the following command (while logged in to your Mac as an Admin account):

sudo cp /System/Library/LaunchDaemons/com.apple.backupd-auto.plist /Library/LaunchDaemons/com.apple.backupd-helper.plist

*Step 2:* In the new file, delete the line that reads "<string>-auto</string>". You may also want to write a comment to yourself about what this file is. Save the file. Here's what mine looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.backupd-helper</string>
<key>Disabled</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd- helper</string>
</array>
<key>StartInterval</key>
<integer>3600</integer>
<key>RunAtLoad</key>
<false/>
<key>KeepAlive</key>
<false/>
<key>EnableTransactions</key>
<true/>
<key>SHAuthorizationRight</key>
<string>system.preferences</string>
</dict>
</plist>

*Step 3:* Load the new job into launchd using the following command:

sudo launchctl load -w /Library/LaunchDaemons/com.apple.backupd-helper.plist

*Step 4:* Enjoy. Yeah, that's it.

With this workaround, hourly scheduled backups will function, but the times they actually start will depend on when you loaded the job into launchd. That is, the "Next Backup" time as reported by the Time Machine System Preferences preference pane will be inaccurate.

I can live with that, but I thought it was worth pointing out.

Reply

Answer 10

Nov 22, 2010 11:24 PM in response to Pondini

So would this be com.apple.TimeMachine.MachineID.plist, so what has changed ?

<key>VerificationDate</key>
<date>2010-11-01T21:30:16Z</date>
<key>VerificationExtendedSkip</key>
<false/>
<key>VerificationState</key>
<integer>1</integer>
<key>com.apple.backupd.BackupMachineAddress</key>
<string>00:1b:63:9b:d1:1f</string>
<key>com.apple.backupd.HostUUID</key>
<string>00000000-0000-1000-8000-001B639BD11F</string>

As you can see the "mac" addresses matches, and the UUID matches ...

or is this some weirdness with DestinationUUID in /Library/Preferences/com.apple.TimeMachine.plist ?

Reply

Answer 11

Pondini

Level 8

38,863 points

Nov 23, 2010 6:43 AM in response to eidolonical

eidolonical wrote:
So would this be com.apple.TimeMachine.MachineID.plist, so what has changed ?

No, sorry, I posted the wrong link. 😟

Try: http://discussions.apple.com/thread.jspa?threadID=2647291

It's the DestinationVolumeUUID vs. DestinationUUID in:

/Library/Preferences/com.apple.TimeMachine.plist

Reply

Answer 12

Nov 23, 2010 5:51 PM in response to Pondini

So which UUID should it be ?

The Volume UUID (where the sparsebundle resides)
or
The Volume UUID of the sparsebundle (the value it actually has in the plist)

What I find weird is that if the Volume is remotely mounted, it works fine, just doesn't work locally mounted, and it only doesn't work iff you use -attach, -auto, or -wake for backupd-helper.

Reply

Answer 13

Pondini

Level 8

38,863 points

Nov 23, 2010 5:59 PM in response to eidolonical

It's not the UUID; it's the name of the element in the plist.

DestinationVolumeUUID vs. DestinationUUID

Reply

Answer 14

Nov 24, 2010 5:50 PM in response to Meitar Moscovitz

just had this same problem backing up to a sparsebundle on a Drobo, the temporary fix works like a charm

Reply

Answer 15

Dec 6, 2010 1:18 PM in response to rocafellaice

This is a regression introduced in 10.6.5. The sparsebundle approach worked throughout 10.5 and 10.6 until now. It clearly is not a problem of principle, since a manually invoked backup to a sparsebundle works fine. OS X was even updated in 10.6.3 (?) to provide better support for sparsebundles by allowing it to automatically grow the bundle if the bundle was full but there was room on the disk itself. So this is a method Apple intend to support.

I have filed a bug on the Developer Bug Reporter (#8734318).

Reply