How to back up Google Workspace: every route, and what each misses

If you are working out how to backup Google Workspace, there are exactly four routes, and only one of them is a backup. The other three are a time-boxed undo, a one-shot data dump, and a legal-hold tool that Google itself says "isn't a data archive". Each has a documented window, a documented set of exclusions, and a documented answer to the only question that matters in an incident: can it put the data back? Below is what each route does, what it costs you in time, and how to tell which one your obligations actually require.

Route 1: the native recovery windows

Every Google Workspace tenant ships with a set of undo windows. They are useful, they are free, and they are not backup — they are a short grace period on deletion, with no schedule and no copy.

• User trash. Deleted Gmail messages and Drive files sit in the user's trash for 30 days, and the user can restore them without help.
• Admin restore, 25 days. After a user empties their trash, an administrator has 25 days to recover the items. After that, Google purges them and they cannot be recovered.
• Deleted accounts, 20 days. An administrator may be able to restore a deleted user account and its files if the account was deleted less than 20 days ago.

Two properties of the 25-day admin restore decide how useful it is under pressure. You select a date range that includes the day the item left the trash — and the restore then recovers everything removed in that range. You cannot restore individual files or folders. So recovering one deleted contract means reinstating every other deletion from those days too, including the ones that were deliberate.

We mapped how these clocks interact, and the trap where emptying the Drive trash early silently shortens the total window, in recovering deleted Gmail and Drive files. The account-level case is covered in restoring a deleted Google Workspace user.

Route 2: the Data Export tool

The Data Export tool produces a full, admin-initiated export of your organisation's data — the same data available through Takeout for individual users, plus admin-only and organisation-owned content. It covers Calendar, Chat, Contacts, Drive, Gmail, Groups, Keep, Tasks, Voice and more. It is the closest native thing to "give me everything".

The constraints are all documented, and they are the reason it cannot serve as your backup:

• Eligibility. You need a super administrator account that is at least 30 days old, with 2-Step Verification enabled. Organisations with FedRAMP Authorization or more than 1,000 users must contact Google support before using the tool.
• It is slow by design. There is a mandatory 48-hour security waiting period, and then the export "typically takes 72 hours but can take up to 14 days, depending on the size of your data export".
• The archive expires. With Google-provided storage, the exported data is "automatically deleted 60 days from the beginning of the export".
• It excludes deleted data, unless that data was retained or held by Vault policies. It also excludes accounts created within 24 hours before the export starts.
• There is no restore path. The tool exports. Nothing in it puts data back into a live account.

Line those up against an incident. The thing you most need back is usually the thing that was deleted, which the export excludes. The export takes up to 14 days to produce, which is longer than most incident response timelines. And it lands as an archive of files that somebody then has to reconstruct into a working mailbox or Drive by hand. As a periodic compliance snapshot it is reasonable. As a recovery mechanism it is not one.

Route 3: Google Vault

Vault is a retention and eDiscovery service. It lets administrators retain, hold, search and export users' Google Workspace data, and for litigation hold and investigation work it is the right tool. Google's own documentation is unusually direct about the boundary: "Vault isn't a data archive."

Three properties follow from that, and each one surprises somebody:

1. Vault does nothing until you configure it. Google states plainly that "Vault doesn't retain data until you set up retention rules". A tenant with Vault licensed but no rules configured is retaining nothing.
2. Retention rules delete as well as preserve. A retention rule has an end. "When data is purged after a retention period ends, it can't be recovered by users or admins." Vault is as capable of enforcing destruction as of preventing it.
3. It exports; it does not restore. You can search and export for processing and analysis. There is no mechanism that reinstates the content into the user's mailbox or Drive.

Vault answers "can we produce this for a regulator or a court". It does not answer "can we be working again by Thursday".

Route 4: an independent, automated copy

The fourth route is the only one that meets the ordinary definition of backup: a scheduled copy held outside the Google tenant, under retention you set, that can restore granularly back into the live environment.

That is a category, not a single product, and the differences between options are real. The properties worth insisting on:

• A schedule you choose, so your recovery point objective is a decision rather than a side effect of Google's defaults.
• Storage outside the tenant boundary, so that a compromised super admin, a billing lapse or a tenant-level mistake does not take the copies with it.
• Granular restore in place — one message, one file, one shared drive, one user — without a date-range sweep that reinstates deletions you meant.
• Retention you control, aligned to your own GDPR, NIS2 or sector obligations rather than to a 25-day purge or a 60-day archive expiry.
• Anomaly detection, so that a mass deletion or mass encryption event is flagged while the native windows are still open.

Which route answers which question

	Native windows	Data Export tool	Vault	Independent copy
Runs on a schedule	No	No, manual	Continuous once configured	Yes
Covers already-deleted data	Within the window	No, unless held by Vault	Only under a rule set beforehand	Yes
Restores back into the account	Yes, date-range only	No	No	Yes, granular
Retention you control	No	60 days on Google storage	Yes	Yes
Survives loss of the tenant	No	Only if you moved the archive	No	Yes

The honest reading is that the native routes overlap heavily on what they protect against — accidental deletion, discovered quickly — and leave the same gap uncovered: anything discovered late, anything that needs putting back precisely, and anything that happens to the tenant itself. This is the division of labour set out in the SaaS shared responsibility model: Google guarantees the service is available and durable, not that your data is recoverable from your own mistakes. Our longer answer to the underlying question is in does Google Workspace back up your data, and the workloads we cover are listed on the Google Workspace protection page.

How to backup Google Workspace: the practical sequence

Most organisations do not need all four routes. They need to know which obligation each one is carrying, and to stop assuming a tool is doing a job it documents itself as not doing. A practical sequence: write down your longest acceptable data-loss window per workload, check it against the 25-day admin restore, then decide whether the gap is a compliance problem, an operational one, or both.

We help you choose and deploy a backup platform that fits your Google Workspace tenant, your retention obligations and the capacity of the team that will run it. You own and operate it afterwards; our job is making sure the choice and the setup are right.

Book a backup assessment and we will document your current recovery window per workload and show you exactly where it runs out.