Almost every company we ask about backups says it has them. Most often they follow the 3-2-1 rule, or at least “to an external drive and to the cloud”. That is a good start. But the incidents we have handled in recent years show the same picture again and again: the backups existed, and there was nothing to restore from.
The reason is simple. The 3-2-1 rule was born in a time when the main threat was a failed disk or a fire in the server room. Today the main threat is a person on the other side who, before encrypting your systems, first finds and destroys your backups. Three copies on two media do not protect you from that scenario if all three can be reached from the same network with the same credentials.
In this article we explain what the 3-2-1 rule really means, how ransomware reaches backups, what immutable and air-gapped copies change, and what this looks like in practice when we keep the backups ourselves.
What the 3-2-1 rule means and what it does not say
The rule is short:
- 3: keep at least three copies of your data: the original and two backups.
- 2: store them on at least two different media or systems, so that one failure cannot destroy both.
- 1: keep at least one copy in a different location, not in the same building.
It is still correct. If a server disk fails, you restore from the local copy. If there is a fire or a flood in the office, you restore from the remote one. In the companies we work with, the most common setup is a server, a NAS device in the same cabinet, and a copy in the cloud or with the IT provider.
The rule says nothing about two things. First, who can delete or modify the backups. Second, whether the backups can be reached from the same network where the original runs. And that is exactly where modern attacks happen.
How ransomware reaches your backups
A modern ransomware attack is not a single file that somebody opened by mistake. It is a process of several weeks carried out by people. A typical sequence in our experience looks like this:
- Initial access: a forged e-mail, a leaked password or unpatched VPN equipment.
- Reconnaissance: the attacker quietly looks at which servers exist, where the backups are kept and who has administrator rights.
- Privilege escalation: domain administrator or backup server access is obtained. Often it is the same administrator whose password works everywhere.
- Backup destruction: backup jobs are deleted, the NAS is formatted, and objects in cloud storage are deleted through the same account that was used to upload the backups.
- Encryption: only now is the ransomware itself launched, usually on a Friday evening or before a holiday.
Note the fourth step. A NAS on the same network, mounted as a network drive, is simply one more drive that the ransomware will encrypt. A cloud copy that the server uploads with its own account can be deleted with that same account. Formally 3-2-1 is met. In practice the attacker holds the keys to all three copies.
What immutable and air-gapped copies change
The answer to this problem has two layers that complement each other.
Immutable backups
An immutable backup is a copy that nobody can delete or overwrite for a set period: not the administrator, not the backup software, not an attacker who has taken over both. Technically this is implemented at the storage level: the object is locked, for example for 30 days, and the storage simply rejects any delete command until the period ends. Veeam calls this a hardened repository, and in cloud storage it is called object lock.
An important nuance: the lock must be in the storage, not in the backup application. If an attacker takes over the backup server, they will change the application settings. They will not change the storage lock.
Air-gapped backups
An air-gapped copy is a copy that cannot be seen from the production network at all. It is not a mounted drive, not a shared folder, and has no IP address that could be found during reconnaissance. Data reaches it through a one-way channel, and a restore is initiated not by the same people and not with the same credentials that manage the production network.
In the past this meant tapes that somebody took home every evening. Today the same principle can be implemented in the cloud, but it has to be designed deliberately so that the backup side cannot see the production credentials and the production side cannot see the backups.
3-2-1-1-0: the rule that fits 2026
In practice we use an extended version, which Veeam also recommends:
| Number | Requirement | What it protects against |
|---|---|---|
| 3 | Three copies of the data | Loss of a single copy |
| 2 | Two different media or systems | Hardware failure |
| 1 | One copy in a different location | Fire, theft, flooding |
| 1 | One copy that is immutable or air-gapped | Ransomware, a malicious administrator |
| 0 | Zero errors in a recovery test | A backup that cannot be restored from |
The first three items are the classic. The fourth answers the question “what if the attacker has administrator access”. The fifth answers the question we most often ask when we first meet a new client: when did you last try to restore? A backup that nobody has tested is an assumption, not protection. Zero errors means a regular, documented test, not a green checkmark in the backup software.
What this looks like at MDP CLOUD
When we keep the backups, the rule is implemented like this:
- First copy: on your server or in our cloud, for fast daily recovery: one file, one e-mail, one virtual machine.
- Second copy: in our data centre in Lithuania (EU), in separate storage and in a separate network zone from your production systems.
- Third copy as needed: in an Amazon data centre in Germany, when requirements (for example DORA or a corporate group policy) call for a copy in another country.
- Secret copy: immutable and invisible from your network. It is uploaded through a one-way channel, and during the set retention period it cannot be deleted by your administrator, your IT provider, or by us unilaterally. A restore is initiated by an authorised representative of yours through a separate channel unrelated to your network.
All of this is implemented with Veeam backups. When a company needs not only the data but also a place to run it after an incident, we add PlanB infrastructure recovery: a ready environment in our cloud where servers are started from backups while your office infrastructure is being repaired.
Where to start
- Draw where each of your backups is today and who has the right to delete it. If one account can delete all three, you have one copy, not three.
- Disconnect the backup storage from the production network: a separate network zone, separate credentials, no shared folders.
- Enable immutability in the storage, not in the application, and set a period no shorter than the time it would take you to notice a breach. In our experience that is at least 30 days.
- Restore one server into an isolated environment and record how long it took and whether everything worked.
- If you want to do these steps together with us, start with the description of secret backups or write to us through the contact form. In the first conversation we will assess together which of the 3-2-1-1-0 parts your company is missing today.
