SMBs? Are you big enough to have a serious backup strategy?

One of the TLAs* we come across all the time in IT is CIA. It's not, in this context, a shady American intelligence force: as far as we're concerned it stands for Confidentiality, Integrity and Availability – the three strands you need to consider as part of your security and data management policies and processes.

Most organisations tend to focus on confidentiality. And that's understandable because a guaranteed way for your company to become super-famous is for confidential data to be made publicly available and for the Press to find out - just ask TalkTalk. On the other hand, site outages will often make the news (particularly if you're a prominent company like DropBox or Microsoft) but they're generally forgotten the moment that the owner puts out a convincing statement saying that their data centre fell into a sinkhole or they were the subject of a type of DDoS attack never previously seen – as long as that statement says: “... and there was never any risk of private data being exposed”.

Internally, though, you care about the integrity and availability of your data. By definition, the data you process needs to be available and correct – otherwise you wouldn't need it to do your company's work. And guaranteeing this is a pain in the butt – for companies of all sizes.

Actually, for the small business it's kind of refreshing that even the big names have to work hard to preserve data integrity and availability – it shows that you're not alone. As a small company, though, your problems are generally different from those of the big boys. Their issues revolve around time and storage (a vast data set means they need a vast repository, and the time it takes to back stuff up is directly proportional to the data size). Your problems, however, are more around the skills you need to define a backup and archiving strategy, the cost of the backup kit, and the people-time you have to find to configure and verify backups and deal with file restores.

What do I need to back up?

Step one is to understand what you need to back up. Sounds daft, because people generally say: “Everything”, but in my experience that's sometimes not the case. Yes, you'll probably need to back up your data but if, say, you're running a fleet of identical Web servers as virtual machines behind a load balancer it'll often be simpler just to dump a corrupted server and clone a fresh one than it would be to restore from a backup.

What about replicated servers?

Sometimes you'll run a replicated world – perhaps you have a two-server replicated MySQL database back-ending a CRM system, for example. And you'll think to yourself: “I don't need to back that up, because if the master dies I still have the slave.

You'll think that right up to the point where someone inadvertently executes a malformed UPDATE or DELETE statement … because this will instantly happen on the slave as well as on the master. And don't think it won't happen, because it does. A colleague once thanked the Almighty that his MySQL replication had failed, because a DROP DATABASE command hadn't made it to the secondary site so the data was still there. So yes, you do need to back those up.

How long do I keep it?

Do you keep your backups forever? If so, you're probably doing it wrong. First of all, most stuff becomes obsolete over time. While information about your customers from 15 years ago may be of academic interest, it'll often have no business value any more and so you should reclaim the storage space it occupies. Secondly, in these days of Freedom of Information laws, you need to be mindful that one day someone may come digging and demand legacy information from you. The dusty skeletons in your data closet may well not exist through any malicious or Machiavellian intent on your part, but you should have a policy of chucking them out regularly anyway.

A strategy

All of this is leading us in a fairly clear direction: that of a data integrity strategy. And even if you're a relatively small organisation you need one, because you rely on your data to keep your company in business. After all, I'm the smallest possible organisation (I'm just one person) and I have a data integrity strategy that proved invaluable when my Mac hard drive died the other week and caused precisely zero data loss. Here's a start, then.

What do I want restoration to look like?

To decide what your backup strategy should be, start with what you want to happen when you need to restore a data item. Sounds a bit odd, but stick with me. List your data items and the applications you use to manipulate them, and consider what you want to happen in the event that something breaks. How long can you live without the data item? Can you restore an individual item on its own or do you (for instance) have to restore an entire MySQL or SQL Server database to get the data back on-line? Do you want users to be able to restore data themselves, or will the IT department do it for them? Are you OK to restore back to last night's backup, or do you need the saved item to be more recent?

Most backup packages back stuff up in similar ways, but in fact it's restoration that counts. So make this the first building block of the strategy.