Friday, July 20, 2012

BC/DR (Part 2): Or, why I left Time Machine

If you read my last post, it might surprise you to find I'm in the process of abandoning Time Machine.  I still think Time Machine is a great product.  In fact, I not only think it is vastly superior to what's probably the most common "backup" mechanism: RAID, and the even more common lack of a backup at all, I think there are areas where it outshines pretty much every other backup system out there.  Specifically, if you boot a Mac off of a Mac install disk, it will ask you if you have a Time Machine backup you want to restore and just do the restore work for you.  I don't know of any other consumer backup solution that has a bootable restore procedure and it's getting to be impossible to find an enterprise solution that can do this.  It's almost impossible for me to overstate how much this lowers your RTO.

Steps to restore from a backup with Time Machine:
1) Install replacement hard drive and stick OS CD in drive
2) Hit "Yes, I want to restore from Time Machine" in boot.
3) Done (I should note I haven't tried this)

Steps to restore from a backup with pretty much anything else:
1) Install replacement hard drive and stick OS CD in drive
2) Install OS
3) Probably install OS patches since your CD is too out of date to run backup software
4) Install backup software
5) Do restore
6) Fix all the stuff that's now broken because the restore libraries aren't compatible with the OS libraries the restore was missing

But for all that, the Pro/Con matrix on Time Machine is still slanted heavily Con for me:

Advantages of Time Machine

  • Backups are stored as normal OS files and thus can be read like normal files
  • Backup/restore software comes with OS, so there's no separate install and restore is extremely easy
  • Setup is nearly trivial, restore is easy and well segregated.  Even respects OS permissions and allows non-admin users to self-restore
  • Self maintains versioning and cleanup

Disadvantages of Time Machine

  • Only runs on Mac
  • You can't change the retention policy
  • De-duplication is done at the file level, not the block level, so if you import 30G of HD video into iMovie and then change the event names (which changes the folder names), Time Machine will create brand new copies.
  • It can't verify a backup is correct, and if one isn't correct, it can't fix it.

My home system has been running Time Machine for 2 years.  I just went and ran diff -qr between the current filesystem and the last Time Machine backup.  There are several files with different contents and a couple of monitor profiles from May of this year that are missing.  None of these particular files are the end of the world, but the problem isn't that these files have incorrect versions, it's that they've managed to keep inaccuracies for months and I didn't know.  Not even that, now that I know it's wrong the only way for me to fix it is to modify the real files so that it will catch the change.  There is no command to have Time Machine scan the entire filesystem and compare what's there to what it thinks is there.  This, to me, is a deal killer.


The system I'm currently building has three parts:

  1. complete, bootable copy of my main hard disk in a USB/SATA enclosure.  In this case I'm particular about the disk.  It's the same as the actual main disk, so if it were removed from the enclosure it could be a drop in replacement for the real hard disk.
  2. second internal disk with a local CrashPlan backup
  3. CrashPlan+ backup to the cloud

This is a relatively expensive strategy (about $150 up front for the disks plus $3 per month for cloud storage), but it gives me several things:


In a disk or total failure, I have a bootable, reasonably recent image.  This speeds up recovery tremendously.  Except for a total, catastrophic, and immediate failure while I'm updating the USB backup, I should only have a gigabyte or so to fetch from a real backup (either local for a disk failure or the cloud for a catastrophic one).  Let's say the house burns down.  My recovery procedure is to go to work and fetch my USB disk, build a new computer around it.  Boot, then recover the rest from CrashPlan.  RPO: nearly immediate.  RTO: about long as it takes to get a replacement computer.


I'm not trusting the cloud.  CrashPlan+ is cheap for online backup (about $3 per month), but I don't trust it.  Lets say CrashPlan loses my backups while my house is burning down.  Admittedly, this seems unlikely, but I've seen reports from most of the cloud services that data has been lost for some small number of users.  My recovery goes back a couple months (more recently if I've dumped a bunch of pictures in and felt like I needed a backup).  RPO: a couple months.  RTO: getting a new computer.


I'm not trusting a disk that's offline.  Like above you can generally trust a disk sitting on a shelf, but you never know for sure until you actually run the restore, which is too late if it's failed.  If I lose the disk entirely I have to rebuild from install DVDs and then get the data from crashplan (which is $150 to have them ship it to me on a replacement disk).  RPO: immediate.  RTO: get a computer plus a day or so.

I'm not yet committed to this and would certainly accept suggestions on better or cheaper ways to do it. I insist at least on having a bootable copy, preferably offsite and a recent snapshot, also preferably offsite.

3 comments:

Chris Heilman said...

Out of curiosity, do you trust the Cloud with your data? Not in a retention way, but in an encryption way. Looks like CrashPlan encrypts your data, can they then decrypt it at the server (like the DropBox issue from a while back), or do you choose the passphrase? Or are you planning on encrypting yourself with something like TrueCrypt and then backing THAT file up with CrashPlan?

Or is it not that big a deal? :P

Christopher said...

I have a two part response to that:

1) I can't think of anything in my backups that I would be horrified if it were leaked. There's no financial data, for instance, on my harddisk. There is password storage, but it's separately encrypted.

2) The backup is stored with a locally generated, locally stored 448 bit key. There is a web restore mechanism which would involve my sending the key to crashplan if I had ever used it (I haven't) but they claim they're not storing it.

Christopher said...

I guess I should note that CrashPlan also offers to back up your server to another CrashPlan user, even without paying them (though it will only run once a day without a CrashPlan+ membership). So you could use my crashplan "server" as a daily backup for free if it's not horrendously large. It also allows you to encrypt those, and they're also stored encrypted so that the person hosting them can't read them.