“We do have backups.” It is the sentence we hear most often — and it is almost always true. The problem is that it answers the wrong question. The right question is a different one: if the systems don't start tomorrow morning, how long before the business is back at work? And on that one, those who “have backups” often discover they have no answer.
A copy is not a restart
A backup is an object: a copy of the data, somewhere. Restarting is a process: which hardware you restore onto, in what order you bring the services back up, who does it, with which credentials, following which document. Between the object and the process lies the difference between those who are back in hours and those who stay down for days — with departments calling, customers waiting and every decision taken on impulse.
This distinction has two precise names: data protection is protecting the data; business continuity and disaster recovery is ensuring the business keeps running. They are two different disciplines, and the second cannot be bought: it has to be designed.
RTO and RPO: the two questions to ask first
Every serious plan starts from two parameters, which are ultimately two simple questions:
- RTO (Recovery Time Objective): how long can you afford to stay down? Everything follows from this: an RTO of 4 hours and one of 2 days lead to completely different architectures — and costs;
- RPO (Recovery Point Objective): how much data can you afford to lose? The hours of work between the last usable copy and the moment of failure do not come back.
The point that changes the perspective: RTO and RPO are not defined “for the company”, they are defined per service. Email, the ERP and the historical archive are not worth the same — and treating them the same means spending too much where it is not needed and too little where it hurts.
Not all services are worth the same
The tool for deciding is called the Business Impact Analysis (BIA): the analysis that lines up the business processes, measures what happens if each one stops — lost revenue, obligations to third parties, reputational damage — and derives recovery priorities and objectives from there. It is the moment the plan stops being an IT document and becomes a business decision: which services come back first, in what order, and how much is worth investing in each one.
An untested backup is a hope
The day of the disaster is not the right time to find out whether the restore works.
Copies can be corrupted, incomplete, or simply slower to restore than anyone imagined. The only way to know is to test: periodic restore checks — sampled on individual systems and, at the right cadence, complete on critical services — timing the real durations and comparing them with the declared RTO. If the measured restore of the ERP takes 11 hours and the objective was 4, better to know on a quiet Tuesday than during the incident.
When the attacker goes straight for the backups
Today there is one more reason to take all this seriously: in modern ransomware attacks, the backup copies are not collateral damage — they are a primary target. Those who encrypt the data know that a business with intact backups does not pay: that is why they try to reach and destroy the copies first.
The countermeasures are well known and must be applied together: the 3-2-1 rule (three copies, on two different media, one of them off-site), at least one immutable or disconnected copy that no compromised credential can delete, and separation between the accounts that administer the systems and those that administer the backups. Alongside this sits the work of prevention and response: backup is the last line of defence, not the only one.
The value of someone watching
One last lesson from the field: backups fail silently. A job that stops, a storage volume that fills up, a new system never added to the policies — and the discovery always comes at the worst possible moment. The difference is made by daily oversight: someone who checks the outcomes, corrects the drift and keeps the policies aligned with how the business is shaped today.
It is the reason we deliver data protection as a managed service — with restore checks included and the NOC watching the jobs alongside the rest of the infrastructure. If instead you want to start from the right question — “how long before we're back?” — let's ask it together, with a Business Impact Analysis.
