Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Google Workspace: why Vault is not a backup, and what export gives you

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Businesses that move email and files to Google Workspace often stop thinking about backup. Google runs the service, and many editions include Google Vault, which keeps data even after users delete it. So it is easy to assume that Vault is the backup.

Google's documentation describes something different. This guide is for owners and administrators of Google Workspace. It sets out, from Google's help pages, what Vault, Drive recovery and the Data Export tool each do, where each stops, and how to check what your organisation could actually get back after a mistake or an attack. A companion article covers the same question for Microsoft 365.

Why it matters

Recovery means putting data back where people can use it, at the right point in time, within a time the business can tolerate (our reading). A tool that can find and export data for a lawyer may not do that. If the difference is discovered during an incident, the business may find it can prove what it had but cannot easily get it back.

What Google says Vault is

Google's Vault help page opens: "Google Vault is an information governance and eDiscovery tool for Google Workspace." Its two main jobs are retention and eDiscovery: "Information governance: Retain and delete data Keep data for as long as you need it."

Vault can keep data users have deleted: "Data remains available to Vault even when users delete it and empty their trash." It can also delete data on schedule: "If your organization is required to delete sensitive data after a set time, you can configure Vault to remove it from user accounts and start purging it from all Google systems."

Three conditions matter before relying on it:

  • Preservation must be configured. Inventory both retention rules and authorised holds. Holds can preserve covered data even when no retention rule applies; without either, normal service deletion can proceed. Do not infer preservation or absence of preservation from the rule list alone.
  • It needs licences. "For Vault to search and retain a user's data: users must have a Google Workspace license that includes Google Vault." Google also notes: "Starting on November 1, 2025, Google Workspace admins must have a Google Vault license to continue using Google Vault."
  • Deleting a user can lose data. "If you delete a user or a required license, their data might be irreversibly purged and no longer available to Vault."

Why Vault is not a backup

Four points from Google's pages show the gap, in our reading.

It does not restore. Google's Drive recovery page says that with Vault, "A Vault user can search for retained data and export it. However, you can't directly restore this data to the user's Drive."

Retention is the same copy, not a separate one. Google explains: "Vault is fully integrated with the Google services that it supports, so there is no separate archive." And: "Data purged in Vault is purged from all Google services".

Rules can remove data as well as keep it. Holds take precedence over retention rules. For data governed by multiple applicable custom rules, Google generally keeps it for the longest custom period; custom rules take precedence over defaults, with documented service/ownership exceptions such as a shorter collaborator rule not overriding a longer owner default. Scope depends on the service, organisational unit, account or shared drive and any search conditions. A bad rule can purge matching data within its applicable scope, not indiscriminately across every product. When a hold is removed, applicable retention rules take effect, so review that change with the legal owner.

Exports are short-lived. "A data export is available in Vault for 15 days, then the export is deleted to protect that data."

Vault exports are built for review. Google says an export contains "A comprehensive copy of all the data that matches your search criteria", metadata linking it to users, and "The corroborating information required to prove that the exported data matches the data stored on Google's servers." Email comes out as PST or mbox files; Google notes, for example, that "If the messages for an account exceed 1 GB for PST files or 10 GB for mbox files, they're exported in ZIP files." Putting those files back into user accounts is a separate migration task (our understanding).

Settings that weaken Vault quietly

A few details in Google's setup guidance can undo retention without anyone noticing (our reading).

  • Other deletion settings. Google warns, about an automatic message deletion setting: "If this feature is configured to automatically delete messages, it interferes with Vault retention rules."
  • No universal rescue window. Google describes service-specific purge behaviour, not a guaranteed extra 30 days. Drive items removed with no protecting rule or hold can be immediately unavailable to Vault. Gmail messages deleted more than 30 days before retention coverage expires are immediately purged at expiry; more recently deleted messages may have only the remaining part of that 30-day period. Preserve or export required data before coverage ends; do not wait for a grace period.
  • Holds outlast rules. Google notes: "Data under a legal hold is not purged." Holds are a legal tool, not a recovery plan, but they explain why some data survives when other data does not.
  • Powerful admin rights. Google cautions: "Vault admins have access to highly sensitive domain-wide data." It offers multi-party approval, in which "A notification is sent to a second admin in your organization that another admin has made an export request."

In our understanding, an attacker who gained a Vault administrator account could shorten rules or export data, so these accounts deserve the same protection as any backup administrator.

What Drive recovery gives you

For accidental deletion, administrators have a shorter, more direct tool. Google says: "As an administrator, you can recover deleted items from Google Drive within 25 days after a user empties their trash." After that: "Google purges those items from its systems and they can't be recovered."

The restore is by date range, not by file: "The restoration recovers all files removed during the selected date range." Google advises asking the user when they deleted the item "so that you can restore the least amount of data necessary." It may not be quick: "Depending on the amount of data that you want to restore, it might take several days for the data to reappear in the user's account."

In our reading, this handles everyday mistakes inside a short window. It does not help if an attacker or a faulty sync tool changes files rather than deleting them, or if the problem is found after 25 days.

