Right-size your backup strategy

FREE

Become An Insider

Sign up now and get free access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content from the best tech brands on the Internet: CIO, CITEworld, CSO, Computerworld, InfoWorld, ITworld and Network World. Learn more.

Multi-layer backup schemes can be complicated and expensive, so know your business objectives before you buy

Enterprise data protection and backup schemes range from the very simple to the very complex. In all but the simplest environments, you typically see a patchwork of software and hardware functionality layered together to prevent nearly any kind of data loss or corruption. Unfortunately, the technology deployed often defines the capabilities, rather than the business defining the capabilities that the technology must deliver. This is a dangerous trap to fall into -- both for you and for your organization.

Like an onion, a well-designed data protection scheme has many different layers, with functionality provided by different pieces of software and hardware. A wide range of technologies may come into play: SAN-to-SAN replication, SAN-provided storage snapshots, off-host backups, disk-to-disk backup, deduplication, virtual tape libraries, and server-based snapshots.

Some of this extra complexity is simply a result of the enterprise data explosion. As your pile of data grows, eventually you may reach a point where adding bigger and faster tape drives simply won't cut it. But the real driver for most backup complexity is a need to provide faster response to data loss and corruption events. Tape is great technology, and it won't disappear anytime soon, but it has comparatively poor recovery-point and recovery-time limitations that may make it ineffective as a sole solution.

So where do you start? Focus on your organization's needs first. The two biggest things to define before you buy are your RPO (recovery point objective) and RTO (recovery time objective).

RPO refers to the maximum age of the data you could restore in the event of a data loss. If you do nightly tape backups, your recovery point will be a maximum of 24 hours. That is, if you experienced a data loss just prior to your nightly backup, your youngest backup would be from the previous night. Worst case, you could lose an entire day's worth of production data.

RTO refers to the maximum amount of time it will take you to restore the data. This figure incorporates a number of parameters, from finding the correct backup resource (tape, etc.) to the actual time required to restore the data. This end-to-end time objective should also include securing a replacement server in case the data loss is a result of hardware failure.

Depending upon the type of technology you bring to bear, RPO and RTO can be measured in weeks, days, minutes, or even seconds. But a wise backup operator will immediately recognize that neither of these two factors are really technical issues at all. At their core, RTO and RPO are business objectives, not IT objectives. Ergo, it is absolutely critical that you let business stakeholders define them.

This may sound like a recipe for disaster. After all, you generally wouldn't ask the VP of Marketing or CFO what kind of SAN or servers to buy. Why should you have them define how you set up your backups?

There are two great reasons for this. Once you have an RTO and RPO defined by upper management for a given application, you can design a solution that achieves those objectives -- including all of the technology necessary to achieve the goal. If they balk at any additional cost that might be involved, you can work to find a middle ground between capability and cost.  When the process is complete, your stakeholders have been completely educated about what the capabilities will be in the event of failure -- and they, not you, will have driven the process of investing to achieve those capabilities.

That might seem like an awful lot of footwork (and it is!), but it is critically important for the leaders of your organization to understand how long they might be without various services in the event of failure. If they understand, for example, that with the technology you have in place, the RPO and RTO on a line-of-business application is one day and three days, respectively, you may be surprised how quickly the company wallet pops open. If they remain ignorant of those numbers until a failure takes down the system for a few days, you may find yourself looking for a job.

To continue reading, please begin the free registration process or sign in to your Insider account by entering your email address:
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies