Why "Google backs it up" is the wrong assumption

Google's infrastructure is genuinely excellent at not losing data on its end. Gmail runs across redundant data centers, and the odds of Google itself losing your mail to a hardware failure are close to zero. That's a real, valuable guarantee - and it's also not the guarantee most people think it is.

What it doesn't cover is you, or anyone with access to your Workspace domain, doing something to the data. A user deleting messages. An admin removing an account during offboarding and taking the mailbox with it. A mail filter someone set up two years ago that's been quietly archiving or trashing messages ever since. A phishing attack that gets a login and starts deleting evidence. None of that is a Google outage - it's normal use of an account, and Google's redundancy has nothing to say about it. This is the same shared-responsibility split you'd get from any cloud provider: they keep the platform running, you're responsible for what happens to your data on it.

The gap shows up most often in three places: employee offboarding (mailboxes get deleted or reassigned faster than anyone checks what's in them), account compromise (attackers routinely delete or forward-and-delete mail to cover their tracks), and simple human error (an admin cleaning up "unused" accounts, a user who thought they were deleting spam).

What Gmail and Workspace actually cover

It helps to know the actual numbers instead of a vague sense that "there's probably a safety net somewhere":

  • Trash: deleted messages sit here for 30 days, then are permanently removed. Emptying Trash manually skips straight to permanent.
  • Spam: same 30-day window, same permanent removal after.
  • Deleted user accounts (Workspace): admins get roughly 20 days to restore an accidentally deleted user and their data from the Admin console. Past that window, it's gone. And critically, this only applies to a deleted account - it does nothing for messages deleted inside an account that's still active.
  • Everything else: there's no native point-in-time recovery. You can't ask Gmail "show me this mailbox as it looked three months ago."

That last point is the one people are usually surprised by. Once a message is past Trash retention, or a mailbox has been reassigned to someone else, there is no button in the Google Admin console that gets it back. The data either exists somewhere you copied it to yourself, or it doesn't exist anymore.

Where Google Vault fits in - and where it doesn't

Google Vault gets mistaken for a backup product constantly, and it isn't one. Vault is an information-governance tool: it lets you place retention holds on mail so it can't be purged even if a user tries to delete it, and it gives legal and compliance teams a way to search and export data for litigation or investigations. That's a genuinely useful, different job.

What Vault doesn't give you is an independent copy of your data. The mail Vault is holding still lives inside your Workspace domain, governed by your Workspace licenses and admin access. If your domain gets suspended, if an admin account is compromised, or if someone with the right permissions deliberately removes a hold and the underlying data, Vault doesn't help - it was never a separate copy sitting outside that blast radius. It also isn't built for the day-to-day case of "restore this one person's mailbox to how it looked last Tuesday." It's a hold-and-search tool, not a restore tool.

Backing up one Gmail account with Google Takeout

If you're backing up a single personal Gmail account, Google Takeout is the built-in option, and it's genuinely fine for that use case as long as you understand what it is: an export, not a live backup.

  1. Go to takeout.google.com while signed into the account you want to export.
  2. Click Deselect all, then scroll down and check just Mail.
  3. Under Mail's settings, choose All mail data included, or narrow it to specific labels if you only need part of the account.
  4. Click Next step, choose a delivery method (email with a download link, or send it straight to Drive, Dropbox, OneDrive, or Box).
  5. Pick a frequency: a one-off Export once, or Export every 2 months for 1 year if you want six recurring snapshots instead of a single point in time.
  6. Set your file type and maximum archive size, then click Create export.
  7. Wait for the "your export is ready" email - it can take anywhere from minutes to a day or two depending on mailbox size - then download the .zip and unzip it to get an .mbox file.
  8. To actually read or search it, import the .mbox into a mail client that supports the format, like Thunderbird or Apple Mail.

Where this stops working is scale. Running Takeout for one account is a ten-minute job. Running it for forty employees, every few weeks, downloading and safely storing forty separate zip files, and knowing which export is current - that's not a workflow, it's an unpaid part-time job for whoever on your team draws the short straw. And even then, there's no way to take an .mbox file and drop a single message back into someone's live Gmail account. You'd be reconstructing a mailbox by hand.

Automating backup for a whole Workspace domain

This is the actual problem we built Bekap around: once you're responsible for more than one or two mailboxes, manual exports stop being a realistic backup strategy, and you need something that runs on its own, covers every mailbox in the domain, and writes into storage that's yours - not tied to whichever backup vendor's platform. Here's how the setup works end to end.

  1. 1

    Create your account and organization

    Sign up and verify your email, then name the organization your mailboxes and backups will live under. Billing is usage-based, by mailbox actively under backup - not a flat per-seat fee.

  2. 2

    Connect Google Workspace

    From the Backups page, connect your Workspace over OAuth using a super admin or delegated admin account. Bekap discovers every mailbox in the domain automatically - it never requests access to billing or your admin console settings, only what's needed to list and back up mail.

  3. 3

    Add your own storage

    Under Settings → Storage, add an S3-compatible bucket - AWS, Wasabi, Backblaze B2, MinIO, or any custom S3-compatible endpoint. Bekap tests that it can list, write, read, and delete objects before saving the connection, and your credentials are encrypted and never shown again.

  4. 4

    Assign storage to mailboxes

    A mailbox doesn't back up until it has a storage location assigned - bulk-assign one location to every mailbox at once, or split mailboxes across multiple buckets if that fits how you work.

  5. 5

    Backups run on their own

    Set the frequency (hourly, daily, or weekly) and which labels to include, and every assigned mailbox backs up on schedule from then on. Turn on bring-your-own-key encryption if you want backups unreadable to anyone without your passphrase, and set a retention window if you don't want to keep everything indefinitely.

Restoring is the part that actually matters when something goes wrong. From the Recovery page, search a mailbox by keyword, sender, or date range, select the messages you need, and either restore them straight into the live Gmail mailbox under a clearly labeled folder, or download them as a password-protected ZIP. You can see progress live, and past restores stay in a history you can refer back to. If you want to see the account creation flow specifically, Bekap's help center walks through it in more detail.

What to look for in a Google email backup tool

Whether you end up using Bekap or something else, these are the things worth checking before you trust a tool with your organization's mail:

Runs on a schedule automatically - not something anyone has to remember to trigger
Covers every mailbox in the domain from one place, not one account at a time
Writes to storage you own, so your data doesn't disappear if the vendor does - even though it's stored in their backup format, not raw Gmail exports
Restores a single message or a whole mailbox to a specific point in time - not just an export file
Lets you set retention per connection instead of forcing one policy on everyone
Keeps a record of who restored what and when, for when someone eventually asks

The common thread is independence: a backup that lives inside the same platform it's protecting, with no separate copy and no way to reach it if that platform locks you out, isn't really a backup. It's a second folder.