OS X Backup: Apple's Backup 3.x

[Update: This post has several updates, but in the end I rejected Backup 3 due to an unacceptable bug.]

I've been trying to figure out how to manage offsite backup now that Retrospect is a lost cause.

I'm using Time Machine/Time Capsule for onsite backup for all of our machines, and testing SuperDuper for an offsite backup of my main machine using an encrypted disk image to work around SDs lack of encryption. That leaves my laptop. Alas, OS X won't mount a networked encrypted sparsebundle image for SuperDuper to use, and I can't backup up my laptop data without encryption.

I can, however, backup just my key laptop iPhoto library to a share.

How to do that?

Well, turns out Apple Backup 3 still works - at least with Leopard. The current version is 3.1.2. Apple will update old versions, and if you're a current MobileMe subscriber it's still available. Free.

Might be just what I need for stuff that doesn't need encryption.

Testing now.

See also:

• Time Machine, Time Capsule and offsite backup
• Online backup – the security problem (it’s not the encryption)
• CrashPlan (or JungleDisk) instead of Retrospect 8?
• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule

Update 4/1/2010: I've now combined scheduled Backup with traveling. Yech. It's stuck on a backup schedule I can't edit and it can't complete. This app never got past beta testing.

Update 4/13/10: APPLE SAYS DON'T USE BACKUP. It doesn't really work with 10.5 or later. Thanks, Apple.

Update 4/14/10: Ok, now they release Backup 3.2. I'm getting whiplash here! Also, I came up with a workaround for the lack of encryption. I use Backup.app to put a backup of my iPhoto Library on my primary drive, that entire drive is backed up by SuperDuper to a local (USB drive) sparsebundle encrypted disk image. This means my current iPhoto library ends up with two local time machine backups, one local backup on my primary server, one local backup via SuperDuper on an external drive, and one remote backup. Five backups feels about right.

The major 3.2 change, besides presumed compatibility with 10.5 and beyond, is recycling. Most significantly, it "improves" restore reliability (kind of scary actually).

Update 4/17/10: I've given up on Backup. I believe it can cause an endless SPOD (spinning pizza of death) system hang when it's backing up to a network share and connectivity is lost (ex: laptop goes to sleep, hang on resume). That's an unacceptable bug.

Can't mount sparsebundle disk images over an AFP network

I can mount several types of OS X disk images from an AFP (TCP/IP) network share, or even from an iDisk (slow obviously), but not sparsebundle encrypted disk images. I can only mount those from a local drive.

This to be a limitation of both 10.5 and 10.6 (Leopard and Snow Leopard). I found a related Apple Discussion thread and an older 10.5 thread on NAS mounting.

I was trying to do this as a workaround for SuperDuper not supporting drive encryption. I had hoped to first backup locally to a sparsebundle encrypted image, then move the image to a shared drive which I hoped to then update over the WLAN. That way I could safely rotate my SD backups offsite.

This doesn't work. We really need SD to support encryption.

Two Problems with SuperDuper backup

I've not been having much luck with OS X backup. I really wanted Retrospect 8.x to work, but every rational voice I trust tells me to stay away from it. It must be terrible to be the responsible product manager.

Time Capsule/Time Machine works ok, but it's not suited for offsite rotation. Carrying around unencrypted data is not a great idea.

SuperDuper! is suitable for offsite rotation, but it has the same problem. Even though it can backup to an image, the image isn't encrypted. You can create an encrypted disk image and have SD do a daily "smart backup" to that; in my testing SD will load the backup on demand and even load the encrypted image (as long as the pw is stored in your local keychain).

There have been many requests for the author to add encryption but he's held off. I hope he'll come around eventually.

The other problem with SuperDuper backup is that you can't test it. The automatic smart reconciliation feature requires payment first. Even EMC provides a 1 month evaluation copy of Retrospect, but Shirt Packet doesn't allow us to test the key backup features of SuperDuper.

See also:

