The attack that beat your backup was aimed at your backup
Modern ransomware crews don't encrypt your files and hope. They go for the backup first, because the backup is the only thing that lets you say no. In Sophos's 2025 State of Ransomware survey, attackers tried to compromise backups in 94% of incidents, and succeeded in 57% of those attempts. When the backup falls, the median recovery cost runs eight times higher — about $3M versus $375K when backups survive. Verizon's 2025 DBIR put ransomware in 44% of confirmed breaches, up from 32% the year before. The backup isn't a footnote in these attacks. It's the objective.
So the question for anyone with a synced cloud folder is uncomfortable: does cloud storage help here, or does it hand the attacker a faster way to ruin every copy at once? The honest answer is both. Which one you get depends entirely on how the storage handles old versions of a file.
Why sync replicates the attack instead of saving you
A sync client has one job: make the server match your disk. It does that faithfully, and it doesn't know or care why your files changed. When ransomware walks your home directory and rewrites every document as a high-entropy blob, the sync client sees thousands of modified files and does exactly what you'd want under any other circumstance. It uploads them. Within minutes the encrypted versions are on the server. If a second device pulls those changes, the damage spreads there too.
This is the failure mode people don't expect. They picture the cloud as a safety net; a naive sync turns it into an amplifier. The clean copy you were counting on gets quietly overwritten by the encrypted one, and now your laptop and your "backup" both hold garbage. A folder that mirrors your disk in real time is not a backup. It's a second copy of whatever state your disk is in right now, ruined state included.
It gets worse. Several ransomware families now look specifically for connected cloud accounts and mapped drives. If your storage exposes a delete-or-overwrite API and the malware holds your authenticated session, it can reach past the local folder and try to scrub history on the server directly. That's the same instinct that drives them to hunt local backup repositories: kill the rollback, and the victim has no leverage left.
What actually saves you: immutable, server-side versioning
The thing that breaks the attack isn't encryption and it isn't sync. It's versioning the client can't retroactively destroy. When the server keeps prior versions as separate, append-only objects — and a client, even a fully authenticated, compromised one, can write new versions but cannot reach back and delete or rewrite the old ones — the ransomware's upload becomes just another version sitting on top of a clean one. You roll back to the last good version and you're done. The attacker encrypted your current state. They couldn't touch the history behind it.
The detail that matters is immutability of old versions. Plenty of services keep "version history" but let any authenticated client prune it. That's theater against ransomware, because the malware is an authenticated client. If the cleanup path is reachable with the same credentials that do the uploading, the attacker who can encrypt can also delete the evidence. The protection only holds when the server enforces append-only on prior versions independent of the client. The write key uploads. It doesn't get a delete-history key.
Here's the honest limit, stated before a critic would: an immutable copy of an already-encrypted file is worthless. Versioning only helps if a clean prior version exists and is still within retention. If a file was created, encrypted by ransomware, and synced before any good version ever landed, there's nothing behind it to restore. And if your retention window is short and you find the attack late, the clean versions may have aged out. Versioning buys you a rewind button; it doesn't invent a past that was never recorded. That's why file versioning is necessary but not sufficient, and why the retention window is the number you should actually be asking about.
Where end-to-end encryption fits, and where it doesn't
Zero-knowledge encryption and ransomware protection solve different problems, and it pays to be precise about which does what. Client-side encryption means the server stores only ciphertext — files sealed with AES-256-GCM under keys derived on your device with Argon2id, never seen by the server. That protects your data's confidentiality if the provider is breached. An attacker who pops the storage backend walks off with unreadable blobs.
But end-to-end encryption does nothing to stop ransomware on your own machine. On your authenticated device the files are decrypted — that's the entire point — so malware running as you sees plaintext, encrypts it, and the sync client uploads the result as ciphertext like any other change. Encryption defends against the provider being the threat. Ransomware is a threat on the endpoint. Don't let anyone sell you E2E as ransomware protection; the mechanism that defends you there is immutable versioning, not the cipher.
What zero-knowledge does add is that your rollback safety net isn't itself a liability. With most providers, the version history that saves you from ransomware is also a readable archive of your data on someone else's server, reachable by a subpoena or a misconfigured bucket. Under a zero-knowledge model the server holds an append-only history of ciphertext. You get the rewind button without handing the provider a readable timeline of everything you've ever stored.
A setup that survives an encryption event
If your real worry is ransomware reaching cloud-synced files, this is where to spend your attention:
- Use storage with server-side, immutable version history — not just "we keep versions," but versions a compromised client can't delete. Ask whether the cleanup path is reachable with normal account credentials. If it is, treat the history as soft.
- Know your retention window and set it deliberately. Ransomware dwell time, the gap between intrusion and detonation, can run weeks. A 7-day window won't save you if the clean version aged out before you noticed. Configure retention to outlive your realistic detection lag.
- Keep at least one copy that isn't continuously synced. Real-time sync is convenient and it's also the propagation path. A periodic, versioned snapshot is harder to ruin in one stroke than a live mirror.
- Shrink the blast radius of a stolen session. Short-lived tokens, device-bound credentials, and 2FA don't stop encryption on the endpoint, but they make it harder for malware to reach the server's history through your authenticated session.
A ransomware-resilient cloud comes down to client-side encryption so a server breach yields nothing readable, append-only versioning the endpoint can't retroactively wipe, and a retention window long enough to outlast your detection lag. Beebeeb keeps recent file versions server-side with configurable retention, stored as ciphertext in Falkenstein, Germany, with the encryption running on your device — so a breach of our backend exposes blobs, not files. We're also clear about what's still maturing: native desktop sync, where this protection matters most for everyday workflows, is on the roadmap rather than shipping today, and recovery still depends on a clean prior version existing within retention.
Ransomware will keep going after backups because backups are what let victims refuse to pay. The countermeasure isn't a stronger cipher or a faster sync. It's a copy of your data the attacker can add to but can't subtract from — plus the discipline to make sure a clean version was already there before the bad one arrived.