The email lands on an ordinary Tuesday: encrypted files, a ransom note, and a clock counting down. In that moment, the question that decides the outcome is not how much the ransom costs, but a far more uncomfortable one: can we restore everything from a backup we know is clean? Too many organizations discover, at exactly that instant, that their backups were encrypted too. Having backups is not the same as having recovery.
The short version: Modern ransomware seeks out and attacks your backups first. A backup only helps you recover if it is immutable, isolated from the production network, and exists in multiple copies (the 3-2-1 rule). And none of that counts if you have never tested a full, end-to-end restore.
For years, backup was designed with hardware failures, accidental deletions, or physical disasters in mind. Ransomware changed the rules: it is no longer a random event but an adversary that studies your infrastructure before acting.
Attackers know your best defense is the backup, so they make it their first target. Among the most common causes of failure we find:
The result is always the same: the copy exists, but it is useless. Recovery requires designing backup on the assumption that the attacker will try to destroy it.
Immutability means that, once written, a backup cannot be modified or deleted for a defined period, not even by an administrator with valid credentials. It is the difference between "I have copies" and "I have copies the ransomware cannot touch."
There are several ways to achieve it:
The key is that protection does not rely solely on good intentions or on a permission that can be revoked. If a compromised operator can delete the copy, that copy is not truly immutable.
Isolation means keeping at least one copy out of the direct reach of the production network. The classic concept is the air gap: a gap of air between your live data and your backup, so that an attack spreading across the network finds no path to the copies.
The traditional air gap was tapes stored physically offline. Today several approaches coexist:
The guiding principle is simple: if your production and your backup are compromised with the same key, you don't have two defenses, you have one—plus a useless copy.
The 3-2-1 rule is still the soundest starting point for thinking about backup:
Against ransomware, many organizations extend it to 3-2-1-1-0: they add 1 immutable or isolated (offline/air-gapped) copy and demand 0 errors in recovery tests. The idea is not to memorize numbers, but to understand that copy diversity and physical or logical separation are what break the attacker's ability to destroy everything at once.
When the attack detonates, the instinct is to restore the newest copy. But if the ransomware had been silently encrypting or corrupting data for weeks, the most recent copy may already be contaminated. Recovering well means identifying a trusted restore point: the last state known to be clean.
To do that you need:
Recovery is also a decision about time. Your RPO (how much data you can afford to lose) and RTO (how quickly you must be back in operation) objectives determine how often you back up and how fast you can come back online. A solution like SyncDR is designed to replicate and orchestrate recovery with those objectives in mind.
An untested backup is a hypothesis, not an insurance policy. The only way to know you can recover is to rehearse it, regularly and realistically. Tests should answer with data, not assumptions:
These tests are the heart of a well-governed disaster recovery plan. If you want to structure that plan, its scope, and its testing cadence, our disaster recovery plans practice helps take it from theory to something verifiable.
Because attackers know the backup is your way out without paying. If the copies are on the network with accessible credentials, they encrypt or delete them along with production. That is why immutability and isolation are now part of basic design, not a luxury.
The cloud helps only if that copy is genuinely isolated: with independent authentication, immutability enabled, and separated from your primary environment's directory. A cloud copy reachable with the same compromised keys gets encrypted like any network folder.
Often enough to have confidence before you need it, and every time your infrastructure or critical systems change significantly. What matters is that the test be complete and measured against your RTO and RPO objectives, not a superficial check.
Backup is the copy of the data; disaster recovery is the ability to resume operations using those copies, with defined processes, roles, and timeframes. Having the first without the second is exactly what fails when the attack arrives.
Don't wait for the Tuesday of the encrypted email to find out whether your copies work. The first step is honest and concrete: check whether your current backups are immutable, whether at least one copy is isolated from production, and whether they have ever been restored end to end. If the answer to any of those questions is "I'm not sure," there is your gap. At SUMāTO we help organizations across LATAM design backup and recovery that withstand ransomware, rather than merely appearing to. Let's talk about your recovery plan and turn your copies into a reliable way out.