Does cloud backup protect against ransomware?

Short answer: does cloud backup protect against ransomware depends entirely on what you mean by cloud backup. If you mean the copies Microsoft 365 or Google Workspace keep for you — recycle bins, version history, Files Restore — then no, not reliably. Those are availability and short-window undo features, and ransomware is specifically good at outrunning them. If you mean a real backup — an independent copy in a separate trust boundary, with its own credentials and its own retention — then yes, that is the layer that actually gets your data back.

The distinction matters because the two are routinely confused, usually by the sentence "it's all in the cloud, so it's backed up".

Why the cloud does not stop an encryption run

Ransomware rarely attacks a SaaS platform's infrastructure. It attacks an identity, and then uses that identity the way the platform expects it to be used.

Two paths do almost all the work:

The sync client. OneDrive, Google Drive for desktop and their equivalents exist to make local changes appear in the cloud. A file gets encrypted on a laptop, its bytes change, and the sync client does exactly its job: it uploads the change. There is no signal available to it that distinguishes an encryption run from an unusually productive afternoon. The malware never touches the cloud service; it lets your own sync agent carry the damage across.

An authenticated app or token. A compromised account, a malicious OAuth grant, or a stolen session can act through the platform's own APIs — reading, rewriting and deleting at API speed, from anywhere, with no endpoint involved at all. To the platform, this is a legitimate user doing legitimate things quickly.

Either way, the encryption arrives through the front door, authenticated. Replication and geo-redundancy — the things the cloud genuinely is very good at — then work against you: they faithfully replicate the encrypted version.

What native recovery does give you, and where it stops

Native tooling is not nothing. It is worth knowing precisely how far it reaches.

Microsoft 365. OneDrive's Files Restore lets you undo all the actions on files and folders within the last 30 days, including content that was deleted, overwritten, corrupted or hit by malware, and it works for work and school accounts. That is a genuinely useful mass-rollback tool, and for a contained incident caught quickly it may be all you need. Its limits are equally clear: nothing beyond 30 days, and Microsoft states plainly that a file permanently deleted from the OneDrive recycle bin can never be recovered. Recycle bin windows sit underneath it — we mapped those in how long the OneDrive and SharePoint recycle bins actually give you.

Google Workspace. Drive keeps previous versions, but Google documents the ceiling: a version might be permanently deleted after 30 days, or once there are 100 newer versions, unless someone has explicitly marked it "keep forever". Ransomware that rewrites a file repeatedly is a very efficient way to burn through 100 versions.

So native recovery is a time-boxed, count-boxed undo. It holds up well against the incident you notice on the same day. It holds up badly against three common cases:

• Dwell time. An attacker who sits quietly for six weeks before encrypting has already aged your clean versions out of a 30-day window.
• Scale. Restoring a handful of files through version history is fine. Restoring hundreds of thousands, across users and sites, without a bulk point-in-time mechanism, is an outage measured in days.
• Deletion by an admin identity. Emptying recycle bins, shortening retention, or removing sites and mailboxes are all normal administrative actions. Whoever holds admin rights can make the undo history itself disappear — and that is the first thing a competent attacker does.

Retention policies are not ransomware backup

A common answer to all of the above is "we have retention policies configured". Retention is a compliance control: it governs how long items are kept and prevents premature deletion. It is valuable, and it is not a backup, for one structural reason — it lives inside the same tenant, under the same admin identity, on the same side of the breach. An attacker with the privileges to encrypt at scale generally has the privileges to change the policy that was supposed to constrain them.

The same test applies to any copy you are counting on. Ask: if the identity that administers our SaaS tenant is fully compromised, does this copy survive? If the answer is no, it is redundancy, not recovery. This is the SaaS shared responsibility model doing what it always does: the provider guarantees the service stays up, and your data's recoverability from your own users' actions stays yours.

What "ransomware backup" actually has to mean

For a backup to survive a ransomware event rather than mirror it, four properties do the work:

1. A separate trust boundary. Storage outside the SaaS tenant, reachable with credentials that are not your Microsoft 365 or Google Workspace admin credentials. Compromising one should not deliver the other.
2. Immutable or append-only retention. Backup data that cannot be edited or deleted for its retention period — not by an attacker, and not by an administrator acting under duress or by mistake.
3. Point-in-time restore at scale. The ability to say "put this site, this mailbox, this Drive back to 03:00 on the 14th" and have it happen in bulk, rather than reconstructing it file by file.
4. Anomaly detection. Mass encryption and mass deletion have a shape — abnormal change rates, unusual file types, activity at odd hours. Detecting it early is what keeps a clean restore point inside your window. Detection is not prevention: it does not stop an attack, it shortens the time before you know, which is usually the difference between a bad day and a bad quarter.

Add a fifth, practical one: a restore you have actually tested. An untested backup is a hypothesis. The first time you find out how long a full restore takes should not be the day you need it.

So, does cloud backup protect against ransomware?

Put together: the cloud protects your data against its own failures — a failed disk, a lost datacentre, an outage. It does not protect your data against a legitimate identity destroying it, because from the platform's point of view nothing has gone wrong. Native recycle bins, version history and Files Restore buy you a window measured in weeks, and only if you notice inside it. A copy held outside the tenant, under separate credentials, with immutable retention and bulk point-in-time restore, is what turns "we have it in the cloud" into "we can get it back".

The questions worth answering now

• If a user's laptop encrypts everything in their synced Drive tonight, how far back can we roll it, and who does that?
• Would we notice on day one, or on day forty?
• If our global admin account is compromised, which copies are still out of reach?
• How long does a full restore of our largest workload take, and when did we last try it?

None of those need a vendor to answer. They need thirty minutes and honesty. If the answers are uncomfortable, that gap is the whole problem, and it is a solvable one.

We help you choose the right fit for your stack, deploy it, and get you protected across Microsoft 365, Google Workspace, Slack and Atlassian Cloud — you own and run the platform, we make sure the setup covers the workloads you actually have. For the platform-specific version of this walkthrough, see how to recover Microsoft 365 from ransomware.

If you want a straight answer on where your current setup would break, an assessment is a short, practical review of what you can recover today and what you cannot.