Time Machine, Time Capsule and offsite backup

Time Machine, among its other significant weaknesses, is ill suited to offsite backup – especially when it is used with Time Capsule.

If you attach an external drive to Time Capsule there is an “archive feature” that will shut down TC access and safely transfer the data to an external drive. Problem is, neither the drive nor the backup are encrypted.

Carrying around non-encrypted backups is not a good idea.

There’s a similar problem with a standard Time Machine external drive. If you swap them, you run into the same encryption problem.

The answer for an external drive is to use an encrypted disk image and mount that for TM backups. That doesn’t, however, work with standard Time Capsule archive behavior. I suspect one might be able to disconnect all clients and use the finder to copy the disk images to an encrypted disk image, but I’ve not tested that.

See also:

• Time Machine - Unable to Complete Backup bug on Time Capsule
• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule
• Time Machine- Fail first, then flaw discovered
• Time Capsule 10.5 Backup volume could not be mounted bug

Time Machine - Unable to Complete Backup bug on Time Capsule

I'm not a fan of Time Machine. I run into more TM bugs than I ever saw with cranky old Retrospect -- and I get less notification of problems.

Today I found a critical laptop hadn't been completing it's TM backup for about 2 days. It was showing a common, unhelpful, error message "time machine an error occurred while creating the backup folder".

David Alison's Blog has the answer for a standalone time machine. Turn off TM on the affected machine. Then navigate to your TM backup folders and look for something like "2010-02-01-134046.inProgress". Delete the "inProgress" file.

This doesn't work for Time Capsule though. TC won't let you delete the inProgress file. I couldn't find any report of a fix, save dragging the actual machine specific TC sparse disk image to the trash and starting over. (The official response to all similar problems, by the way, is to wipe the entire TC disk and redo ALL machine backups).

What worked for me was to turn off Time Machine on all the TC clients. Then I restarted the AirPort and then turned TM back on for the troubled machine. The backup chugged away for a while, and then it resumed.

See also:

• Freeing up Time Capsule space – and documentation for Time Machine and Time Capsule
• Fixing the Time Machine / Time Capsule 10.5 "Backup volume could not be mounted" bug

Windows 7 is OS X Warp(ed)

One of my work machines now runs Win 7. It’s the first time I’ve had to do more than play with it.

It helps to know OS X, but it also hurts. There’s a lot of stuff in Win 7 that’s a tasteless and ugly version of OS X. Take the desktop themes (please).

Hard to say if it’s really an aesthetic improvement even over XP. The XP interface feels light, sharp and clear by comparison.

Update: For example - "Program Files (x86)". Thousands of Google hits puzzling over that one. WTF were they thinking?

Update 2/4/10: OS X managed a smooth migration to 64 bit. I've had a few days of experience with the Win 7 mix of 32 and 64 bit ODBC, Oracle, Java, Microsoft Office, SQL Developer, etc. It's a train wreck. It brings back memories of early DOS experiences. This 2007 tech doc tells one part of the dreadful story.

Computing keeps getting more bizarre

At home I’ve retired my six+ year old XP machine. It lives on in a cloned Fusion VM [1] on my iMac. The dead hulk of the machine waits for anyone who might make use of it, but it’s most likely headed to recycling.

It’s a relief to be done with it. It worked well enough to the very end, but it was a flaming security hole (no antiviral software – that cure is worse than the disease) and it howled like a demented banshee.

At home the four Macs and three iPhones are quiet. So quiet I now notice the ever running fan on my G5 iMac, a fan I never heard when the XP box lived. OS X is kind to me. It all just works.

At work though, I still live with XP. Not just XP, but XP layered with monitors, automated maintenance systems, encryption software, automated backup software that isn’t useful, misguided and aborted security layers and only Satan knows what else. At work, computing is bizarre. I don’t think my workplace is atypical; I suspect this is true of many large publicly traded companies.

Consider this.

I reboot a Windows 2003 box after a failed disk cloning attempt to discover the boot disk is hosed. [2]. So I take a look at my personal backups (since the corporate backups are effectively useless) and find the disk has no files.

Nothing.

But Retrospect Professional (Windows) shows the backups have been working.

Nothing will show any files. Chkdsk reports no errors. But 325 of 350GB are in use.

So I try a restore from Retrospect – and it works.

The files are there, but invisible to cmd.exe. (No, not marked as hidden, truly invisible).

I suspect some side-effect of an cryptic corporate attempt to secure/encrypt USB peripherals. It’s not worth trying to debug this – I don’t have enough control over the pieces.

I have to assume we’re reaching some nadir of corporate computing – that things will improve somewhat with a migration to windows 7. It is ever more clear, however, that those of us who are cognitively dependent on our computers will need to have our own computers and network access at the workplace.

Which is good news for the iPad.

[1] Which is periodically slow and awkward on my quad core 10.6 machine compared to Fusion 2 on an older MacBook. Fusion 3 on 10.6 quad core needs work.

