7 Contentious Thoughts about Data Protection

Years ago, back in the days when TV shows would take months, if not years, to appear in Australia after first airing in the United States, I followed a Star Trek Voyager fan-page that would give a blow-by-blow account of each episode after it aired. I know, I know:

I think I got my enjoyment of reading spoilers from that Voyager fan-page. Now, this blog post isn’t about Star Trek Voyager or spoilers, but about a saying that I first read on that fan-page. Something along the lines of, “…Janeway came to chew gum and kick ass, and she’s all out of gum…”

So this is a bit of a blog post where I came to chew gum and tell some home-truths, and I’m all out of gum. So buckle up.

Cloud is only cheaper if you don’t think about data protection

I get it, lots of people like the cloud. Hell, I like Cloud these days myself. I live a digital life – I buy electronic books, I listen to electronic music, my photos are all taken on a smartphone and all of this, I know, comes from and goes to the cloud.

But I’ve also been working in data protection for almost 25 years, and if that’s taught me anything, it’s this:

If a system looks too cheap to be true, someone probably forgot about backup.

There may be exceptions to the rule, but it’s my experience that once you start talking about comprehensive data protection, the “cheapness” of public cloud drops away. Of course, there can be advantages to the public cloud: pay-as-you-go, convenience and for many businesses, access to IT infrastructure and services they might find too challenging to run on-premises themselves. Those are all strengths of the public cloud experience.

But if you’re talking cheaper than on-premises, it probably means you need a data protection architect to help you review your processes.

You’re not protecting enough data

OK, I’ll admit that when it comes to data protection, I’m a slightly paranoid person: I’m not fond of the idea of losing data. But something I hear regularly is we-don’t-back-that-up, usually regarding secondary servers, storage or systems.

Invariably that’s a cost decision, and I get it. But my recommendation always remains: if you’re not-backing-that-up and it takes you more than 15 minutes to fully recreate or repopulate a system from scratch, you should have been protecting it. And I’ll continue this line of thought in my next point.

You’re protecting data too much

Note that I didn’t say you’re protecting too much data. That’s not my point, but yes, it goes hand-in-hand with my previous statement that you’re not protecting enough data.

Because here’s the thing: if you’re not planning data protection properly, you’re spending too much money (comparatively) on keeping too many compliance copies of your backups at the expense of not providing sufficient operational recovery to your business.

Now, I know some say you should never keep any compliance copies (i.e., long term retention) within backup and recovery systems. They’re archive purists, and I love them and their commitment to the ideal. Still, I also think given the sheer number of platforms we need to use in IT it’s a perpetual pipe-dream – because once you’re beyond standard files, every application requires a specific approach to archive. (To be fair, that means: ‘file serving’ is an application as well – so every application ends up needing a specific archiving strategy).

Rightly or wrongly, we need to keep compliance copies – long term retention – within our backup and recovery services. But do you really need to keep all those copies?

For many businesses, I find the IT teams and business in general always reluctant to engage with legal counsel because of the apparent cost thereof. But this just has a flow-on effect. Rather than finding out what level of compliance retention would be required, knee-jerk reactions are often made to keep copies forever or keep too many copies for too long.

So your business has a requirement to retain certain backups for 7 years: are you sure – are you legally sure that you actually need to keep monthlies for 7 years? Who asked, and who legally confirmed that this is required? Who legally confirmed you can’t just keep half-yearly backups taken at strategic times for 7 years? (For many Australian businesses, for instance, this would be the last monthly backup of the calendar year and the last monthly backup of the financial year.)

It becomes a numbers game: if you’re starting at 500 TB of “compliance” backups in month 1 with a 10% per annum growth and keeping monthly backups for 7 years (84 months), you’ll be keeping almost 60 PB in logical copies of compliance backups over that period. Even when you apply deduplication – good deduplication – that’s still going to add up. Are you sure that’s still cheaper than getting legal counsel to review the requirements?

And every dollar you save from keeping fewer long term retention backups you can plough back into offering more advanced operational recovery for the business. It’s a win/win.

Backup is Dead

Backup is dead. There’s no doubt about it.

It should come as no surprise to anyone who’s read Data Protection that I said backup is dead. I’ve been saying it for some time, and it’s actually the opening line on the back cover of the book. But, and there’s always a but…

Backup is still Very Much Alive

Why yes, I do like to be deliberately contradictory.

No, backup isn’t some shambolic zombie that chews through system resources. (That’s Adobe Acrobat Reader if you must know.)

The point I made in Data Protection, and that I continue to make at every opportunity, is backup as a standalone topic is dead. Where once ‘backup’ might have been the primary intent of ‘data protection’, it’s not any more. Just as your business will not survive if it’s only using on-platform protection methods, it’s not going to survive if it’s only using off-platform protection (i.e., backup). Both are needed in a modern environment.

Ransomware Snuffed Out Multi-Purpose Backup Servers

I’m using multi-purpose here to refer to a backup server running on a conventionally accessible operating system. I’ve been dealing with these sorts of backup servers for as long as I’ve been in data protection, and it’s time they’re put out to pasture.

It’s too easy for these conventional servers to be rolled by ransomware. Backup administrators logging on as the OS administrative user to maintain the system represent a huge attack vector for malicious binaries and actors.

So, every time you deploy a backup server in your environment, you should be asking, “Can I deploy this as an appliance?” That doesn’t necessarily have to mean a full-stack appliance (converged, or hyper-converged), but it does mean the backup server can be deployed as a functional appliance where you can administer the backups without having to be a system administrator. (Avamar obviously has done this for most of its life, NetWorker had the NetWorker Virtual Edition appliance released a few years ago, and PowerProtect likewise gets deployed as a virtual appliance.)

If your business is focused on reducing the risk of malware affecting critical systems, deploying your backup services on say, a conventionally accessible Windows install these days is just asking for trouble.

You’ve Probably Got The Wrong People Running Data Protection

When I joined my first system administration team, I was told, “We just installed this new backup software, you’ll administer it”. That was 1996, and the product was Solstice Backup, the Sun OEM version of Legato NetWorker. Therein started my love of NetWorker.

But here’s the rub: the team made a bad mistake. Yes, I’m grateful for it because it set me on a career path, but they shouldn’t have done it. If data is the new oil, as the saying goes, then you don’t put the protection of your data in the hands of the juniors – certainly not without senior supervision.

I genuinely believe that if a business is serious about data protection, it’ll have some of its most senior staff responsible for it. These are the veterans of the IT department who know systems inside and out, and who really are ultra-careful when it comes to systems functions – because if you get data protection wrong (whether it’s on-platform or off-platform), the business can suffer disastrous consequences.

So what do you think?

So that’s what I think, anyway. What about you? What do you think people get wrong about Data Protection? Feel free to leave a comment!