A lot of organisations approach backups the wrong way round. They decide they need backups, they put backups in place, and nobody ever asks what those backups are meant to achieve.
You don’t start with a backup strategy. You start with two questions.
- How much data can this business afford to lose?
- How long can it afford to be down?
Answer those honestly and the strategy more or less writes itself. Skip them and you’ve got a backup regime that may or may not do what you need on the day you find out, which is the worst possible day to find out.
RPO and RTO, in plain terms
Your Recovery Point Objective is how much data you’re prepared to lose, measured in time. An RPO of fifteen minutes means fifteen minutes of data is an acceptable loss.
Your Recovery Time Objective is how long you have to get back to that point. You might have an RPO of fifteen minutes and an RTO of four hours: four hours to restore the environment to within fifteen minutes of where it was.
Those two numbers determine everything downstream. What backups you take, how often, in what form, and where they’re stored.
The bit that gets skipped
They also have to be checked against physical reality, and this is where I see plans fall over.
If you have a four terabyte database, how much of it changes? How long does a restore actually take? Not in theory, not according to the policy document, but measured. Because an RTO of four hours is a fiction if a restore of that database takes six.
I had a client who had to recover from backup and worked out, in the moment, that getting back to within five or ten minutes was going to take longer than the business could stand being down. So they made a decision: lose twenty-four hours of data, be operational sooner.
That was the right call for them. It would be a catastrophic call for a bank. There’s no universal answer here, only what your business can actually tolerate.
Where the money comes in
The tightest possible RPO and RTO always cost more, in infrastructure, testing and ongoing management. That’s not a reason to avoid them. It is a reason to be honest about what you need.
A small business might genuinely want everything a bank has. They can’t afford it, and in almost every case they don’t need it. Their data doesn’t change at the rate a bank’s does and the consequences of losing an hour are not the same consequences.
So you want a Ferrari, but you’ve got a Volkswagen budget. Fine. Let’s work out what you actually need to protect and build something proportionate to that.
Then test it
One last thing, and it’s the one most commonly skipped. A recovery plan you haven’t tested is a hypothesis.
Restore it somewhere. Time it. Do that on a schedule, because environments grow and the restore that took two hours last year may not this year. The moment you need the plan is not the moment to discover it no longer fits.
—
Warwick Rudd is a Microsoft Certified Master and Data Platform MVP, and the founder of SQL Masters Consulting. If you’d like help working out what your recovery requirements actually are: Backup, Recovery & Data Integrity.
Leave a Reply