What is a best practice

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.

Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at Sullivan Strickler, which helps companies manage their legacy data

7 comments
  • Another great post, Curtis! I couldn’t agree more – not everything is a best practice just because some consultant (like me or you) decides to call it that. Everyone should trust his gut and decide what makes sense for their unique situation.

    I just penned a (concurring) response to this over at my new Enterprise Storage Strategies blog http://developer.nirvanix.com/blogs/strategies/archive/2009/05/07/are-best-practices-just-shared-opinions.aspx. I point out my old three-part test for best practices: Is it prudent, widely-used, and low-risk? I think your description and mine would agree when presented by a given practice.

  • I’m glad you liked the post. You and I have talked about this in the past. I only disagree with the second element of your list of three. I don’t think that popularity determines whether something is a best practice or not. If that was the case, it would never be a best practice to use disk in backups or to properly stream your tape drives, for example. Almost no one properly streams their tape drives and at some point, putting backups on disk was new. That doesn’t mean it’s not a best practice.

  • You indicated something a few times here that I think you should hit even harder:

    Have a business reason for what you do.

    Even if you’re just going to use defaults, or follow Best Practices/Industry Standards, know why you’re picking that option. Even if the reason is, “No time to investigate,” you at least know why you have things the way they are, and can answer to it if asked.

  • I’ll echo what Nick says, Having a valid business reason for what you do is always a best practice!

    As for the “widely-used” part, Curtis, I don’t mean we should all be lemmings. I’m using this as a gating factor more than as a positive. In other words, we should not do things that have not been widely done – pioneers get arrows in their backs! A wise man lets others try things out (perhaps not in production, or in less-sensitive areas) before moving ahead.

    I know what you mean, though. Someone has to be first. But I believe that being first can never be a best practice!

  • Just had to say it. Ne dit jamais jamais. (French I learned from Styx)

    Never say never

    BTW, I live my life as a pioneer. No wonder I have all these arrows.

  • best practice is a nice way of saying “hook it up like this, or you’re on your own”

  • If it’s your vendor, then yes. But that’s not my primary goal when I’m talking best practices. In fact, some of my usual best practices go AGAINST what the vendor’s support line says.