What you will learn from this tip: Establishing metrics, reducing the possibility of human error and collecting feedback from administrators are a few ways your organization can take better data backups. Learn how to refine your data backup procedure.
Consistency is not merely a virtue when it comes to handling data backups -- it's nearly a necessity. If you don't consistently handle all aspects of backups and restores in the same way across the organization, then backups become a lot harder to deal with. You could also find yourself facing a nasty, expensive surprise the next time you need those backups.
Consistency isn't as easy as it was in the days of "One Big Computer" with "One Big Tape Drive." The world is changing even more rapidly today than before. Besides the usual business realignments that have to be reflected by backups, new concepts like information lifecycle management, new technologies like SATA and new rules like Sarbanes Oxley require changing backup policies.
Equally important, more and more enterprises have to back up more than one system. Although consolidated backups are a major trend, there are still multiple backup systems, sometimes dozens of them, to manage in many enterprises. The storage administrator's job is to get everyone singing off the same page and keep them there.
Not everyone needs a procedure to set backup policies. If you're backing up all your servers to a single backup device, such as a tape library, a formal method for establishing backup policies is probably overkill. However, if you have to back up to multiple systems, possibly using different hardware or software, a formal procedure is probably a good idea.
But when you're responsible for backups on multiple systems, you need not just backup policies, but also a well-understood procedure for setting those policies.
A 'terminological inexactitude'
There's a semantic landmine underlying discussions of backup policies and p
To continue reading for free, register below or login
To read more you must become a member of SearchDataBackup.com
rocedures. In most of the business world, a policy is more general than a procedure. An enterprise sets policies and then develops procedures to support them. In discussing backups, the terms are reversed. Policies are low-level criteria, usually set within backup software, and procedures are the higher-level constructs that determine policies. Thus, in backup, procedures manage policies.
So for our purposes, "backup policy" refers to the rules that control the actual backup. These are usually enforced by the software under the term "policy management." Procedures are the methods used to set policies.
A good backup procedure should include the following seven rules:
Sets consistent policies
Your procedure should encourage, if not demand, consistent backup policies across all the servers and backup devices in your enterprise. This isn't always possible, especially in the case of mixed backup devices (such as backing up the data center with a VTL and remote offices with a tape drive directly attached to the server).
Makes sure the policies are clear and as easy to implement as possible
A policy that isn't consistently followed because it's confusing isn't much better than no policy at all. Ideally, everyone should understand the policy and why it exists. That means putting the justification in writing.
Establishes metrics
An effective procedure has clear, measurable and appropriate ways of checking to see that the policies are being followed. Modern backup software with automatic policy management features helps considerably with this.
Strives to take the human out of the loop
A good policy takes people out of the backup process as much as possible, because machines are simply more reliable. It usually isn't possible to completely eliminate humans from the process for economic or other reasons, but minimizing their influence should be a procedural goal.
Collects ongoing feedback
An effective procedure creates policies that are responsive to the real world. That means you need to make an effort to find out from the people in the trenches how well the policies are actually working. Ideally, this is more than a passive effort. Storage administrators should actively seek opinions from the people affected by the stake holders, especially the people who are doing the work.
Gets buy-in
You've heard it before: Get buy-in from the people doing the work. However, it's especially important here because the vast majority of backup and restore failures have human error as a root cause. (Most studies show human error as the number two cause of backup failures, behind media failure. But many of those media failures are a direct result of human error.) And human error is notoriously influenced by the human's commitment to the process.
To be blunt, if you don't have buy-in then you're going to have a much higher rate of failed backups. This is a particular problem with backups at remote locations, when the people doing the backups don't belong to the storage organization and running backups is an auxiliary job.
Makes it easy to change policies as technology and needs change.
The purpose of a backup procedure is to make it easy to establish good policies. Good policies are those that reflect and adapt to the real needs of the organization. A slow, inflexible and overly bureaucratic policy-setting procedure will hinder rather than help this goal.
Resources
Michelle Gruel of the SANS Institute has a presentation of a procedure for developing security policies that can be used as a guide for setting backup policies. Since security is more intrusive on day-to-day operations than backup, the procedure is more elaborate and detailed than the typical procedure for setting backups needs to be, but it contains a lot of good ideas. You can read the report here: http://www.sans.org/resources/policies/Policy_Primer.pdf (PDF).
Michigan Tech University has a less elaborate example of a standardized procedure for policy setting that can serve as a model at: http://www.admin.mtu.edu/admin/policy/gen/1001_1.htm.
Do you know…
How to prevent backup failure?
