“We have backups” is one of the most misleading phrases in IT. It sounds reassuring, but it says nothing about the question that really matters: when the time comes, can you actually restore effectively and in a timely manner?
Most organizations affected by data loss actually had a backup solution in place. The problem is rarely the absence of backups, but rather three classic failure scenarios that occur time and again, in virtually every sector.
Three recurring scenarios
1. The backup exists, but has never been tested
A backup job reported as “successful” does not mean the data is actually recoverable. Configuration errors, incomplete backup sets, corrupted files, or forgotten applications (such as a database that falls just outside the backup schedule) often go unnoticed until the moment of restore. A backup that has never been tested is an assumption in practice, not a guarantee.
2. The restore takes much longer than expected
Even when a backup is technically sound, the recovery process in practice is often slower than anticipated. Network bandwidth, the order in which systems must be restored (for example, an application that depends on a database server that is not yet online), and the lack of a documented recovery plan mean that an estimated recovery time of a few hours can take a full workday or longer in reality.
Recent research by Veeam shows that the average recovery time after a ransomware attack is more than three weeks, and that barely one in ten affected organizations can effectively recover more than 90% of their data.
3. The backup itself is infected or encrypted
Modern ransomware attacks are not aimed at production data alone. Attackers deliberately target backup infrastructure to prevent the victim from recovering without paying a ransom.
The same Veeam research shows that in 89% of organizations that suffered a ransomware attack, the attackers also actively attempted to compromise the backup environment. Yet, only a minority of organizations use immutable storage to structurally eliminate that risk.
The 3-2-1-1-0 rule as a practical answer
There is no magic bullet for these three scenarios, but there is a proven architectural rule of thumb that structurally limits the risks: the 3-2-1-1-0 rule.
- 3 copies of your data: the production data plus at least two backup copies.
- 2 different types of storage media: for example, local disk storage and cloud or object storage, so that one type of storage error doesn't affect all your copies simultaneously.
- 1 offsite copy: physically separated from your production environment, so that a local incident
- (fire, theft, a complete site failure) doesn't destroy your backups as well.
- 1 offline or immutable copy: inaccessible or unalterable to an attacker who has access to your production environment, even with administrator privileges.
- 0 errors: regular, documented, and verified restore tests. Not just a green checkmark in a dashboard.
These last two elements are the primary evolution compared to the classic 3-2-1 rule, and they are precisely the elements most often missing in practice.
What does that mean in practice?
At Epact, depending on the environment, we combine Veeam Backup & Replication or Veeam Data Cloud with immutable object storage (including via Wasabi, with Object Lock functionality) for the offsite and immutable copy.
This means that once a backup is written, it cannot be modified or deleted by anyone during the set retention period, not even by an attacker who has gained full access to your production environment or even to the backup management itself.
Testing is a habit, not a one-time event
A restore test performed once a year, during a quiet moment, with a non-critical application, says little about how your environment will behave during an actual incident. A mature backup strategy includes periodic, documented restore tests on different types of workloads (file servers, databases, entire virtual machines), with corresponding measurement of the effective recovery time. Only then will you know if your RTO objective is truly achievable, rather than just a number on paper.
Conclusion: a backup that has never been tested is not a backup
The three failure scenarios in this chapter have one thing in common: they only become apparent at the moment you can least afford them. A backup strategy that structurally relies on multiple, separate, and immutable copies, combined with regular and documented restore tests, is the difference between an organization that survives an incident and one that takes weeks to get back on its feet, if it manages to recover at all.
This blog is part of a broader narrative on business continuity that we cover in full detail in our “Business Continuity Guide for CIOs and IT Managers.”