Journey with me back in time to 2001.

A fresh out of college, wet behind the ears IT Admin comes in to work EXCITED. After years working Mac Support in the Helpdesk while in college, he’s pinching himself that he’s now working in the datacenter – learning Netware, Border Manager, Linux (Red Hat even), networking (just learned what a VLAN is – how cool – down with VLAN 1!), and more. Each morning he stops by the break room to grab his Mountain Dew (1st of the day with 2-3 more to follow), heads to his desk, starts an RDP session from his Mac, and logs into the…

Backup Console

…to look at last night’s successful and failed jobs in Backup Exec. There’s a depressing amount of lines in the failed job list.

Amazingly it’s now impossible to find an image of Veritas Backup Exec 8.0 from 2001 – this roughly conveys the idea.

Months ago he knew that no one really liked to manage backups. Now he understands why. By the time he finishes the morning troubleshooting, he’s often morphed from Excited Young Admin to Sad (Backup) Panda.

Sad (Backup) Panda

At first it was interesting – learning any new system can be intriguing after all. Now he’s realized that no matter what he does there’s simply a daily slog that will often consume hours each morning. Sometimes jobs run long, sometimes jobs are delayed due to other jobs or limited tape drives and disk space, sometimes jobs fail seemingly randomly, sometimes they can be re-run, sometimes not. While there’s a certain satisfaction to resolving errors and tweaking a system to run efficiently, he realizes that there’s a real amount of repetitive drudge work that’s simply required by a backup architecture based on jobs, tasks, and schedules that each operate individually with no awareness of each other. Constant data movement with minimal degrees of intelligence + automation = painful.

And even worse, despite all that work, any given restore may or may not work.

Guaranteed Restore you say?

Ok….enough writing about myself in the third person. 😉 Yes, this was me.

Am I too good to be a backup admin? Nope, not at all. Did I learn a lot both in running+building+upgrading Backup Exec and later IBM Tivoli Storage Manager? Absolutely – I still have a soft spot in my heart for the simplicity yet clunkiness of Backup Exec in the early 2000’s and the complexity yet incredible power of Tivoli Storage Manager in the mid 2000’s (file-level incremental forever was mind-bending). We can even discuss the time spent with Avamar, Data Domain, Veeam, Networker, Commvault, and more (pre-sales architecture plus some hands-on) within that compendium of “learning new tech plus understanding underlying architecture is fascinating”.

This history is a large part of what attracted me to Rubrik’s SLA policy-driven approach enabled by an intelligent, adaptive backup application (aka Rubrik Cerebro) paired with the power of a scale-out file system built to handle incremental backups (aka Rubrik Atlas). That’s not even touching on the other purpose-built components of Rubrik which enable going far beyond backup.

Simple is Hard – takes writing all this stuff.

In future blog posts, I’ll explore more details around SLA Policies, Cerebro and the other items mentioned. I think the next one will likely be “Look Ma – No Hands!” but we’ll see.

Disclaimer: no one at Rubrik is telling me what to write in these posts. Consider this blog series to be the extended version of “so…why in the world did you join a backup company?”.

Spoiler Alert: I don’t think I joined a backup company but rather a company which does backups really well as a primary but not only use case.