SaaS backup: what your vendor has already decided for you

SaaS backup is the practice of keeping a recoverable copy of your SaaS data outside the vendor's control plane — separate from the trash bins, retention policies and export buttons the vendor ships. You need it because the contract you signed is an availability contract, not a recoverability one. Microsoft's own Services Agreement tells you to back up what you store on its services. Google's Workspace SLA promises uptime and pays out in service credits, and says nothing at all about getting deleted data back. This post sets out what that gap actually is, what your vendors have already decided on your behalf, and what a copy has to do before it counts as a backup.

What SaaS backup means, precisely

Three conditions, all of them load-bearing:

1. A copy exists outside the vendor's control plane. Not a second region inside the same tenant, and not a longer setting on the same data — a copy that survives the loss, compromise or lapse of the account that holds the original.
2. You choose the recovery point. Not whatever the vendor's native window happened to retain at the moment you noticed.
3. You can restore a part without restoring the whole. One mailbox, one page tree, one project — without overwriting everything around it.

Most of what gets called backup in a SaaS context fails at least one of these. Usually the third.

Your contract covers uptime, not your data

This is the part that surprises people, because it is hiding in documents everyone accepts and nobody reads.

The Microsoft Services Agreement (published 30 July 2026), under Service Availability, states: "We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you've stored. We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services."

That is the Services Agreement rather than the commercial Product Terms that govern an enterprise tenant, and the distinction is worth knowing before you quote it at a vendor. But the posture is the vendor's own, written down: outages happen, your data may be unreachable, and backing it up is your job.

The Google Workspace SLA works the same way from the other direction. It commits to a Monthly Uptime Percentage of "at least 99.9% in any calendar month," and it is explicit that the SLA "states Customer's sole and exclusive remedy for any failure by Google to meet the Google Workspace SLA" — a service credit. The document is about whether the service is reachable. It makes no commitment about recovering data that was deleted, encrypted or overwritten while the service was up and running perfectly.

Both vendors are being straightforward. Availability and durability of their platform is their job. The lifecycle of your data on it is yours. We wrote about the full division of labour in the SaaS shared responsibility model, and every practical consequence below falls out of it.

The three things people mistake for backup

Retention and legal hold are preservation, not restore

A retention policy stops data being removed. It does not give you a way to put a known-good version back. Google says this about its own product in as many words — Vault is not a data archive, it exports but does not restore. Microsoft's retention and eDiscovery equivalents preserve into a state you then have to search and extract from, which is a discovery workflow with a lawyer's timeline, not a recovery workflow with an operations timeline.

Worse, retention is a setting on the live tenant, which means anyone with admin rights can shorten it — including an attacker who has admin rights.

Sync is replication, and it copies the damage too

OneDrive's own interface calls folder sync "Back up important PC folders." It is not a backup: it is a fast, faithful replicator. When ransomware encrypts a synced folder, the sync client does exactly what it was built to do and propagates the encrypted versions to the cloud. The same applies to Drive for desktop. We covered the whole trap, including the licence condition that outranks every retention setting you have, in OneDrive backup: why folder sync is not one.

Encryption during a ransomware incident usually arrives authenticated — through a sync client or an API token that is supposed to be there. Replication has no way to tell that from ordinary work.

An export is a file, not a restore path

This one is the most consequential, and Atlassian's documentation states it more plainly than any vendor we have read.

You can export a full Jira Cloud site. But Atlassian documents that importing that export "will erase all existing data and replace it with data from your backup," and that "You can't use this process to import a specific project while maintaining your existing site data." So the file exists, and the only documented way to use it destroys everything created since it was taken. As of 22 January 2026 Atlassian also limits Backup Manager restores "to those that are 30 days old or less," and if you include attachments, avatars or logos you must "allow 48 hours between backups."

The pattern repeats across every platform. A Slack export hands you file links rather than files. Google's Data Export tool makes you wait, excludes deleted data, expires the archive, and offers no restore path at all — one of four routes we walked through in how to back up Google Workspace, of which exactly one is a backup. Confluence's Backup Manager keeps a single copy whose download link expires and whose restore overwrites the target site.

An export answers "can I get a copy of this?" Backup answers "can I put this back?" They are different questions and vendors have mostly only built the first.

The recovery ceilings your vendors already chose

If the only copies you hold are the vendor's, then your recovery point objective is not a number you selected. It is whatever each native window happens to be — a different number per workload, none of them chosen by you, and several of them shortened by ordinary user behaviour like emptying a trash or removing a licence at offboarding.

Workload	Documented native ceiling	Shortened by
Exchange Online	14 days deleted-item retention by default, raisable to 30; 30 days for a soft-deleted mailbox	Offboarding; default left untouched
OneDrive / SharePoint	93 days across both recycle-bin stages, counted from the original deletion	Emptying the first stage; loss of licence
Microsoft Teams	~30 days for a soft-deleted team or channel; no self-service restore for chat messages	Deleting rather than archiving
Gmail	30-day trash plus a 25-day admin window, anchored to the deletion date	Little — the two windows add up
Google Drive	30-day trash plus a 25-day admin window, anchored to when the trash is emptied	Emptying the trash early
Slack	Deletion is permanent; there is no trash	A retention setting chosen before the deletion
Jira	60 days for a trashed project; no documented trash for individually deleted work items	Nothing — the floor is already zero
Confluence	No published expiry for deleted pages; a hard 60 days for a deleted space	An admin purging the space trash
Bitbucket	No admin-triggered backup; recovery means rebuilding from a local clone	Not holding a current clone

Each of these is documented by the vendor, and each is covered in depth in the platform post it links from: Microsoft 365 backup, Google Workspace, Slack retention and Atlassian Cloud.

Read the table as a single number and it is uncomfortable: the widest ceiling on it is 93 days, most sit between two and eight weeks, and one is zero. Attacker dwell time is measured on the same scale. A patient intruder does not have to defeat these windows. They only have to wait them out.

What a copy has to do before it counts

This is the checklist we use when helping a team work out whether what they have is a backup or a filing cabinet:

• It is independent of the tenant. Compromising the admin account should not compromise the copies.
• It runs without anyone remembering. Continuous or scheduled capture, not a button someone presses when they think of it.
• It restores granularly. One item, one project, one mailbox — without overwriting its neighbours, which is exactly what the Jira import behaviour above does not allow.
• It restores to a point in time you pick, not to whichever snapshot happens to survive.
• It covers the workloads you actually run, including the ones vendors leave out of their own first-party tooling.
• It flags anomalies — a mass deletion or a mass encryption event visible while it is happening, rather than discovered after the native windows have closed.
• It produces evidence. Restore logs and test results, because NIS2, GDPR, ISO 27001 and cyber-insurance questionnaires ask you to demonstrate recovery, not to assert it.
• It has been tested. An untested backup is a hypothesis. The rest of that argument is in our SaaS disaster recovery plan post.

No backup prevents a ransomware attack. What an independent, tested copy changes is the outcome: an incident becomes a restore with a known recovery point instead of a negotiation, and the decision about what you lost stops being made for you by a trash-bin timer.

Working out what you actually need

The right answer depends on which workloads carry your operational risk, what your regulators and insurers expect you to prove, and how much of the current arrangement is already doing a job you think it is doing. That is a conversation, not a page.

We help you choose and deploy the right fit for your stack across Microsoft 365, Google Workspace, Slack and Atlassian Cloud — and we get you through setup and onboarding so it is genuinely running rather than half-configured. You own and run the result.

If you want to know where your current exposure actually sits, book an assessment. It is a short, structured review of which of your workloads have a real recovery path today and which ones are relying on a window someone else chose.