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).
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.