Almost any company will calmly tell you it "has backups". The problem is that attackers know this better than you do — and they count on it. According to Veeam's 2025 reports, backups are targeted directly in 96% of ransomware attacks, and in roughly 76% of cases attackers manage to compromise them. In other words, the first target is not your production data, it is the very safety net you rely on to get back up.
"Having backups" and "being able to recover within an acceptable time" are two completely different statements. The first is about storage. The second is about a recovery capability you have tested and trust. Between them stand the companies that, on the day of an incident, discover their copied files were encrypted too, or that a full restore takes three days instead of three hours.
A backup you have never tested is just hope
The data on real recovery is unforgiving. Of the organizations hit by ransomware, only about 10% managed to recover more than 90% of their data, while 57% recovered less than half (Veeam, 2025). A 2026 report confirms the pattern: only 28% of victims fully recovered their affected data, and 44% stayed below the 75% mark. These are not companies without any backup — these are companies that "had backups".
And even when data is recoverable, time kills you. A 2026 study shows 60% of IT leaders need six hours or more for a full restore, and only 5% can do it in under an hour. For a company that invoices, produces or delivers every day, the difference between three hours and three days of downtime is not a technical detail — it is the difference between an incident and an existential crisis.
Why do backups fail exactly when you need them most? Usually for a few recurring reasons:
- The backup is permanently connected to the same network — so it gets encrypted along with everything else, in the same attack.
- It has never been tested with a real restore — nobody knows whether the archive even opens until the day it matters.
- The restore "works", but the applications will not start: missing permissions, dependencies, service start-up order.
- No one has decided, in numbers, how much data the company can afford to lose and how long it can be down — so there is no target to measure success against.
Cloud sync is not a backup
There is a costly confusion, very common in small companies: sync is not backup. OneDrive, Google Drive or Dropbox keep files up to date across all devices — but that is exactly why they also propagate the encryption. When ransomware encrypts your files locally, the "safe" cloud version is overwritten with the encrypted one within seconds. A sync service without versioning and without a separate immutable copy does not save you from an attack, it just replicates it faster across every connected device.
The reason it is worth the effort is simple: the cost of downtime. For a company that depends on its systems to invoice, produce or deliver, every hour of standstill means delayed orders, people paid for nothing and lost trust. A cheap backup that does not work does not save money — it just postpones and amplifies the bill.
From 3-2-1 to 3-2-1-0: what the final zero changes
The classic 3-2-1 rule remains the right foundation: 3 copies of the data, on 2 different media types, with 1 copy off-site. For years it was enough. In the ransomware era it no longer is — because it assumes an "off-site" copy is automatically safe, which is no longer true when attackers actively hunt for backups.
That is where the 3-2-1-0 extension (and the 3-2-1-1-0 variant) comes from. The added digits are not marketing, they are exactly the gap most companies fall through today:
- 1An extra "1" — an immutable or air-gapped copy: a copy that cannot be modified or deleted, not even with compromised admin credentials. It is the only one that survives an attack that has taken over the network.
- 2A "0" — zero recovery errors: every backup is verified, and the restore is tested periodically until the error count is zero. An untested backup is not protection, it is an assumption.
The figure that should worry you: although 89% of organizations report that attackers targeted their backups, only 32% actually use an immutable repository (Veeam, 2025). The rest understood the threat but did not close the door. This is where recovery is won or lost — not in the backup software, but in the architecture around it.
A backup you have never restored is not a safety copy — it is a promise you never verified. Ransomware verifies it for you, on exactly the day you cannot afford to find out.
RPO and RTO: the two numbers you decide before any tool
The most common implementation mistake is to start with "which backup software do I buy?". The correct order is the reverse. Before any tool, the company must answer two business questions, in concrete numbers:
- RPO (Recovery Point Objective) — how much data can you afford to lose, measured in time? An hour of work? A full day? The answer sets how often the backup runs.
- RTO (Recovery Time Objective) — how long can the company be down before recovery becomes unacceptably expensive? The answer sets what kind of restore infrastructure you need.
A recovery target you have never tested is simply a guess. These two numbers, decided together with management and not just with "the IT person", turn backup from a vague technical expense into a business-continuity decision. Without them, any implementation is over- or under-sized — you pay too much for data that does not matter, or too little for the data the company depends on.
An example makes it concrete. If the agreed RPO is one hour, a daily backup is not a solution: an incident at 5 p.m. would cost you the whole day of work. If the RTO is four hours, a restore that pulls terabytes over the internet from a distant cloud does not fit — you also need a fast local copy alongside the off-site one. The two numbers are not bureaucracy; they directly dictate the architecture, the frequency and the budget of the whole solution.
What an implementation that actually protects you looks like
A serious implementation is not "install a program and tick the backup box". It is a small project with clear steps, where each stage closes one of the gaps above. This is how we structure a 3-2-1-0 backup strategy implementation:
- 1RPO/RTO workshop with management: for each critical system, we set how much data can be lost and how much downtime is acceptable. This is where the real objectives are born.
- 23-2-1-0 design: we design the 3 copies across 2 media, with an off-site copy and, crucially, an immutable copy ransomware cannot touch.
- 3Configuration (Veeam Backup & Replication + QNAP storage): we actually deploy the solution, with retention, encryption and immutability enabled — not just "on", but configured for the attack scenario.
- 4Real restore test: we actually restore data and applications in a controlled environment, to prove they open, start and work — and that we meet the promised RTO.
- 5Runbooks + training for the local administrator: we document, step by step, who does what on the day of an incident, so recovery does not depend on a single person or on luck.
The last step is the one most companies skip — and exactly the one that makes the difference. A backup is tested on a rhythm, not once at install time. The practical cadence we recommend:
- Monthly: a file restore, as a routine check that archives open.
- Quarterly: an application-level restore, dependencies and permissions included.
- Annually: a full failover exercise of the critical environment, timed against the RTO.
A few pitfalls we see often and that a good implementation closes from the start: retention too short (you discover the infection only after the single clean copy has expired), immutability "on paper" but not actually set on the storage, a single person who knows how to run the restore, and no fully disconnected copy for the most critical systems. Each one turns a backup that "exists" into one that does not help you on exactly the day it matters.
The good news is that maturity pays off: companies that test and keep immutable copies recover visibly faster — the share of those fully recovering within one week rose from 35% to 53% in a single year. It is not magic, it is method. If you want to see how that translates for your setup, we start from your IT infrastructure architecture and the systems that are not allowed to go down.
Conclusion
Backup is not a box you tick, it is a recovery capability you prove. The difference between "I have a backup" and "I brought my company back in two hours" is made by exactly those two zeros: an immutable copy and a real restore test, against consciously chosen RPO/RTO objectives. If you are not sure your backup would pass a real test today, let us talk for 30 minutes — I will tell you concretely where you are exposed and where to start.