Google Workspace backup: does Google actually back up your data?

Short answer: no. A proper Google Workspace backup is not something Google provides — Google keeps your deleted items in trash for about 30 days, gives an administrator a further 25 days to reach back after that, and preserves the platform rather than your specific data. After that window, or after a ransomware event that outlasts it, the data is gone unless you have an independent copy. Google says this plainly; the gap only surprises the companies that never read it.

Here is what Google actually retains and for exactly how long, why the admin recovery path is narrower than it looks, where the confusion with Google Vault and the Data Export tool comes from, and what closes the gap.

Retention is not backup

Google Workspace is genuinely good at the everyday case — undo a deletion within the month:

What	Native window	The catch
Gmail	30 days in Trash, then purged	Counted from the deletion date, not from when the trash was emptied
Drive	30 days in Trash, then permanent deletion	Plus a 25-day admin window after a user empties trash — see below
Shared Drives	Same 30-day trash model	A deleted shared drive is restorable for 25 days; access depends on membership, so a departing member can orphan files that still exist
Calendar, Contacts, Sites	Thin or no self-service recovery once deleted	Nothing resembling a restore point

That is retention: a short, automatic grace period. A backup is an independent, point-in-time copy you control and can restore from on demand. Google provides the first and, per the SaaS shared responsibility model, expects you to arrange the second.

The admin recovery window is 25 days, and it is all-or-nothing

This is the part that gets misread most often, so it is worth stating precisely. Google documents that an administrator "can recover deleted items from Google Drive within 25 days after a user empties their trash" — after which Google purges the items and they cannot be recovered. The theoretical maximum for a Drive file is therefore about 55 days: 30 in the trash, 25 more in the admin window, and only if nobody empties the trash early.

Three limits sit inside that 25 days, and each one matters more than the headline number:

• You cannot restore a single file. The admin restore works on a date range, and Google is explicit: "The restoration recovers all files removed during the selected date range. You can't restore individual files or folders." If you need three files from a bad Tuesday, you get everything deleted that Tuesday.
• You have to know the date. The restore is driven by when the item left the trash, which is precisely the fact nobody records. Guessing the range widens the collateral damage.
• Retention policies do not extend it. For shared drives, Google states you can only restore items removed from the shared drive's trash within the last 25 days even if you have Vault retention policies in place. The compliance control does not buy the recovery control more time.

The same asymmetry between Gmail's and Drive's clocks — one anchored to the deletion, the other to the emptying — is where most real losses happen. We took that apart in the real windows for recovering deleted Gmail and Drive files.

Google Vault doesn't close the gap either

A common mix-up: "we have Vault, so we're covered." Vault is an eDiscovery and retention-policy tool — it holds messages and files for legal hold or compliance retention, and it's genuinely useful for that job.

What it does not give you is a restore. Google's own guidance on data older than the 25-day window is that a Vault user can search for retained data and export it — but that you cannot directly restore that data back into the user's Drive. The output is a file somebody reassembles by hand, not a mailbox or a folder returned to how it looked. Vault preserves for search and litigation; using it as a recovery path for ransomware or accidental deletion means slow exports instead of a restore button.

The native "how do I back up Google Workspace" answer, and its limits

If you go looking for a first-party way to take a copy, you land on the admin Data Export tool, which exports the organisation's data to a Cloud Storage archive. It is a real and useful tool, and it is not a backup. Google's own documentation sets out why:

• It is slow. The export is available no earlier than 48 hours after you start it, typically takes about 72 hours, and can take up to 14 days for a large domain.
• The archive expires. Data exported to a Google-provided bucket is automatically deleted 60 days from the start of the export.
• It does not contain your deleted data. Deleted content is excluded unless it was retained by a Vault policy — so the export captures what you still have, not what you lost.
• There is no restore. The tool exists for preservation and migration. Nothing in it puts a mailbox or a Drive back the way it was.

Run quarterly and stored somewhere durable, an export is better than nothing. As a recovery plan for a business, it fails on the two axes that matter: it cannot reach the past, and it cannot put anything back.

Where the backup lives: the EU data-residency question

For organisations with a data-residency requirement, Google offers data regions: an admin can choose to store covered data in the United States or Europe, or express no preference. The coverage is real — it applies to primary data at rest, including backups, and to data processing for Gmail, Calendar, Drive, Docs, Sheets, Slides, Chat, Vault and others. It is also edition-dependent: the fuller Enterprise-level controls come with specific editions or as an add-on, while other business editions get a narrower version.

Two things are worth being clear about. First, a data region governs where Google keeps your live data — it does not create an independent copy, so it answers a residency question, not a recovery one. Second, when you add your own backup, its storage location becomes a separate decision that you control, and for a GDPR file that is a feature: you can put the independent copy in a European region deliberately and document why. The evidence obligations that make this matter are in what GDPR actually requires of SaaS backup.

Why the windows fail you

• Ransomware waits them out. Encryption that dwells for weeks surfaces only after trash has auto-purged the clean copies, so the "last known good" state you would restore to may no longer exist inside Google's retention at all. The mechanics are in does cloud backup protect against ransomware.
• Offboarding loses data. Deprovision a user and their Drive content can age out or orphan faster than anyone expects — especially in Shared Drives, where the file's existence doesn't guarantee anyone still has access to it.
• Bulk mistakes. A bad sync client or a mis-scoped script can delete thousands of files in minutes; trash fills, purges on schedule, and the oldest losses fall off the back before anyone notices the scale of it.
• Compliance needs proof. GDPR and ISO expectations lean on demonstrable, testable recovery — a rolling 30-day bin with no restore log is not evidence you can hand to an auditor.

What real Google Workspace backup looks like

An independent backup living outside your Workspace domain, with:

• Continuous, incremental capture of Gmail, Drive and Shared Drives — not a manual export you have to remember to run.
• Point-in-time restore to any day, not just the last 30 or 55.
• Granular recovery — a single message, a single file, or an entire user's account, restored on its own without touching everything else. This is the exact capability the native 25-day window does not have.
• Ransomware anomaly detection so mass-encryption gets flagged as it starts, not weeks later when someone notices missing files.

That's what we help you choose and deploy — an independent solution you own and run, and we guide the setup and onboarding. The Google Workspace backup and recovery page covers the specifics per app.

What to check before you commit to a solution

Not every product marketed as "Google Workspace backup" covers the same ground. Before you pick one, confirm it can:

• Back up Shared Drives specifically, not just personal My Drive content — Shared Drive ownership and permission structures trip up backup tools that were designed for individual accounts first.
• Restore to a different account or a new domain, not only back to the original — useful in a full-tenant compromise, not just a single-file mistake.
• Restore one item without restoring the day around it, which is the precise limitation of the native admin path.
• Show you a restore history and audit trail — the artifact you'd actually hand to a compliance reviewer or a cyber-insurance underwriter.
• Detect anomalous deletion or encryption patterns, rather than relying on someone noticing files are missing.

The 30-second self-test

Ask your admin: "If a departed employee's Drive was cleared 40 days ago and we need three of those files for an audit, can we get them — just those three?" If the honest answer is no, or "only by restoring everything from that day", you have retention, not backup.

---

Not sure what would survive an incident today? Book a free risk assessment — we'll review your Workspace domain and tell you exactly what's recoverable, app by app. No pricing pitch, just the gaps.