It’s a common misconception that, well, backup sucks. This for the most part seems to come from one of three sources: misunderstandings, issues, or vendors trying to sell you some New and Shiny Thing.
Invariably when someone tells me that backup sucks, it isn’t backup that sucks, it’s the design, implementation or processes at their site that … ahem, suck. Perhaps more so than any other function of IT, backup lends itself most to rigorous procedural implementation. If you think this is why it sucks, I’d suggest that you’re not thinking of the benefits of such processes.
These benefits are:
- Predictability: You know, with absolute certainty, what the end results should be of backup activities, every single day. (Successful recovery from a successful backup.)
- Task management: Only exceptions require additional task management; all other functions are sufficiently routine as to allow standard operational guidelines.
- You know today, you know tomorrow: Not only do you have a good sense of direction in your day to day activities, you also know many of your long term goals as a matter of fact (capacity planning, reporting, etc.)
- Be the hero: That may sound petty, but there’s nothing wrong with knowing that your work helps to ensure the company survives in the event of a failure. This is a great cause for job satisfaction.
- Problem solving: OK, all of IT gets to work in problem solving, but problem solving in backup environments is one of immense satisfaction; you get to take something that’s not working, and not only fix it, but fix it to ensure recoverability.
- Breadth of access and experience: In a heterogeneous environment, a backup administrator gets to work with a very broad scope of operating systems, applications, databases, etc.
Personally, I think this represents great scope for job satisfaction! So let me suggest again – if you think that backup sucks, maybe that means there’s scope to improve things: the design, or the implementation, or the procedures. The job however should be immensely rewarding.