The core argument
Ransomware goes for the backups first.
This is the part that surprises people. It is not a smash-and-grab. The backups are the target, and they are usually taken before anything visible happens.
Bring your retention schedule. We will tell you what it actually costs to meet it.
Air-gapped
No network connection. Ransomware cannot reach it.
70°F / 50%
Climate held to ±2° and ±5% RH
9R
Highest UL vault rating available
40+
Years operating since 1983
How it actually goes
- 1
Initial access.
Credentials, a phished session, an unpatched edge device. Nothing breaks. Nobody notices.
- 2
Dwell.
The attacker moves quietly and maps the environment. This phase is measured in weeks, not hours.
- 3
Find the backups.
This is a deliberate, prioritised step. Backup servers, replicas, snapshots, and any cloud target the compromised credentials can reach.
- 4
Corrupt or delete them.
Quietly. Retention policies get shortened. Snapshots get expired. Jobs keep reporting success because the job is not the problem.
- 5
Then encrypt production.
Only now does anything visible happen — at which point the recovery path has already been removed.
- 6
The demand.
Priced against what it costs you to rebuild from nothing, because that is now the alternative.
The whole point
Why the offline copy is different
Steps three and four require the backups to be reachable. Every one of them assumes a network path, a credential, or an API.
A cartridge on a shelf in a vault with no network interface has none of those. It cannot be encrypted, expired, or deleted remotely, because there is no remote. It is not hardened — it is absentfrom the attack surface entirely.
That is the only property that matters here, and it is the one property no connected system can have.
Being fair
Where cloud immutability genuinely helps
Object lock and immutable snapshots are real controls and they defeat a lot of attacks. We are not going to pretend otherwise — if you have them configured properly, you are in far better shape than most.
Three things still catch people:
- Configuration. Immutability that was enabled after the intrusion began protects the already-corrupted state.
- Window length. A 14-day lock does not help against 6 weeks of dwell.
- The account itself. Immutability protects objects. It does not protect you from losing the account to a billing failure, a vendor dispute, or an administrative takeover.
Practical
What we would actually suggest
Keep cloud as the fast tier — it is better at day-to-day recovery and you should not give that up. Add an offline set on a fixed rotation with enough history to reach back past a realistic dwell period. That is usually a weekly set rotating out and a monthly set held long term.How the rotation works →
Common questions
- Is immutable cloud storage not enough?
- It is genuinely strong, and if it is configured correctly and was configured before the breach, it usually holds. The failure cases are misconfiguration, a retention window shorter than the dwell time, and losing the account itself. An offline copy has none of those failure modes.
- How long do attackers sit in a network first?
- Long enough to find and corrupt backups deliberately — that is the part people underestimate. Assume weeks, not hours, and size your offline retention accordingly.
- Does tape actually get used in recovery?
- When the connected copies are gone, it is what is left. Slow beats absent.
- How much should we keep offline?
- Enough history to reach back past the dwell time. A single most-recent offline copy can already be encrypted. Talk to us about the rotation rather than the volume.
Bring your current backup design.
We will tell you where the offline copy actually belongs in it — and if you do not need one, we will say that too.