Why backup theory is important

 Architecture, Backup theory  No Responses »
Dec 302011
 

Obviously the NetWorker Blog gets a lot of referrals from search engines via people looking specifically for help on particular NetWorker issues they’re encountering. Even just in the last 8+ hours, here are just some of the search terms that people used:

nmc doesn’t start

restore networker aborted saveset

networker disk backup module

nsr_render_log command

nsr_render_log daemon.raw

networker centos support

39077:jbconfig: error, you must install the lus scsi passthrough driver before configuring

And the list goes on and on, on a daily basis. This was reflected in the Top 10 for 2011 (and indeed, the top 10 for every previous year, too).

I’ll let you all in on a little secret though: all of those tips, all of those NetWorker basics articles and how to use nsradmin user guides – they’re all just the tip of the iceberg when it comes to getting a working backup system in place.

You see, a lot of sites don’t have a backup system at all – they just have some backup software and backup hardware and configuration. That doesn’t represent a backup system at all. From my article, “What is a backup system?“, I provided this diagram to explain such beasts:

Backup system

As you can see, the technology (the backup software, hardware and configuration) represents just one entry point to having a backup system. The others though are all equally critical; and when you add them all in together, it becomes clear that a backup system will derive much of its success and reliability from the human and business factors.

The technology, you see, is the easiest part of the backup environment; and it’s also the part that’s most likely to appeal to IT people. If you were to graph how much time the average site spends on each of those activities, it would probably look like this:

Imbalanced backup systemsWhen in actual fact, it should look more like this:

Balanced backup system

The short description? If you chart the amount of time you spend on your backup “system”, and the the Technology aspect (software, hardware, configuration) becomes a Pacman to the rest of the components, eating away at the rest of those facets, then you’ve got a cannibalistic environment that’s surviving as much as anything on luck/good fortune as it is on good design.

That’s why I bang on so much about backup theory – because all the latest and greatest technology in the world won’t help you at all if you don’t have everything else set up in conjunction with it:

  • The people involved need to know their roles, and participate in both the architecture of the environment and its ongoing operation;
  • The processes for use of the system must be well established;
  • The system must be thoroughly documented;
  • The system must be tested or you’ve got no way of establishing reliability;
  • The Service Level Agreements have to be established or else there’s no point whatsoever to what you’re doing.

Backup theory isn’t the boring part of a backup system; I’d suggest it’s actually the most interesting part of it. Just as I suggested that companies need to plan to follow some new years resolutions for backup systems, I’d equally suggest that the people involved in backups should start making it their goal to spend a balanced amount of time on the components that form a backup system.

If you don’t have the theory, you actually don’t have a system.

If you want to know more, you should treat yourself to my book (now available in Kindle format).

 Posted by at 06:33  Tagged with: , , , , , , , ,

What is a backup system?

 Architecture, Policies  5 Responses »
Jan 252011
 

One of the core concepts I try to drive home in my book is that you don’t get a backup system by installing enterprise backup software.

Here’s a diagram to help explain what really goes into making a backup system:

Backup system

In short, you can have as much technology as you want, but without the rest of those pieces all you’ve got is a budget sink-hole.

If you want to understand how all these concepts fit together, you really should take the time to invest in my book, “Enterprise Systems Backup and Recovery: A Corporate Insurance Policy“.

 Posted by at 06:44  Tagged with: , , , , , ,

The real joy of consulting

 Aside  No Responses »
Nov 162010
 

Consulting isn’t the glamour job that a lot of people think it is. Sure, you may get to travel and learn new things, but as anyone who travels a lot will tell you, it can be a bit wearing after a while, and you find yourself suddenly hankering for the most basic of simple meals after weeks at a time of hotel or restaurant food.

Nor do you do consulting for the fame. Sure, good consultants will get reputations in their fields, but we’re hardly household names (except maybe in particularly niche/geeky households). Undoubtedly I think the best consultants start with a passion for their field and a desire to learn as much as possible, but this will only get you so far. There needs to be something else to prevent burn out and to allow for personal growth.

I’ve been extraordinarily lucky to develop and keep long term customer relationships, carrying customers between my last company (which collapsed) and my current company, and equally having customers carry those relationships with me from one company to the next. At one level, they remain customers – but at another, as you’ve been working with certain customers year in, year out, you realise that the true value of consulting is the people you’re doing the consulting for. It’s not about being able to solve problems and challenges for companies that you deal with, it’s about being able to solve problems and challenges for the individual people you deal with. The first just pays the bills; the second one is what gives you the job satisfaction.

In the past couple of weeks I’ve had a few people I’ve been working with for years advise me that they’re moving on to other endeavours. It’s always at this time that I pause to think about the core reason I do this job: to help people.

 Posted by at 06:39  Tagged with: , ,

There is no magic bullet

 Architecture, Backup theory, General Technology  2 Responses »
Apr 092010
 

The always astute Martin Glassborow has an article on his blog titled “This Changes Everything … Honest!” In it, Martin bemoans vendors who push technologies as miraculous solutions – the notion that if you’ve got a problem, all you need to do is buy a widget and bingo! the problem is gone. The meat of Martin’s argument is as follows:

Actually if you try to do this without a huge technology change; you may reap more benefits. The problem with large technology changes is that you often fail to do anything with the legacy tail; you simply deploy new stuff onto the new technology. The legacy just sits and moulders, costing money to maintain and manage. Of course you could simply just decide not to maintain the legacy, which will save you money in the short-term but when it breaks, you could find yourself spend even more money trying to fix a system which no-one really understands. If you try to change the process before rolling in the new technology, you will probably stand a greater chance of dealing with the legacy tail.

So don’t expect miracles from a change in technology!

Without process change, technology changes are probably just cost!

People Trump Processes Trump Technology

It’s the final sentence that I find most important in this – “People Trump Processes Trump Technology”; i.e., people trump processes, and processes trump technology.

It’s like rock, paper, scissors, but with a trump card.

In my book, I spend an entire chapter talking about the human and technical layers within a backup solution, and so Martin’s argument struck very true with me: it doesn’t matter how excellent the purchased technology is – if you don’t have people and processes established to integrate with the technology in a synergistic function, you won’t get anywhere.

Or to put it another way, there is no silver bullet. There’s no one piece of technology that you can deploy which will magically solve your issues if you can’t integrate it properly within your operating processes. In fact, I’d suggest that technology at most only ever forms 40% of the total solution – and that’s an absolute maximum percentage. The rest comes from people, and processes.

This is why so many large scale technology purchases fail to actually achieve anything within organisations. Companies that pursue an aggressive technology change strategy without addressing core issues – personnel and processes – repeatedly fail to achieve anything, and lurch from one silver bullet to the next, cursing each failed solution. This isn’t always their fault – it’s easy to believe a slick salesperson who suggests that their technology will resolve all your issues when you’re reluctant to face those core concerns.

If you want to take some honest advice from someone who has worked in the systems integration space for a decade, consider this: there are no silver bullets. You can’t solve a problem just by buying a specific piece of technology, and anyone trying to tell you this is either lying or misguided. Instead, if someone is pitching a piece of technology, or a suite of technologies, as able to solve your problems, and they don’t understand your business, they can’t be believed.

The important question is: do you understand your business? You need to – you have to, in order to understand what part people and processes need to play in solving any issue you’re currently having. Remember: they’re 60% of the solution. The technology is certainly the easy part of the solution, but it’s not a silver bullet.

 Posted by at 21:49  Tagged with: , , ,
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha