Something I’ve periodically mentioned to various people over the years is that when it comes to data protection, simplicity is King. This can be best summed up with the following rule to follow when designing a backup system:

If you can’t summarise your backup solution on the back of a napkin, it’s too complicated.

Now, the first reaction a lot of people have to that is “but if I do X and Y and Z and then A and B on top, then it’s not going to fit, but we don’t have a complex environment”.

Well, there’s two answers to that:

  1. We’re not talking a detailed technical summary of the environment, we’re talking a high level overview.
  2. If you still can’t give a high level overview on the back of a napkin, it is too complicated.

Another way to approach the complexity issue, if you happen to have a phobia about using the back of a napkin is – if you can’t give a 30 second elevator summary of your solution, it’s too complicated.

If you’re struggling to think of why it’s important you can summarise your solution in such a short period of time, or such limited space, I’ll give you a few examples:

  1. You need to summarise it in a meeting with senior management.
  2. You need to summarise it in a meeting with your management and a vendor.
  3. You’ve got 5 minutes or less to pitch getting an upgrade budget.
  4. You’ve got a new assistant starting and you’re about to go into a meeting.
  5. You’ve got a new assistant starting and you’re about to go on holiday.
  6. You’ve got consultant(s) (or contractors) coming in to do some work and you’re going to have to leave them on their own.
  7. The CIO asks “so what is it?” as a follow-up question when (s)he accosts you in the hallway and asks, “Do we have a backup policy?”

I can think of a variety of other reasons, but the point remains – a backup system should not be so complex that it can’t be easily described. That’s not to ever say that it can’t either (a) do complex tasks or (b) have complex components, but if the backup administrator can’t readily describe the functioning whole, then the chances are that there is no functioning whole, just a whole lot of mess.

 

We’re now rapidly heading towards 2010. The world did not collapse at the start of the year 2000, thanks in no small part to the efforts of developers and system administrators across the globe in mitigating Y2K risks.

So where was I, 10 years ago?

Well, I was still working for the most part as a system/backup administrator for a large resources company. I was neck deep in Y2K mitigation projects, notably:

  • Major efforts on a Tru64 environment where the core application could not be upgraded to a supported Y2K compliant version, so the surrounding OS and underlying database had to be upgraded instead to mitigate the risk.
  • Ensuring all my NetWorker servers were running 5.1 so that I could rest easy, knowing that anything that might fail could still be recovered.

The first project was the most frustrating for me. Not because of the work, but because of the “technical project manager” assigned to it. I knew I was in for a long hard haul the first time I had a conversation with the TPM and it boiled down to a 1 hour discussion where I kept on trying to explain why you had to add disks to a machine if you needed additional storage. From that point on my colleagues always knew when I was on the phone to that TPM due to the look of exasperated frustration I would wear throughout the conversation. It was even more maddening that the TPM had a laptop so old and clunky that he could run MS Project or Outlook, but never both at once. That would mean significant delays in responses to emails…

The funny thing is – when I reflect back on that project these days, I realise that it helped to turn me into a consultant. The standard engineer/sysadmin approach to such challenging people usually doesn’t work, so you have to learn to be a consultant to actually make any headway at all. So thankyou, challenging TPM. 10 years on and I don’t find myself silently screaming when I remember that project – instead I’m grateful that I was assigned such a complex project where self management became very important almost immediately out of the gates; it taught me that I was interested in far more than regular system administration. Instead of just being part of a team that did managed services and consulting, it made me want to actually be a consultant myself.

(As to Y2K itself, I spent around 8pm through to around 1am for the crossover at my desk, waiting for the world to fall down around our ears if we’d got it wrong. In a beautiful case of irony, the only major system that fell over during the Y2K transition was the Microsoft Access database designed by some psuedo-admin in another division of the company at the last minute to record Y2K failures…)

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha