Backup Basics #2: You're not planning to backup

Think about it: What's the only way you can measure success when it comes to your backup?  It's not how often you back up.  It's not how big or awesome your cloud backup company is.   The only way to measure success when it comes to backing up is:

  1. When the backup restores completely
  2. When the restore happens in time
Not being able to restore is no good.  And like a bad transporter accident, not funny at all.  This design belongs to Glenn Jones; you can buy his T-shirt on Threadless.  Click through and request a reprint!

Not being able to restore is no good.  And like a bad transporter accident, not funny at all.  This design belongs to Glenn Jones; you can buy his T-shirt on Threadless.  Click through and request a reprint!

It's really a simple backup basic:  You're not planning to backup.  Instead, you're planning to restore.  And restoring completely is one thing, restoring on time is another. I have seen companies very nearly go out of business because it took two to three weeks to get their data back, and in the best cases, weeks longer to get back to 50% functionality.   The good news is this can be prevented by asking yourself the right questions, then taking the appropriate actions:

Determine your target restore state first.

The first step is to determine what your target end state looks like.  Always start by assuming complete data loss.  Think of it this way:  If your computer (or phone) were stolen right now, and if you were to go buy another computer right now, what would you need to get back up and running? Here's a list of a few questions I've found most people don't ask:

  • Can you restore your entire platform the the ground up? Could you restore in a way that does not require any reinstallation or reconfiguration?  Most cloud vendors don't advise you that their backups often only backup the data, but can't restore the operating system.   The difference here could be days, even weeks, of time spent looking for restore disks, application installers, licenses, and more.  And that's only if you remember what you had installed in the first place.  Imagine trying to rebuild your house after a total loss in the fire entirely from memory, but without plans, without a concrete foundation or property lines.   Think of all the things you'd forget and all the things you'd miss.
  • How recent is your most recent backup?   The older the backup, the less useful it is.   Restoring is about returning yourself to service.   I've been told using a computer restored to a backup a few months old feels about as awkward and useful as attending one's high school reunion.  Not to mention useless from a productivity standpoint.  Can you afford to lose three months of work and start over?
  • What's your platform dependency?  Even if you have a restorable complete set of data from yesterday, what if you don't have a computer (or phone) that can accept it? PC users are really susceptible here: Windows on a PC ties into the hardware so much that you can't simply restore another PC.  You typically have to start from scratch, reinstalling and reconfiguring everything.   The disruption and expense associated with recovering from hardware failure here is high.   Mac users often think they're immune to such problems, but heightened belief in immunity often comes with increased shock at the cost and disruption of finding out that you have to buy all new apps and the associated migration, or face the unfortunate alternative of feeling cornered into a very expensive repair to keep using your existing software.
  • When was the last time you tested your backup? If you worked at TechRoom for a week, you may be surprised at the number of people coming in for data recovery from a Time Capsule (Apple's wireless backup device).  Just because it reports the backup is good doesn't mean it is. If you want yet another example, read in my previous posts about my 90-day nightmare with an iCloud backup that wouldn't restore.

The next step always reminds me of the clock on the TV show 24.

Determine how long you can wait for the restore to finish.

I was just at a doctor's office recently where a technician had implemented a cloud based backup service that is gaining a lot of popularity as a "low cost" and "simple to implement" backup system that's presumeably Mac and PC friendly.  I see a new one of these every few months.  Like any other technology business where anyone with venture capital can buy a catchy name, servers and some programmers to write code, cloud backup vendors keep popping up like Tribbles.  The problem that this doctor had is that he was never presented with the number of hours it would take to restore his backup.  In a theoretical vacuum, the restore would have taken 5 days.  In reality, the restore would likely take 7-9 days to complete.  

In the case of the doctor, this assumes readiness of everything else, and only waiting on the data.  In the case of most customers, the clock doesn't even start ticking until the problem is understood and addressed by a tech, after which the difficult conversation around data recovery or restoration happens.   What if you planned for the breakdown instead?  What if you chose a backup system based on it's ability to restore in the time frame you required?   The same volume of data for the doctor, over USB 3.0, would take roughly an hour.

How long can you afford to be down?

Hopefully this second Backup Basic helps prompt thought.  At best, it is meant to help prompt action.   Feel free to drop me a line if you have questions or feedback.  I'd love to hear from you.