Disaster recovery: why an untested backup won't save you

"We have backups." Two words that reassure any manager — and that, on the day of a real incident, often turn out to be the most expensive illusion in the company. Because between having a backup and being able to recover from it lies a gap most companies discover at the worst possible moment: when they need the data and it does not come back.

A backup that has not been tested is not a safety net. It is an assumption. And in 2026 that assumption has become dangerously expensive, because attackers have learned exactly where to strike: not just the production data, but the backup copies that are supposed to save you.

Backup is not recovery

A backup is a copy of data. Disaster recovery is the ability to bring the business back to operation — on time, completely, with clear processes. They are two different things, and having the first guarantees nothing about the second.

You can have perfect copies of your data and still be down for two weeks: because nobody ever measured how long a full restore takes, because the backup sits on the very server ransomware encrypted, because there is no written procedure and under pressure everyone improvises, or because the last "it worked" check was a year ago and the job has been failing silently every night since. The backup is the raw material. Disaster recovery is the recipe, the kitchen and the cook who can get it on the table within the promised time.

What the 2025–2026 data shows

The figures from the past year tell a clear story: the problem is no longer that companies lack backups, but that actual recovery is far harder than it looks.

• Nearly 9 in 10 breaches at small companies involve ransomware, compared with roughly 4 in 10 at large corporations — SMBs are the preferred target, not an exception.
• On average, a company hit by ransomware needs about 24 days to return to normal operation. For many SMBs, three weeks of standstill is fatal.
• Only about half of victims recover in under a week; a significant share need more than a month, and very few recover within a single day.
• In the vast majority of ransomware attacks, attackers target the backup copies directly — and succeed in compromising them in over three-quarters of cases. Backup is no longer a safe corner; it is a target.
• Companies that manage to restore from intact backups spend, on average, several times less on recovery than those with compromised backups — the difference is measured in hundreds of thousands of euros.
• And yet, a large share of recovery plans are tested rarely or never — many companies have never verified whether their plan actually works.

The conclusion reads between the lines: the companies that recover quickly and cheaply are not the ones with the most expensive backup software, but the ones that tested their recovery before the disaster. The rest pay the bill — in lost days, in money and, in the worst case, with the very existence of the business.

RTO and RPO: two business decisions, not technical ones

Any serious disaster recovery plan starts from two numbers. They are not decided by a technician but by management — because they are, at their core, decisions about how much risk the business can afford.

RPO — how much data you can afford to lose

Recovery Point Objective is the maximum window of data you accept losing. If you back up once a day, an incident can cost you up to 24 hours of work. For accounting records, that may be acceptable. For an online shop or a transactional system, one lost hour can mean vanished orders and money. RPO tells you how often you must take copies.

RTO — how fast you must be back

Recovery Time Objective is the maximum acceptable time until the system is functional again. An 8-hour RTO and a 15-minute one demand completely different architectures — and different costs. The trick is not to demand "instant recovery" everywhere, but to correctly identify which systems are critical (those that stop the business) and which can wait. You invest in the critical ones; on the rest, you save.

Without these two numbers, "we have backups" is an empty phrase. With them, the design becomes a rational decision: you know exactly how often you copy and how fast you must restore — and you can verify whether you actually succeed.

Why backups fail exactly when you need them

Recoveries rarely fail for a single spectacular reason. Most often the cause is one of these — mundane, but fatal:

1. 1The backup was never tested. The job "runs", but nobody ever attempted a full restore. The first time you do should not be in the middle of the crisis.
2. 2The backup sits next to production. A copy on the same server or network as production data gets encrypted by the same ransomware. Without an off-site, immutable copy, you do not have a backup — you have two victims.
3. 3RPO/RTO are missing. Nobody decided how much is acceptable to lose, so nobody can say whether the current backup is enough or whether recovery is "on time".
4. 4There is no runbook. In the first hour of an incident, under stress, people improvise. Without a written procedure — who, what, in what order — precious hours are lost on decisions that should have been made in advance.
5. 5Retention does not cover the real scenario. Some attacks lie hidden for days or weeks before striking. If you keep only the last few days of copies, you risk restoring already-compromised data.
6. 6Monitoring is missing. A backup job failing silently for months only reveals the problem at the first restore — that is, too late.

What a disaster recovery plan that actually works looks like

An operational plan — not a shelf one — has a few clear ingredients:

• RPO and RTO defined per system, agreed with management — not a single number for everything.
• The 3-2-1-0 strategy: three copies of data, on two different media, one off-site, with zero errors on verification. At least one immutable copy that ransomware cannot delete or encrypt.
• Periodic restore testing — monthly for critical systems, quarterly for the rest — measuring real times and comparing them to the target RTO.
• Written runbooks: who triggers recovery, in what order systems are restored, how it is communicated, when it is escalated.
• For systems with a low RTO, a cloud secondary site and continuous replication (Disaster Recovery as a Service) with failover drills.
• Retention and archiving policies aligned with GDPR requirements — keep what you must, automatically delete what has expired, with a full audit trail.

A backup you have never restored is not a backup — it is a promise you never verified. The only question that matters is: how long does it actually take to come back?

How we work

In our data protection projects we start with a business impact analysis workshop, defining RPO and RTO with you for each system. We then design the 3-2-1-0 strategy with an immutable copy, configure backup, monitoring and alerting, and — most importantly — test the restore on a clear schedule, documenting real times until we hit the target RTO. For systems that cannot tolerate downtime, we add cloud replication and tested failover runbooks. Because ransomware is today the main threat to data, the recovery plan goes hand in hand with cybersecurity measures. If you want to find out how long a full recovery actually takes in your company, let us talk for 30 minutes — I will tell you concretely where you are exposed.

Conclusion

The 2025-2026 data is unequivocal: the difference between a company that survives an incident and one the incident shuts down is not the backup software, but tested recovery. Backup is mandatory but insufficient. Disaster recovery — with defined RTO and RPO, immutable copies, runbooks and periodic tests — is what turns a copy of your data into a real guarantee that your business survives. Do not let the first restore be in the middle of the crisis.