Backup is Insurance

As evidenced by the title of my book (Enterprise Systems Backup and Recovery: A corporate insurance policy), I’m a firm believer that the only way to conceptualise the purpose of backup is to describe it as insurance. The way I describe this is to compare the way in which we take out insurance, but hope not to use it, and to make backups, and similarly hope not to use them. This can be easiest described through a couple of Venn diagrams.

First, let’s look at insurance:

Backup and Insurance: Insurance Venn DiagramNo-one wants to claim on their insurance. We take it out on a yearly basis, and any year that we don’t have to use it is good. (Particularly in countries where insurance companies run rough-shod over morality, decency and legal restraint.) I personally have home insurance, contents insurance, car insurance, travel insurance (whenever I travel) and health insurance. Any time I don’t have to make a claim on any of these types of insurance is good – because in order to make a claim, something bad needs to have happened. So I’m much happier paying the fees each year and hoping that I don’t have any more involvement than that with my insurance agencies. Do I resent paying these fees? Hell no – because I’m well aware that if I don’t, and something bad happens, I’ll be up the creek without a paddle. (Or to use the Australian vernacular, I’d be up s––t creek.)

So let’s see the Venn diagram for backup:

Venn Diagram for BackupAs you can see, it’s spookily similar to the diagram for insurance. Now, one of the first things that I tend to hear when I roll out my “backup = insurance” argument is that occasionally, people will want to recover from backups – e.g., to migrate between systems, refresh Q/A systems from production, etc. Well, this isn’t really using backup for the primary purpose – recovery, but instead using it as a data migration/retrieval system. It’s a fine distinction, but it’s an important distinction. The primary reason backup systems are deployed is to recover data when there’s been a failure – any secondary benefit from a backup and recovery system is just that – a secondary benefit.

Your next question may be – so what point is there in classifying backup as a type of insurance?

This is the absolute core of why companies need to think of backup as being a type of insurance – it’s all about the budget.

Look at an example company. Let’s say there’s 5 departments:

  • IT
  • Finance and Human Resources
  • Sales
  • Warehousing and Operations
  • Solutions Delivery

In a standard company, each department will have it’s own budget, but there’s also the corporate budget. That’s the budget that covers costs which affect all departments and have to be met regardless of the size or capacity of each department – it’s for the core business costs. One of those “core” costs is usually the various insurance policies that companies take out. This will definitely include some sort of standard business insurance, but will then cover other types of insurance – professional indemnity, building insurance, contents insurance, car insurance, etc. Few businesses would argue that each department needs to individually seek out and/or pay for its own insurance on each of those matters.

The mistake then made by many businesses is to fail to think of backup as insurance, and therefore work on the basis that IT will manage data and systems backup out of its own budget. This sort of thinking leads to the most common disasters where:

  • Backup systems budget is cut to meet the budget requirements of “production” systems. (See my points here about why it’s a fallacy to think of backup systems as anything other than production systems.)
  • “Make do” data protection systems are deployed that require significant time to complete recovery – e.g., to “save” money, some IT departments will decide to only backup actual data, and leave operating systems and applications at the mercy of being re-installed from the ground up.
  • Backup retention is cut to reduce operational expenditure (i.e., limit the purchase of new media).
  • SLAs, if established, are silently ignored – or even railed against by IT.

None of these processes or decisions are conducive to sensible or useful business systems management – yet they’re the inevitable consequence of asking one department to meet costs that are shared between all departments. It would be like demanding that the sales department pay for all company insurance out of their budget: it just doesn’t make sense.

Where does this discussion leave us? There’s a lesson any business can take out of this: backup, being insurance, is something that’s funded by the corporate operational and capital budget, not the budgets of any individual department.

Chances are if your business isn’t thinking of backup as insurance, it’s not handling or funding backup properly either.

3 thoughts on “Backup is Insurance”

  1. Hi Preston,

    Can you help me understand the following statement from this post?

    ““Make do” data protection systems are deployed that require significant time to complete recovery – e.g., to “save” money, some IT departments will decide to only backup actual data, and leave operating systems and applications at the mercy of being re-installed from the ground up.”

    I’m actually thinking of recommending a model in our I.T. department whereby we don’t back up individual hosts, and that instead centralized data is backed up, and O.S. data is left alone. I was under the impression that it should be faster to rebuild a generic host than it is to restore it from tape (tape especially, I suppose, as opposed to disk). This obviously requires that the O.S. teams buy into this philosophy and build hosts in such a way that application data, and any other critical data sets, are kept on redundant, performing centralized storage and not on local hosts.

    What problems do you see with this model? It obviously carries assumptions, but I think it would reduce complexity.

    Thanks for the post and the thought!

    -Dave

  2. Hi Dave,

    I’d certainly not recommend the model that you’re proposing. The simple rule of thumb I always recommend is that if an untrained administrator, without any exposure to your systems and environments can’t complete patching and customisation of settings to allow an operating system (and applications) to return to their previous functioning, then you should definitely be backing it up.

    If you can achieve total systems restoration and re-integration faster than that (e.g., through virtual machine templates, system imaging, Jumpstart builds, etc., then you can probably justify changes to the above. But until that point, you’re usually just asking for a disaster if you don’t backup the operating system and applications.

    Even if you move to a system of say, fully SAN booting environments, then you still need to factor in data loss or data corruption. A SAN will typically protect you from, say, disk failure, but that doesn’t protect from a virus, or patch gone wrong, or a user clicking “yes” instead of “no” to a “Delete everything?” prompt 🙂 Throw in suitably high levels of automatic snapshotting and you might have appropriate alternatives – but then you have to ask yourself: how much space and time are you saving vs the cost of the alternatives? If we consider a 50GB system for instance, the OS and applications are likely to only represent say, 5-10GB of that space at most on most systems. If you’re deploying new environments, or justifying significant expansions to avoid backing up those much smaller components, it’s often quite a hard cost justification perspective.

    Cheers,

    Preston.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.