The first group responds by telling me about how often they do fulls and incrementals, how long they keep the tapes and how often they send them off site. The second group is only a little more sophisticated: They have one answer for databases and another for files.
Only the third group is sophisticated enough to ask me what I mean: Am I referring to backup or archive? Which service level am I referring to? And so on.
The first two groups are guilty of focusing on the mechanics of their backup environment--dealing primarily with operational concerns, such as tape management. They share two common attributes:
If the first two scenarios remind you of your organization, here are a few things that you can do to begin to evolve to a model more like that of the third group.
What really matters?
An optimized backup environment delivers services that are aligned with the business requirements of the organization. This requires having both the capabilities and resources available to meet these service demands, as well as the policies and processes in place to apply these resources where appropriate.
In backup environments, an all-too-common approach is to define a set of policies based primarily on two attributes: retention and the frequency of full backups. Often, decisions about these aspects are based not on an understanding of business need, but rather on IT operational standards or a vague sense of what is generally believed to be acceptable.
That approach may not adequately meet the data protection needs of the organization. It would be far more useful to develop an approach to backup policy that ensures that resources and capabilities match business needs. Here's how to begin.
First, develop service objectives, a set of attributes around which a service is defined. An SLA is a written agreement between IT and a user for providing a set of services that have been defined by one or more service objectives.
Clearly, backup frequency and retention are important backup service objectives, but there are others (see "What's your objective for backup?" on this page) that merit some additional comments. Although "backup" is commonly used to refer to the entire backup/restore operation, users don't care about backup at all. Their real concern is restorability. Two attributes go to the heart of that concern: recovery time objective (RTO) and recovery point objective (RPO). Respectively, they answer the questions: "How fast can data be restored?" and "How current must that data be?"
Focusing on frequency and retention doesn't address those concerns. To establish RTO and RPO, gather and define requirements for your key applications. How well is the value of data understood within the organization? Many organizations are attempting to establish tiers of primary storage in which the most important data is placed on Tier One storage, and less important data place on more economical, Tier Two storage devices. The definition of RTO and RPO requirements for data can be thought of as one of the more important elements of this data classification process.
Another increasingly important service objective relates to historical data retention, also known as archiving. Archiving is different from the retention and expiration parameters of backup data. It's a point-in-time snapshot of selected data that is intended to be stored and retrievable for a significant period of time. Archiving is more about content than format, so it's often a completely separate process from backup, one in which selected content is dumped into a standard format for safekeeping. The renewed concern about regulatory compliance is driving a re-examination and modification of archive policies and procedures.
The goal of analyzing your backup capabilities is to establish a set of metrics that help to define the level of services that can be delivered. Typical questions you must answer are:
You have to balance what's feasible, what's desired and what it costs. This is where having a clearly understood set of metrics becomes essential. If you can't meet requirements for data recovery with current resources, then either the requirements must be modified or the resources expanded. Having the data available to present to senior management and to users is the key to negotiating realistic service level agreements.
Having the right backup policies is only one part of the much-larger issue of storage management. Everything that has been discussed about service objectives and service capabilities can be applied to other areas of storage. Developing backup policies is part of a process of shifting focus from the inward perspective of storage management to an outward view focused on the needs of the business. It's possible to be good operationally (regular backups completed on time, etc.), but bad from a business point of view (unable to restore key data in the time required). Reviewing policies is a good place to begin coming to terms with that problem.