While beginning work on a series of articles entitled “NetBackup Best Practices,” I was reminded of the arguments I’ve had with customers and coworkers about such things. Some argue that there is no such thing as a best practice. Others argue that they don’t apply to them. Click Read More to see what I think.
How does one start an article entitled Backup Best Practices? What do I say in 800 words or so that can help out your backup environment? I’m reminded of the question, “How does one eat an elephant?” The answer is “One bite at a time.” So here’s the first bite.
First we need to agree on what a best practice is. We can start with this web definition:
A technique or methodology that, through experience and research, has proven to reliably lead to a desired result.
Does that mean that everyone should follow every best practice? Not necessarily. There are lots of environment and business reasons why a given best practice cannot be used in a particular environment. That doesn’t cease to make it a best practice. It’s just a best practice that you cannot follow.
For example, we can probably all agree that it is a best practice to drive on the correct side of the road. It’s also a best practice to stay on the road and not off it. (Yes, I think the correct side is the right side, but let’s argue that point another time.) However, what if you are on a two lane road and there is a giant truck headed in the opposite direction in your lane? Well, of course, you should abandon the best practice and move to the other lane, while still following the best practice of checking for oncoming traffic. If you see other traffic, then you should abandon the best practice of staying on the road and go off-roading immediately.
Does this mean that it is not a best practice to drive on the correct side of the road or to stay on the road while driving? Absolutely not. However, I get people arguing all the time that a given best practice isn’t a best practice because it doesn’t apply to them. There are exceptions to every rule. There are reasons why a given best practice shouldn’t be followed in certain circumstances. It’s still a best practice.
Therefore, I would modify that web definition slightly to say this:
A technique or methodology that, through experience and research, has proven to reliably lead to a desired result – and should be followed except when there is a valid business or technical reason for not doing so.
Please don’t take this definition of a best practice as an easy way abandon a given best practice, though. You should examine any best practice and the benefits it tries to bring, and see if there is a way you can modify your environment to use the best practice.
I see this all the time when working with end users. They say, “we can’t follow that best practice because of this other requirement.” And that’s that, as far as they’re concerned. I ask them to examine the other “requirement” before so easily dismissing an important best practice. Often when they do that they find out that the other “requirement” is either outdated, or is based on another “requirement” that is outdated. Change the first outdated requirement, and voila! You can follow the best practice!
A friend of mine tells a story about cooking meatloaf. A mother was teaching one of her children on how to make Great-Grandma’s famous meatloaf. One of the very important elements of the recipe was that you have to cut off the ends of the meatloaf when cooking it. The child didn’t understand and asked why you do that? The mother assured her child that it was important, but the child refused to accept this “requirement” without a good reason why. So the mother called her mother and asked her why. The answer was, “That’s what my mother told me to do.” In frustration, the mother called her grandmother and asked about the cutting off of the ends of the meatloaf. Her grandmother’s answer was simple: so it would fit in the pan that she cooked it in.
Sometimes we do things just because we always did them that way. Before abandoning a given best practice, be sure to examine your motives for doing so and make sure that it’s not because your great-grandmothers pan was too small.
Let me finish this article by relating all of this to the best practice of using automatic discovery in your backup system. I feel strongly that if your backup system supports automatic discovery of the filesystems or databases on your server, you should use it. For example, NetBackup’s ALL_LOCAL_DRIVES, NetWorker’s All Saveset, and TSM’s all-local entry will all find all drives/filesystems on your server and back them up using your backup product. I’ll probably write a separate article just on this best practice at some point, but suffice it to say that I believe strongly in this best practice. However, what if 30% of the servers in your environment are test or development servers, and doing backups of all filesystems on those servers is really a waste of time? After some investigation, I might agree that it’s OK to abandon this best practice for those servers, but it’s still a best practice.
So it turns out all I had room for was arguing that we should have best practices. Actual best practices will come in later articles. Thanks for your attention.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.