[2] Could be a side-effect of the Acronis disk cloning, but I doubt it. I suspect it would have been hosted on any reboot – that machine hasn’t been restarted for weeks.

Online backup – the security problem (it’s not the encryption)

Here’s how you lose everything.

First, someone gets control of your email account. It might be a security vulnerability, or a password attack (note: “tigger”, “angel” and “soccer” are not wise choices), or a password reset, or an inside job.

They then sell your email to someone who takes a look, and finds a backup report from, say, CrashPlan. They then reset your CrashPlan password:

Please submit your email address. Afterward you will receive an email with a link that will reset your password and securely display the new password to you. The provided link will only work for one hour.

Now they have access to everything you’ve backed up.

CrashPlan talks about their 128-bit Blowfish encryption (standard) or 448-bit CrashPlan+ encryption and how robust that is. As Schneier used to point out before he was overwhelmed by the boredom of it, this is rather besides the point. Their use of the industry standard “password reset by email” process means they’ve built a solid steel door on a house made of rice paper.

It’s not just CrashPlan of course. Google is little better. This reset problem is just one aspect of how broken passwords are (don’t get me started on “security questions”. Please.)

CrashPlan also offers a “data password” that encrypts at the client side. So even if someone gets control of your online backup they can’t actually do anything with the data.

Except … Well, CrashPlan’s FAQ dodges around this, but since the encryption is client side they can’t make any changes to whatever you’ve already backed up. So if you want to add, or change, your data password you have to wipe your online backup and start over. If you change it, but don’t start over, you better keep your old and new password since data may be encrypted with one or the other. In my home a full family CrashPlan offline backup takes about 4 weeks, so this is not a trivial change.

Note that I’m using CrashPlan as my example here because they’re the best in the offline consumer backup business, and they are the only offline backup plan I’ve considered. They just have the usual problem with their password reset procedure.

How could CrashPlan make the best of a bad situation? Well, in the unlikely event that they read this, they can research higher quality reset procedures (not #$!$!$ security questions). Those reset procedures often involve two factor authentication procedures, such as the procedure myOpenID almost got right. They involve more expense, so it would be reasonable to for CrashPlan to charge extra for a higher quality security service. They really don’t need more encryption, they need better reset controls.

In the meanwhile this problem has tipped me away, for now, from using offline backup. I’ll continue to rely on physical drive rotation for offline security and I may make use of CrashPlan’s (free, unfortunately – I distrust the longevity of free things) ‘backup to friend plan.

Update 2/4/10: For more on CrashPlan.

Update 5/17/10: Matthew Dornquast of ChrashPlan replies in comments.

EXIF orientation tag bug returns in Snow Leopard - sideways pictures

Almost five years ago Image Capture would corrupt the EXIF image orientation tag on import:

Gordon's Tech: Image Capture Rotate per EXIF iPhoto 5 = Nasty problems

Image Capture has had a bug for several years -- with my Canon camera it duplicates the EXIF orientation tag when it auto-rotates on import. This confuses iPhoto 5.04 -- iPhoto re-rotates portrait images a second time (interestingly the thumb nail is upright) and so the image ends up rotated 180 degrees. I was sure this bug must have been fixed in Tiger. Wrong."

The problem went away with 10.5, but it's back in some form with Snow Leopard. The slide show shows some of my old images sideways. This didn't happen in Leopard.

--
My Google Reader Shared items (feed)

The Blogger in Draft line spacing bug - illustrated

In a kind rebuttal of my claim that Blogger is troubled, Rick Klau, a Google Product Manager, wrote:

… There is a new text editor available on www.blogger.com (available under settings) which is the default on Blogger in Draft. It significantly improves the authoring interface, addresses a number of the issues you referred to, and opens up a number of integration opportunities for us with other Google properties - we're doing QA on the next batch of integrations right now…

When I described the longstanding troubles I’ve had with the Blogger in Draft rich text editor Rick responded;

… Odd to hear about formatting problems with Draft's editor - it's pretty rock solid. Please ping me with any indications of what you're seeing - that's almost certainly a bug that we'll want to fix if it persist…

So I’m pleased to say I have a good example of the bug. I believe it’s related to the old CR/LF, CR, LF problems in DOS/Windows, MacOS and Unix – augmented by the transition to the unicode standard. (I’ve read recently that all of Google’s new tools require translation to unicode).

Here’s a recent post of mine, authored using Windows Live Writer (Windows only) as it renders in Chrome 4.0.249.78 after posting (it shows the same way in WLW):

Here’s how it looks in Blogger Classic using Chrome:

And here is how it renders in Blogger In Draft using Chrome:

Yes, the line spacing is wrecked. From past experience, this is messy to fix up. When you fix the line spacing here, it comes out double-spaced on publishing.

I’ll point Rick to this post. Hope it helps!

Update 1/29/10: Based on Rick's comment below, Google is looking into this one.

Update 2/1/2010: There's a similar bug with Safari on OS X. When you quote a block of text everything double spaces.

Update 3/10/2010: I just had blogger in draft completely screw up a post composed 100% in Chrome on XP. It's far from ready.