Data protection
Google Workspace backup and retention
Google Vault is a retention and eDiscovery tool, not a backup. It holds what your rules told it to hold, so a mailbox deleted 2 years after a 1-year retention rule expires is gone, and Drive files a compromised account overwrites in place are recoverable for 30 days at most from version history.
| Gmail trash | 30 days, then unrecoverable by an administrator |
|---|---|
| Drive trash | 30 days, then purged from the user's view |
| Drive version history | Retained per file; overwrites are recoverable, purges are not |
| Admin restore for a user | Within 25 days of deletion, subject to edition |
| Google Vault | Only content matching an active retention rule or hold |
| Third-party backup | Independent copy with its own retention and restore path |
Retention and backup answer different questions
Retention answers a legal question: what must we keep, and for how long, so it can be produced if asked. Backup answers an operational one: how do we get yesterday's version back after something went wrong. Vault is excellent at the first and structurally unsuited to the second, because it preserves according to rules set in advance rather than capturing state continuously.
That distinction becomes concrete during an incident. A finance shared drive whose contents were re-encrypted by a compromised third-party app is a restore problem measured in hours. Vault can produce copies of anything a rule was already retaining, which may be all of it or none of it depending on decisions somebody made years earlier.
- Vault retains by rule; it does not snapshot the tenant
- Deleting a user account can remove data no rule was holding
- Trash is a user convenience, not a recovery tier
- Version history covers overwrites, not deliberate purges
- Restores need a rehearsed procedure, not a licence you own
The scenarios to design against
Four scenarios cover almost every real recovery request. A leaver's data needed months after their account was tidied away. A shared drive whose folder structure someone reorganised destructively. A compromised account that mass-deleted or overwrote files through an authorised OAuth app. And a legal request for material older than your current retention rule.
Each has a different answer, and only the fourth is a Vault question. Write down which tool covers which scenario, then test the two you are most likely to face. An untested restore path is a plan, not a control.
| Leaver data needed later | Archived User licence plus a documented offboarding sequence |
|---|---|
| Destructive reorganisation | Drive version history within its window, or third-party backup |
| Compromised account mass-delete | Third-party backup with point-in-time restore |
| Legal production request | Vault retention rules and matter holds set in advance |
Designing retention you can defend
Start from the organisation's own document policy rather than from console options. Statutory record-keeping periods, contractual obligations and sector rules set the floor; anything longer is a choice you should be able to explain. Then write the rules to match, per content type, and record who approved them and when.
Two failure patterns dominate. Retention that is shorter than policy, which quietly destroys records the organisation believed it held. And indefinite retention of everything, which sounds safe and is instead an expanding disclosure surface with a cost attached. Neither is a technical mistake; both are governance decisions made by default.
Testing the restore, not the backup
Backups fail silently and restores fail loudly. Rehearse a restore twice a year: pick a folder and a mailbox, restore them to a staging location, and time it. Record the elapsed time, because that number is your real recovery objective, whatever the policy document claims.
Keep the evidence. A dated restore test with a named owner is what turns a control from an assertion into something an auditor or insurer will accept, and it is the artefact almost no tenant we review can produce.
What we see that others don't say
In the tenants we audit, the single most common gap is not the absence of backup software but a retention rule shorter than the organisation's own document policy, so the tool was working correctly and the data was still unrecoverable.
What this doesn't cover
- We do not resell backup software; we specify requirements and configure retention, then you buy the tool you prefer.
- Legal hold decisions and retention periods belong to your counsel and records owner, not to an administrator's judgement.
- Recovery windows quoted are Google's documented defaults and change with edition; verify against Admin Help for your own tenant.
- Endpoint and non-Google SaaS data need their own backup design and are outside a Workspace tenant review.
Questions we get asked
- Is Google Vault a backup?
- No. Vault is retention and eDiscovery. It preserves only content matching a rule or hold that already existed, and it has no point-in-time restore, so it cannot recover from destructive changes the way a backup can.
- How long can an administrator restore deleted Google Workspace data?
- Trashed Gmail and Drive items are recoverable for 30 days, and a deleted user account can typically be restored within 25 days depending on edition. After those windows, recovery depends on Vault retention or an independent backup.
- Do we need third-party backup for Google Workspace?
- You need it for scenarios Vault cannot cover: point-in-time restore after a compromised account or a destructive reorganisation. If your risk assessment accepts those outcomes, retention rules alone may be enough — but record that decision.
- What is the most common Workspace data-protection gap?
- A retention rule shorter than the organisation's own document policy. The tooling behaves correctly, nobody notices, and records the organisation believed it held were deleted on schedule.
How this page is verified
Reviewed by Pearl Lemon Cloud security desk, Workspace security and compliance reviewers. Last checked .
- Trash, version history and user-restore windows reflect Google Workspace Admin Help documentation as of 2026-08-06.
- Gap frequencies reflect Pearl Lemon Cloud security audit findings across tenants of 20 to 300 seats.
- Vault capability statements are limited to behaviour Google documents publicly.
Sources you can check
Related pages
Can you produce a dated restore test?
An audit compares your retention rules against your own document policy, names the scenarios currently unrecoverable, and leaves you with a rehearsed restore procedure and the evidence that it ran.