CrashPlan 3

Do you use local encryption for your backups?

@Martin What do you mean by local? Are you referring to Time Machine?

@Michael: No, I am referring to the available encryption/security features of CrashPlan, see 'encryption' and 'security' on http://b3.crashplan.com/consumer/details.html.

@Martin The self-generated private key? No, I’m not using that. However, my sensitive information is already encrypted on the source drive via encrypted disk images, keychains, 1Password, etc.

Do you use disk images or sparse bundles?

I'm somehow in a conflict here: Disk images are usually easier to use with cloud software (backup, syncing, etc.) while sparse bundles make the hourly Time Machine backup faster … since cloud storage becomes more important, I've converted many of my sparse bundles to disk images.

@Martin I use sparse bundles to encrypt the writable files. They work efficiently with Time Machine, CrashPlan, and SuperDuper. For compressed clones I use regular encrypted disk images.

"I use sparse bundles to encrypt the writable files. They work efficiently with Time Machine, CrashPlan, and SuperDuper."

Do you worry about unmounting the images before Time Machine, CrashPlan, and SuperDuper do their thing?

Avoiding that issue is one of the reasons why I went straight to FileVault...

@Chucky I do unmount before SuperDuper and also at night to ensure that Time Machine and CrashPlan get clean copies. However, my experience is that the OS is pretty good about writing sparse bundles (contra sparse images) in a consistent state even without unmounting. As I see it, FileVault makes things worse because you can’t unmount one set of files while working on another.

"However, my experience is that the OS is pretty good about writing sparse bundles (contra sparse images) in a consistent state even without unmounting"

That's precisely what I wanted your opinion about. Good to know.

"As I see it, FileVault makes things worse because you can’t unmount one set of files while working on another."

Ah. But there is a trick.

Since FileVault puts your home folder as a mount point in /Volumes, you can use TimeMachine, CCC, or SD to backup from that mount point while you are logged in.

It's reasonably trivial to set things up to do your backups in an automated manner that covers all of your bases while using FileVault, as long as you understand that trick.

(For example, my "standard" TimeMachine prefs backup my logged-in FileVault only to AFP partition #1. That gets set when I log into the account. I can then trigger a script that swaps in different TimeMachine prefs that backup my entire HD to AFP partition #2, with /Users excluded, waits until the backup is finished, and then swaps back to my "standard" TimeMachine prefs. Then when I log out from my FileVault account once or twice a month, I log into a 'backup' account that automatically swaps in a third set of TimeMachine prefs that backup my entire HD to that same AFP partition #2, with /Users included. It sounds Rube Goldberg, but I was able to set it up in one morning. And if my math is correct, I should be perfectly well taken care of if total disaster struck, just needing to jump through an extra hoop during the recovery. Similar principles work for SD or CCC.)

@Chucky Well, the problem with that trick is that your backup isn’t encrypted.

"Well, the problem with that trick is that your backup isn’t encrypted."

While the "whole HD" backup isn't encrypted, since we're using FileVault, the "FileVault mount only" backup is indeed encrypted.

Converting an AFP TimeMachine sparsebundle to encrypted is trivial.

(The real problem with the setup is that the TimeMachine sparsebundle password must be stored in the System keychain. I'm currently dealing with that by a combination of security by obscurity, and by manually deleting the password from the System keychain when I'm lending the box out. In the medium-term, I'm planning on creating an automated keychain scripting solution, but keychain scripting is enough of a jungle that I haven't dived in yet. That'll take an entire morning and extra coffee to sort out.)

"The real problem with the setup is that the TimeMachine sparsebundle password must be stored in the System keychain ... I'm planning on creating an automated keychain scripting solution"

Huh. That was initially more difficult than I thought, but it ended up being easy. Funny story if anyone is ever interested.

First I tried Keychain Scripting, which turned out to not be the jungle I was worried about, but then I discovered that it has no way of writing to the System.keychain that way.

Second, I tried the command line 'security' tool. But again, no way of writing to the System.keychain.

Third, I tried teh google, and there I got pretty worried. It seemed the general conclusion was that the only way to write to the System.keychain was through some pretty verbose Obj-C code. I got worried because, while I can do almost anything I want on OS X through AppleScript, GUI scripting, and "do shell script" UNIX, I don't speak Obj-C.

But then comes the happy ending. After a second cup of coffee, I realized all I had to do was the following:

do shell script "sudo '/System/Library/ScriptingAdditions/Keychain Scripting.app/Contents/MacOS/Keychain Scripting'" password "myPassword" with administrator privileges

Then I can very easily write to the System.keychain using Keychain Scripting.

So I added a handler to my "FileVault mount only" TimeMachine pre-flight to insert the correct password for the sparsebundle, wait until the volume is mounted, remove the password, and then quit the root instance of Keychain Scripting. Problem solved.

(And since I couldn't find the answer of how to write to the System.keychain using Keychain Scripting and AppleScript when I googled, perhaps this will get properly indexed and may help fifty intrepid googlers in the future...)

[...] the last year, I encountered lots of problems with both CrashPlan and Time Machine. (They continue to work well for my parents, however.) I’m now using Arq to [...]

[...] Finder tags and the “where from” URL), and Finder comments. Arq, CrashPlan (as of version 3), SuperDuper, and Time Machine all support all of these. Dropbox supports all of them except [...]