• Time Machine, Time Capsule and offsite backup
• Online backup – the security problem (it’s not the encryption)
• OS X Backup: Apple's Backup 3.x
• CrashPlan (or JungleDisk) instead of Retrospect 8?
• Retrospect 8 - no user guide?
• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule
• Airport Extreme: Firmware update, Time Capsule bugs, tips and fixes

--
My Google Reader Shared items (feed)

The OS X Snow Leopard "Connected As" MobileMe bug

In 10.6.2 I can replicate the same bug described here ...

OS 10.6 - how to change "connected as" default name - Mac-Forums.com

I have an imac & a macbook on my network. when I'm on my imac & i click on the sidebar to connect to my macbook, the same "connected as" name always comes up. i don't remember where this name came from (it's actually my mobileme email address) it's not a name i have listed under users who can share on my macbook. after connecting i have do disconnect then quickly click connect so i can enter in the username i want to use, if i don't then it automatically connects back under the name i don't want. i just want to reset the default "connect as" i guess I'm trying to say. i don't have this problem when connecting from my MacBook

It's a Snow Leopard bug. If you enable MobileMe Snow Leopard tries to authenticate with a remote machine using the MobileMe name instead of a username. I think it's some version of a directory service; in theory it probably lets you easily connect to a remote account with the same MobileMe credentials -- even if has a different username and password. It fails, however, if you try to connect to a share with a different associated MobileMe account.

When this bug hits you can't use the normal "Disconnect" or "Connect As" features. Editing the Keychain doesn't help. You can try clicking "Connect As" very quickly after Disconnecting and it might respond.

If you turn off MobileMe then you can connect and disconnect normally and the "Connect As" feature works. If you turn MobileMe back on the bug returns.

If you save files using this MobileMe authentication scheme on the remote share I think you may run into ugly permissions problems (such as 45,000 0 length files this evening on one failed write attempt).

See also: Gordon's Notes: Tech churn 2010: How do you share a family file?

Update: There's a Take Control book on permissions due out soon. The announcement blog post sounds ominous. I'm going to buy that book, I'll ask the author to check out this MobileMe bug too. Since Apple last updated their troubleshooting permissions document in 2008, and their screen shots go back to 10.2, the author has his hands full.

Update 3/11/2010: Given my recent experiences, I decided it was time to migrate Emiy's account to the new machine, and clean out the old accounts. I did a firewire migration and it went very quickly. After verification and testing I deleted her account on the old 10.5 iMac. On restart my old account on that machine had her user name, but all of my content. So the permissions were more than a bit screwed up over there. I deleted that account as well.

Why you shouldn't use OS X ACLs

The OS X file security mechanism (aka "permissions") was archaic eight years ago. Now it's the living dead.

The somewhat less decayed alternative is to use OS X Access Control Lists (ACLs). They are not widely used, though some geeks use them to share media collections among multiple machine accounts. (This kind of file sharing is not otherwise possible [1] without hacks that remind us that OS X is a dying desktop solution).

This, however, is not necessarily wise. This warning is embedded in Retrospect Professional 7.7 Mac OS Client preferences for ACL backup ...

Allow the Retrospect Client to examine Access Control Lists (ACLs) on Intel Macintoshes. This may cause Retrospect to freeze due to a defect in Apple's implementation of ACLs.

EMC's products are notoriously buggy, so I suspect "freezing" rather than, say, throwing an error message is an EMC bug. On the other digit, however, I believe them. This feels true based on my own experiences, and it confirms a hunch of mine that one should avoid ACLs. Of course this is a good general principle -- don't use features of operating systems and software that are not widely used. A corollary is that you shouldn't consider uncommonly used features when evaluating modern software -- they probably don't work.

[1] Last April Tidbits claimed iPhoto '09 does enable multi-user sharing. It is, however, still undocumented by Apple and thus risky. Even so, I might give it a cautious try once I happy with my 10.6 backup solutions. I'm not happy yet.

Using an HDTV as a low vision monitor - initial test

We have a 21" CRT. We known nothing about television.

On the other hand, my mother likes television and she has lost much of her vision due to macular degeneration. She has difficulty reading the text on a large CRT set to 1024.x768. (LCDs display poorly at non-maximal resolution, and at maximal resolution the font sizes are far too small for her).

Modern HD TVs run at 30" screen at screen resolutions usually seen on 20" computer monitors. So a 30" HD TV might produce a more readable display.

To test this theory I took my MacBook to Best Buy and tried several displays using the mini-DVI to VGA adapter. The results were pretty bad; clearly VGA won't work. (For one thing it drives the display at 60 Hz when it needs 120.)

I didn't have an HDMI to DVI Adapter Cable so I couldn't test HDMI input results. I'm hoping they'll be much better. I'll update this post with future results.

Update 4/5/10: I found a 2006 Coding Horror post on using an HD TV as a monitor. I'd read it some time ago but, of course, had forgotten it. That old post was pretty positive, but I don't hear of people actually doing it now.

iPhone Voice Memos.app - the missing manual

It took me fifty years to learn to tie my shoes. So it's not surprising that it took me months to figure out how to use the "simple" iPhone Voice Memos app.

I doubt many users could have as much trouble as I with an app that seems to have only two buttons, but if you're one of the chosen this is for you.

To begin with, I need to explain the wrong way to use the app. The wrong way is to tap the red button to start, then tap it again to stop. Wrong. Than puts you in pause mode, and to quit recording you might next tap the right side black icon, then go to another screen, then tap the Done icon and so on.

Here's the right way to use the app without an Apple headset. Headset instructions follow.

1. On startup you tap the red button to record. (Ok, I got that far.) You need to hold the microphone reasonably close to your mouth, the app isn't designed to be used for recording lectures and the like -- just for voice memos.

2. Ok, here's the trick. While recording the red button has changed from a circle to two parallel vertical red bars. It's a pause button. What you might miss, because your eye has been pulled to the red button, is that the odd "grill" button (3 black horizontal bars) has also changed. It's now a black square.

3. When you're done, don't tap on the red pause button. Tap on the right black button. Yes, the one that used to be 3 bars but now, if you're paying better attention than I, you will see is a black square.

Tap the black square and you're done.

3. What happens if you tap the red button? You go into Pause mode.

Pause mode looks just like start mode, except for the big red top banner that stays on whatever you do on the phone. In Pause mode the black button is 3 horizontal bars. Now if you tap on the (multimodal, nefarious) black button you go to review mode.

4. In review mode the app will start playing back your last recording. You can click Done to stop and quit or you can play or delete your saved recordings (swipe to delete).

At the point you can see that if your intent is to record and stop, then hitting the red button while recording is a mistake. It puts you in pause mode, and exiting from pause mode involves several precision taps. If you're dictating while driving, this is dangerous. If you fall into the pause trap, your best option is to tap the red button again to return to record mode, then tap the black button to exit.

The Voice Memos.app behaves differently if you're wearing an Apple headset. From a previous post of mine  ...

Gordon's Tech: iPhone Voice Memos.app - the secret feature

I wasn't that impressed with Voice Memos.app when if first appeared with OS 3. I joined the chorus complaining about the audio levels -- or lack thereof. It only works if you talk directly into the phone or headset mike. The record button should be huge, instead the UI is given over to a pointless graphic. It takes too many taps to close a recording. And so on.

There was, I thought, only one good feature of Voice Memos.app. It's fast. iTalk Lite had great features, but it was too damned slow to launch and record (I'd have paid for the pro version if it were five times faster).

That was before I discovered the secret feature.

If you're wearing Apple's earset and you have Voice Memos running, one click of the microphone switch starts recording, a second click stops and saves.

So if I'm driving with my right earset in, I can click dictate and click again. No distraction, no multi-taps, no delays. This is a great feature. Now I love Voice Memos.

So, where the #$$!$ is this documented? My Google searching can't find mention of this feature. Heck, I can't find any documentation on Voice Memos.app...

... PS. There is Apple documentation on some of the microphone switch's features. You can use it, for example, to decline an incoming call (hold 2 seconds) or to switch and hold (click once) or switch and kill (hold 2 seconds). No mention of Voice Memos.app though.