David's Discussions

What do train tracks and data backup have in common? Do you happen to know why train tracks are 4 feet, 11 3/4 inches apart in England? Because they were built following the ruts left by Roman chariots.

Stop Backing Up!

I am not kidding, guys, just stop it.

One of my favorite questions to ask smart IT folks is why they backup data at all. After the unavoidable litany of doing file level restores, email restores, server restores, compliance requirements, etcetera, etcetera, we come to the real answer: the guy before me did it this way.

Who was this guy anyway? For all we know his retention scheme was based on the number of tapes that came free with the Travan tape drive he bought in the 80s. At least there is some logic to that answer.

In all seriousness, there are lots of good reasons to do backups, but far fewer IT shops have these requirements than we think. So before we spend a small fortune in deduplication, application agents, WAN acceleration, and tape infrastructures, let's figure out if what we are doing is really serving our objectives or just another (Roman) rut.

Objective 1: Restore a file / email—snapshots anyone?
If you really want to get a file back fast, utilize some host-based or (even better) array-based snapshot mechanism. In most cases, these are free and easy to implement and sure beat re-cataloging a bunch of tapes. Oversize your storage by enough to store 30 days worth of snapshots and you have met the requirements for 99% of the restores out there encountered by IT pros. In terms of email (specifically Exchange), leverage the tools already at your disposal, namely Deleted Item Retention. Not many users are using Shift+Delete in their day to day, so this covers this common restore handily. Restores outside of a 30 day window are extremely uncommon, but monthly and even annual snapshots are possible—these, though, should have a pretty good rationale before implementation.

Objective 2: Restore a server
An uncommon restore in the grand scheme of things—but definitely something we want to be prepared for—is bringing the whole server back (potentially offsite). I have yet to find a bare metal solution I really admire (reliable, inexpensive, easy to use, easy on storage, etc). My personal favorite solution here is leveraging some sort of virtualization, even if you only put one virtual machine on a physical server, along with some mainstream replication technology. The virtualization technology can be the free stuff for this to work, so all you are out is the replication software cost or array replication cost, which is generally in the same ballpark as backup software and some old server hardware that you would otherwise be using to hold up your installation manuals in the back room. This solution is far more effective toward the goal and much easier to test. Did I say test? Yeah, do it. Figuring out server level restores at 2AM sucks. In terms of retention, I have no use for a server image from a year ago. I am sure I can contrive a reason to be contrary but that’s just being obtuse. So keep an image, or a week’s worth, and move on.

Objective 3: Compliance
Okay, you got me. This one and its ridiculous retention requirements may drive us to tape purgatory, but at least I never really have to use them for operations. My compliance officer can hug the tapes at night, but I am not betting my job on a media that cannot be tested outside of an actual restore and is very susceptible to environmental fluctuations such as heat, dust, gravity, humidity, cold, air, time, quarks, palm sweat, the breath of the tape guy, etc. I would still like to have it in writing from someone who has to sign the check for this stuff (boss, lawyer, compliance officer, etc) as to exactly why they ask for the retentions they do. Again, maybe they got their guidance from the guy with the free tapes in the 80’s…