The question of what backup software application should an organization use comes up all the time on the online forums I visit on LinkedIn and Spiceworks. The answer to that question typically come from vendors who, of course, say “Use my stuff, it’s the best.” Or users who say, “Use this product because I use it and like it.” While answers from actual users do have value, that value is limited because in almost every case we don’t know what the original poster is trying to accomplish. All we actually know is they don’t like what they have and they want to try something new.
Stop Throwing Software At The Problem
The success or failure of a backup application within an organization has as much to do with process as it does with technology. Most of the time when an organization decides to make a replacement, the IT administrators are struggling through a particular issue or shortcoming. When they look for new solutions they make sure it won’t have the same problem. But they might miss that it has other problems, like not protecting the entire environment or not supporting the cloud for DR.
Create Service Level Objectives
The first step is to create a clearly defined set of objectives for your data protection process and then communicate those to the organization as a whole. Generally speaking, all disasters come in one of four forms; server outage, data corruption, system failure or site disaster. Each of these failures needs a specific set of steps in order to recover and, in some cases, multiple data protection applications are needed for each type.
The next step is to identify the key applications/data sets. How much data does each application and/or data set have? How fast is it growing and how quickly does it change? Then decide what application needs to be recovered first (service level agreement). How long can they be down (recovery time objective)? How much data can be lost (recovery point objective)? How long do you expect to retain backed up information and why?
Write out the answers to the above questions based on your own internal understanding of things, don’t include anyone outside of IT yet. This is just a rough draft. The goal is to get it done, getting something, anything, in writing puts you ahead of 80 percent of the IT professionals out there.
After you have your draft, the next step is to assess what software you have today. How close can it get to meeting those above objectives? It is safe to assume there will be short falls, that’s your gap. It’s time to fill it in.
My first stop would be to your incumbent vendor, see what they can do to fill in the gap. Trust me, getting your current solution, that you’ve already paid for, working is typically less expensive than buying something new. Tell them, if they can’t fill in the gap, you’ll be forced to find another vendor.
If you do have to interview other vendors, then show them this document you created. Tell them that this is the standard that they will be held to, you will find that sales tactics quickly drop, technical guys are brought in and real work gets done. In fact, the technical will probably hug you (hopefully not a long awkward one) for putting so much advanced thought into the issue.
We’ve written and spoken a lot on the process of data protection. The theory is simple, it is almost impossible to hit a target if you don’t know how to find the target. Successful data protection requires planning and goals. Service Level Objectives are our term for that process.
Want help? Email me. I’ll write up the next few service level rough draft requests at no charge.