Google guarantees that Gmail and Drive stay available. It does not guarantee that a file one of your staff deleted in March is recoverable in June. Those are different promises, and the gap between them is where Australian businesses lose data they legally have to keep.
Backing up Google Workspace means holding an independent copy of your Gmail, Drive, Shared drives, Calendar, Contacts and Chat data, outside the tenancy and outside the control of the accounts that use it, that can be restored to a chosen point in time. Nothing included with a Workspace licence does that.
The shared responsibility line, stated plainly
Google is responsible for the infrastructure: keeping the service running, keeping the data centres up, protecting against hardware failure, and replicating your data so a disk or a site failure does not lose it.
You are responsible for what happens inside your tenancy: what your users delete, what an attacker who has your password deletes, what a departing employee takes or destroys, and how long you keep records you are legally obliged to keep.
Google’s replication is not a backup, because replication faithfully copies the deletion. If a file is gone from the live system, it is gone from every copy of the live system. The question is never whether Google still has your data somewhere. The question is whether Google will give it back to you, and for how long.
What Google actually retains, and for how long
These are Google’s published windows. They are shorter than most business owners assume, and they are not adjustable.
Drive trash: 30 days. By default, Drive permanently deletes files 30 days after a user moves them to their trash. The user can restore them during that window.
Admin recovery after the trash is emptied: 25 days. If a user empties their trash, an administrator can recover deleted Drive items for a further 25 days from the Admin console. After that, Google purges the items and states they cannot be recovered.
Deleted user accounts: 20 days. If you delete a user and do not transfer their files at the time, Google deletes those files 20 days later. Restoring the account inside that window is the only route back.
Deleted Gmail: a comparable window and no more. Admins can restore a user’s permanently deleted email for a limited period after deletion, and after that Google purges it.
Shared drives: deleting a shared drive removes its content, with a limited administrative restore window rather than an indefinite one.
Audit logs: mostly six months. Most log event types are retained for six months. Email log search is 30 days. Chrome reports are 12 months. Administrators cannot delete log event data or change how long it is kept.
Put those together and the practical position is this: you have roughly a month to notice an ordinary deletion, and slightly less if the deletion happened through an account that was then removed. If your only detection mechanism is somebody looking for a file, you will regularly miss the window.
Vault is not backup, and Google says so
This is the most expensive misunderstanding in the Google ecosystem, because Vault is genuinely good at its actual job.
Google Vault is an information governance and eDiscovery tool. It lets you retain, hold, search and export Gmail, Drive, Calendar, Chat, Meet recordings, Groups, Sites, Voice and Gemini data. It is included with Business Plus, Frontline Standard and Plus, Enterprise Standard and Plus, all Education editions, Enterprise Essentials and Enterprise Essentials Plus for domain-verified accounts, and G Suite Business, and it is available as an add-on licence for some other editions. Since 1 November 2025 administrators need a Vault licence themselves in order to use it.
Here is why it is not backup, in Google’s own terms.
Vault does nothing until you configure retention rules. Google states it directly: Vault does not retain data until you set up retention rules, and until you do, users can delete data and services can purge it on their normal schedule. A tenancy with Vault licensed and no rules configured has exactly the same recovery position as a tenancy without Vault.
Vault is not an archive. Google’s documentation says Vault retention rules are applied to the live data systems of the underlying services and that Vault is not a data archive. When a retention period ends and the data is not on hold, it is subject to normal deletion, and once purged it cannot be recovered by users or admins.
Vault deletes as well as retains. Retention rules cut both ways. A rule configured to purge data after a set period will purge it, permanently, on schedule. That is the intended behaviour for a governance tool and the opposite of what you want from a backup.
Vault exports, it does not restore. You can search retained data and export it. You cannot press a button and put a user’s Drive back the way it was on Tuesday. Recovering a mailbox from a Vault export is a manual reconstruction project, not a restore.
Vault dies with the licence. Google’s documentation warns that if you delete a user or a required licence, their data may be irreversibly purged and no longer available to Vault. A backup that disappears when you stop paying for the platform it protects is not an independent copy.
Vault is bounded by the tenancy. If you lose administrative control of the tenancy, you lose Vault along with everything else. That scenario is covered in losing admin access to the tenancy.
Vault is the right tool for legal hold, for eDiscovery, and for enforcing a retention policy. Use it for those. Do not put it in the recovery column of your business continuity plan.
The four scenarios that actually cause data loss
Ransomware and account compromise. The modern version does not encrypt a file server. An attacker takes a password, signs in, and works through Drive and Gmail from inside a trusted session. Files are deleted, shares are changed, mailbox rules are created. Google’s systems replicate every one of those actions correctly, because from the platform’s point of view an authenticated user is doing normal work. Your recovery position is the 30 day trash window and whatever the attacker did not bother to empty.
The malicious insider. Someone resigns badly and spends their notice period deleting or exfiltrating. Because they own the files, most of it is legitimate activity that no security control will block. Detection after the fact depends on Drive log events, which are retained for six months, and recovery depends on those same short windows.
Departing staff and the 20 day clock. This is the quiet one, and it is almost always self-inflicted. An employee leaves, someone deletes the account to stop paying for the licence, and nobody transfers the files. Twenty days later the data is gone, including files that were the only copy of a client project. Google’s own guidance is to transfer ownership of Drive files and Calendar events before deleting, or to suspend rather than delete, or to archive the account. A proper offboarding checklist prevents this entirely, and it is a five minute change to the process.
Ordinary human error found too late. A folder is deleted in the last week of the financial year and nobody notices until the accountant asks for it in October. There is no window left, no matter how good your excuse is.
The Australian angle you cannot configure your way out of
Record keeping. The ATO requires businesses to keep records that explain their transactions, generally for five years. Employment, contractual and industry-specific obligations frequently run longer. Google’s Drive and Gmail recovery windows are measured in weeks. Vault can hold data for five years if you configure a rule to do it, which is a governance answer rather than a recovery answer, and only on the editions that include it.
Privacy Act and the NDB scheme. Under the Notifiable Data Breaches scheme, loss of personal information counts alongside unauthorised access and disclosure. If personal information is destroyed and you cannot recover it, you may still have a notifiable breach on your hands and an assessment obligation the OAIC expects you to complete within 30 calendar days. Being able to say precisely what was lost, and to restore it, materially changes both the assessment and the notification.
Where the copy lives. If you take a third-party backup, ask where the backup itself is stored, because that answer may be different from where Workspace stores your live data. Workspace data regions offer United States, Europe or no preference, with no Australian option, so an Australian-hosted backup can end up being the only Australian copy you have. That question is worked through in where your business data actually lives.
What a real backup covers, and what to look for
We are not going to name a product, because the right one depends on your edition, your data volume and where you need the copy to sit. These are the criteria that separate a real backup from a file sync with good marketing.
Independent credentials and an independent blast radius. The backup must not be accessible with the Workspace admin credentials it is protecting. If compromising your super admin account also lets someone delete the backups, you have one copy, not two.
Coverage of everything, not just Drive. Gmail with labels and folder structure intact, My Drive, Shared drives, Calendar, Contacts, Chat, and Sites if you use them. Shared drives are the common gap, because they are owned by the organisation rather than a user and some tools skip them.
Point-in-time restore, not just latest. You need to restore to the day before the deletion, not to the current state. Daily is the minimum, more often is better.
Granular restore back into the tenancy. Restoring a single message to a single mailbox, or a folder to its original Drive location with permissions intact, without the user having to reimport a zip file. Export-only tools are recovery projects, not restores.
Retention you set, decoupled from your Workspace licence. If you need seven years, the backup should hold seven years regardless of whether the user is still licensed, still employed, or still exists.
Immutability and deletion protection. Backups that cannot be altered or deleted for a defined period, including by an administrator, so that an attacker who gets in cannot destroy the recovery path.
Data location you can specify and evidence. Ask where the data is stored, in writing, and ask what happens on termination.
A tested restore. An untested backup is a hypothesis. Restore something real, on a schedule, and document that you did. Cyber insurers and client security reviews increasingly ask for evidence of the test, not the policy.
The general architecture behind all of this is covered in how business cloud backup should be structured.
What to do this week
Check your Workspace edition and whether Vault is licensed and whether any retention rules exist, because a licensed Vault with no rules is a common and misleading finding. Check your offboarding process for the account deletion step and add a file transfer before it. Confirm someone owns the alerting so a mass deletion gets noticed inside days rather than months. Then decide whether a third-party backup is warranted, and if it is, scope it against the criteria above rather than on price alone.
Tightening the tenancy itself is a separate and complementary job, covered in hardening the tenancy itself and the Admin console settings that matter. Backup reduces the consequence of a bad day. Hardening reduces how often you have one.
We can tell you in one session what your current recovery position actually is, including which retention windows you are relying on without realising it. Call 1300 028 324 or start at techassist.au/contact.