4 incredibly useful steps to better backups

In all my years in IT, I can’t think of an everyday task that is more universally loathed than maintaining good backups. Depending upon what size environment you’re running, setting them up in the first place can be a massive investment in capital and manpower, but that’s just the tip of the iceberg. Daily monitoring and troubleshooting often end up making the initial deployment look like a walk in the park.

But it doesn’t need to be that way. Backups can be almost a set-it-and-forget-it affair, although reaching that utopia requires careful planning and a solid understanding of what you want to accomplish. Here are some design tips to help you avoid the most common backup pitfalls.

Step No. 1: Set expectations

As is often the case, the first step is the most important. Before you even begin to think about what kind of hardware and software you’ll use to back up your environment, sit down with your business stakeholders and come to a consensus on what RTO (recovery time objective) and RPO (recovery point objective) you’re trying to achieve. The RTO is the time it will take you to recover a given resource; the RPO is the maximum age of the data that you’ll be able to recover at any given time.

In my experience, IT pros who take the time to have this discussion with management discover that what management finds important bears little resemblance to their pre-conceptions. Either management has nearly impossible RTO/RPO objectives or — surprisingly enough — cares far less than you might think about how quickly you can get certain services back in production.

Either way, building a consensus on what you need to deliver will provide you with two invaluable assets: nearly automatic budgetary justification (after all, this is what they’ve asked for, not what you’re trying to sell) and adequate breathing room to get things rolling again in the event of disaster.

Step No. 2: Define technical requirements

Once you have an idea of what management expects, you can start figuring out how you’ll meet those requirements. One way to make this a bit easier is to spend less time thinking about backing things up — and more time considering you’ll restore them when you need to. Too many times, I’ve seen design decisions made to shrink backup windows that have the unfortunate effect of dramatically increasing restore windows (a frequent side effect of certain types of dedupe and some commonly used tape rotation schemes).

Also, it’s not just about how quickly you can restore a given resource — but how it will be restored. I can’t tell you how much money I’ve seen wasted on application-level backup agent software that doesn’t stand a chance of being used in an actual work environment. Do you really need to be able to restore individual Exchange email messages to a user’s mailbox? How about SQL tables and rows? I can count on one hand the number of times I’ve seen either of these features used in real life.

Most often, a disaster big enough to need your backups also requires a full mailstore/database restore. You may well end up needing more features, but avoid blindly buying features you may never use — and, worse, that will make your solution unnecessarily complicated.

Step No. 3: Keep it simple

The best backup solution is the simplest. I have seen and, sadly, participated in designing some of the most complicated backup mechanisms you can imagine. Between building in various flavors of disk to disk, replicated disk, disk to tape, direct to tape, and offsite/cloud backups, you can meet nearly any set of requirements you’ll ever be faced with. You can also design a system so complex that it collapses under its own weight.

The general rule is to try to use the bare minimum of hardware and software to satisfy the requirements you’ve defined. Ideally, that boils down to a single software package and a single layer of hardware — perhaps augmented by a second layer of hardware that might handle offsite archiving if the first doesn’t.

In a decent-sized, virtualization-heavy environment, this might boil down to a piece of software like Veeam and a backup-optimized NAS device like an Exagrid. For offsite, you might either get a second replicated NAS to park at a different site or toss in a tape drive and some stripped-down software just to shuffle your Veeam images onto tape. With that combination, you can get a very wide range of RTO/RPO, retention, and archival capabilities without introducing unnecessary complexity.

Step No. 4: Remove the human element

After you have an idea of what your solution will look like, calculate in good faith how much time real people will need to spend making it work. I’ve seen some fantastically unreliable backup hardware and software over the years, but the weakest link of any backup infrastructure is usually a human one.

Face it: There are always more important things to do than ensure your backups are working — right up until you actually need them. That often means things fall by the wayside, like investigating backup logs, changing media, and perhaps most importantly actually performing restore testing.

That being the case, try to design your backups so that they’re as hands-off as possible. That may seem like an argument for avoiding tape, and in your environment that may be exactly what it boils down to, but don’t stop there. Some backup software packages have the capability to automatically test backups every time they perform a backup — so an operator only needs to be involved when they fail. Don’t underestimate the value of features like that. Backups that appear to work fine but are, in fact, useless are no myth. I’ve seen the bone-chilling results more than once.

Planning for the worst

No matter how you decide to satisfy your backup and recovery needs, make sure you spend at least as much time designing your backup infrastructure as you do actually implementing it. With that investment up front, you’ll save time and money in the long run. You’ll also avoid the recurring management nightmare that poorly designed backup infrastructures become.

This article, “4 incredibly useful steps to better backups,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.