What the Data Export tool gives you

Google's Data Export tool can export a whole organisation's data. Google says these steps "initiate a full export of your organization's data and are available in all Google Workspace editions."

Its limits, in Google's words:

  • Time. "Data export typically takes 72 hours but can take up to 14 days, depending on the size of your data export."
  • Deleted data. The export excludes "Deleted data, unless that data was retained or held by Google Vault policies."
  • Short storage by default. "The exported data is automatically deleted 60 days from the beginning of the export." To keep it longer, "you need to create a custom export and choose your own Cloud Storage bucket."
  • Cannot be stopped from the console. "Once you click Start export , the process cannot be canceled or stopped within the Google Admin console."
  • Who can run it. It requires "a Google Workspace or Cloud Identity super administrator account that is at least 30 days old".
  • Larger organisations. "If your organization has FedRAMP Authorization or more than 1000 users, contact Google Workspace support before you use the Data Export tool."

The export produces a copy outside the live service, which is closer to a backup. But it is a manual, point-in-time export, and Google's pages do not describe restoring it back into accounts (our reading).

What Takeout gives individual users

Individual users can download their own data through Google Takeout. For work accounts, Google notes: "Google Workspace administrators can manage if users can download data from different products." Takeout depends on each user acting and is not a managed organisation-wide copy (our understanding).

Read-only checks

These checks read settings in the Google Admin console and Vault; they change nothing. They involve no commands.

  1. What preserves each dataset? Inventory applicable retention rules and authorised holds. No rules alone does not mean no preservation; holds may cover data. Record the service, organisational unit, account/shared-drive and search-condition scope, and any coverage gaps.
  2. Who is licensed? Check which users and admins hold a licence that includes Vault.
  3. What would become eligible for purge? Review applicable custom/default periods, longest-custom-rule behaviour and service/ownership exceptions, with hold precedence. Ask the authorised legal owner to review any hold release or retention change before acting.
  4. Who can change the rules? List admins with Vault privileges to manage retention, and whether exports need a second admin's approval.
  5. How are departing users handled? Check whether staff accounts are deleted, suspended or kept, and whether that happens before data is preserved.
  6. Is there any copy outside Google? Record whether your organisation keeps an export or backup copy outside Workspace, and when it was last made.

These checks show the settings. They do not show whether you can put data back; a test does (our recommendation).

Safe restore rehearsal

Use an authorised test user, test shared drive and synthetic files only. Have an administrator with the required privileges supervise; never alter production retention or holds for this exercise.

  1. Test My Drive separately. Place the sample explicitly in the test user's My Drive. Delete it and empty that user's trash, then use Google's user Drive-recovery procedure within 25 days of trash removal. The admin restores all removed files in the chosen date range, not one selected file; record the range, privileges, elapsed time, sharing and result.
  2. Test shared-drive recovery separately. Use the documented shared-drive administration procedure with the Drive & Docs administrator privilege. For a test file, record when it leaves the shared drive's trash and stay within the separate 25-day recovery window. If testing deletion of the disposable shared drive itself, the drive must have been deleted within 25 days; to restore all its files, select the date it was deleted through the current date. Account for time zones and record the range and result. Vault retention does not extend the admin shared-drive recovery window.
  3. Test Vault export as a separate route. Under an authorised test preservation setup, search for the synthetic data and export it. Record which data was retained, its format and export time.
  4. Test the intended re-import process into the disposable account or shared drive. Record what content, metadata, sharing and permissions returned and what needed separate work.
  5. Keep the results separate. User recovery, shared-drive recovery and Vault export/re-import are different scopes. State what each test proved and any untested gap.

Diagnosing what you find

  • Vault finds nothing: check rule and hold coverage, search scope, licences and whether the user or data was removed before preservation. Absence of rules alone is not a diagnosis.
  • Drive recovery cannot get the file back: more than 25 days have passed; the file was changed rather than deleted; or it sat in a shared drive needing a different process.
  • The export cannot be put back easily: Vault exports are designed for review; email came out as PST or mbox; or permissions and sharing were not carried over.
  • Data is missing from a full export: it was deleted and not held by Vault; the export finished with errors; or the stored export had already expired.

Worked example (illustrative)

The following is invented. A firm discovers that a former employee's project folder was emptied three months ago. Drive recovery is outside its 25-day window. Vault has the files because a retention rule covered Drive, and an administrator exports them. Restoring them to a shared drive takes two days of manual work. The firm decides it needs a copy outside Workspace that can be restored directly, and changes its offboarding so accounts are preserved before deletion.

Risks and limits

  • Editions, licences and limits change; check current Google pages.
  • Behaviour described here comes from documentation, not a test.
  • Retention settings can have legal effects; take advice before changing them.

Sources

All accessed 14 November 2026.

Related future topics

  • Microsoft 365 native retention and restore limits
  • Offboarding staff without losing their data
  • Restoring a shared drive at scale

This article was originally published on .