OK, it’s been a little while since I did a meme Monday, and there are s a few ones I want to cover off today. So let’s get cracking!
Listen, I get that people in procurement, in particular, want to be able to draw a line in the sand and say, “We spent X on this, we won’t need to spend any more for 5 years.”
But that’s not how data protection works. That’s not because we’re always looking to spend more money – if anything, most people I know who work in data protection are always actively looking for ways to save money.
In movies, the butterfly effect is arguably one of the most broadly used memes from maths, but if you want to see the butterfly effect in motion, track a backup system over 5 years. Or to jump across to quantum physics: you can predict where your business needs to be in 5 years time, but you can’t predict exactly what form its IT infrastructure will be in to meet that goal. And that’s not a jab at the cloud – I’m not talking about being able to say “we’ll be all-in on the Cloud in 5 years time”. Pfft, anyone can say that. I’m talking about being able to say exactly what the type and size of every one of your workloads are going to be in 5 years time.
Never. Going. To. Happen.
So, remember that there are better questions to ask than “give me sufficient capacity for 5 years”, such as:
- How do you scale?
- Can you give me enough capacity for 2 years but headroom to scale for 5 {at X% YoY growth} without having to do a forklift upgrade?
- Can you provide an estimate of cloud resource usage requirements for {this sample workload with this growth} over a 3 year period?
- Can you provide a mechanism for me to move licensing and software between DCs and Cloud, and between appliances within DCs?
- Can you help me scale on demand?
Here’s my honest advice to people:
- You can predict, with a reasonable degree of accuracy, what and how much you’ll be backing up within a year
- You can predict, with at most 50% accuracy, what and how much you’ll be backing up within 3 years
- Beyond 3 years, your predictions are pure guesses.
Look, online, disk-based backups are awesome at making the entire data protection process smoother. That’s why it’s increasingly rare to see tape used, particularly as the initial backup target, within a data protection system.
Backing up to disk-based storage is great. But, if you pick a backup product that’s going to write backups to the D:\ drive or E:\ drive or /backups mount-point, you’re giving ransomware a head-start in your business. I’m not joking when I say that the Boost protocol is one of your best fundamental defences against ransomware. Because Data Domain Boost backups don’t expose the protection storage to the accessing operating system (server or client), ransomware can’t just hop onto a system and encrypt all your backups.
Here’s something I’ve seen saying for more than 20 years now:
Your backup systems touch more in your IT environment than anything else other than the network itself.
It always surprises me when someone says, “I upgraded X and now my backups don’t work”. My first thoughts are:
- Did you read the release notes?
- Did you check the compatibility guide?
In a broad infrastructure, backups touch everything. That means every change request, every upgrade, should have mandatory checks in your business for “can we still back this up?” and “will this change break our backups?”
The first question is the singular system protection: “we’re going to upgrade from Windows 2019 to Windows 2027”, “what does the compatibility guide say about support for Windows 2027?” Or “we’re switching from non-federated to federated databases, can we still back them up?”
The second question is the more complex – wanting to make sure that as a result of doing a change, your backup system is still going to work, or still work the same.
If there’s anything as a data protection expert you’re going to have bookmarked for easy access on your computer, it should be the release notes and compatibility guides.
And if you’re a change coordinator who hasn’t added checks for backup/data protection in every change request, you need to re-think how you handle changes in your organisation.
I’ve said this before, and I’ll say it again: your backup server is singularly the most promising attack vector for any malicious actor operating within your organisation. Why struggle to jump through reams of security on mission-critical production systems when there’s a backup server on the network with credentials of “administrator” and “password123” for access?
You want to use your backup server to save you when the chips are down. Given a chance, attackers will use it to inject vulnerabilities in your most mission-critical systems, to exfiltrate your data, and compromise your ability to recover from data destruction. It needs to be secured with the same level of paranoia as your most mission-critical systems.