Does Google Cloud back up your data? Shared responsibility explained

What is the Google Cloud shared responsibility model?

It's the split between what Google secures and what you secure. Google is responsible for the underlying network and infrastructure; you are responsible for everything you put on it and how you configure access to it.

Picture a team that has moved its ERP and Cloud SQL databases to Google Cloud. Then an engineer runs a clean-up script against the wrong project. Google's infrastructure performs perfectly, and the data is still gone. That is the gap this article is about, and it's why we treat cloud workloads as part of your backup as a service strategy rather than something the provider handles.

Google's Architecture Framework page on shared responsibility and shared fate is explicit: the provider "always remains responsible for the underlying network and infrastructure", while customers "always remain responsible for their access policies and data". Google's "shared fate" layer adds secure blueprints and defaults, but it doesn't move ownership of your data back to Google.

• Google: data centres, hardware, network and the availability of managed services.
• You: your data, IAM roles, project settings, retention and your ability to restore.

What do Google Cloud's native protections actually cover?

Google offers several useful safety nets, but each one protects against a specific failure and each one has limits. None of them is an independent copy outside Google's control.

According to Google's Cloud Storage soft delete documentation, soft delete is on by default with a 7-day retention, and when a project is deleted, buckets are kept only for the soft delete duration or the project recovery window, whichever is shorter. Buckets without soft delete "might be deleted immediately when a project is deleted". The Resource Manager documentation confirms that soft-deleted projects are fully deleted after 30 days.

These windows suit a mistake noticed the same week, not one found after a month-end close or a long intrusion.

What can still go wrong with data in Google Cloud?

Most data loss in the cloud comes from what happens on top of the infrastructure: people, credentials, configuration and, occasionally, the provider's own processes.

1. Human error. A deleted bucket or a Terraform run against the wrong environment, copied to every zone by replication.
2. Compromised credentials. An attacker with an Owner role or a highly privileged service account key can delete snapshots, shorten retention and remove projects through legitimate APIs. The Verizon 2025 Data Breach Investigations Report found ransomware present in 44% of the breaches it analysed, and attackers routinely go after recovery options first.
3. Misconfiguration. Broad IAM bindings or a lifecycle rule that deletes objects too early. No uptime commitment covers these.
4. Provider-side error. Rare, but real. In 2024 Google Cloud explained that a blank parameter in an internal tool caused one customer's Google Cloud VMware Engine private cloud to be deleted after a default one-year term.

That last customer was the Australian pension fund UniSuper. We cover the incident and its lessons in detail in what the UniSuper deletion teaches about third-party backup.

Is Google Cloud Backup and DR enough on its own?

For day-to-day restores it is a solid tool, and you should use it. As your only copy, it leaves you dependent on one provider for both production and recovery.

Google's Backup and DR overview describes a managed service for Compute Engine, Persistent Disk, Filestore, VMware Engine VMs, Cloud SQL, AlloyDB and self-managed databases. Its backup vaults are "Google-managed, isolated storage resources" with write-once-read-many immutability and an optional enforced minimum retention of up to 99 years. That is a real improvement over plain snapshots.

What it doesn't change is who operates it. Production and backup share one provider, one contract and one jurisdiction, so a failure at that level hits both. At UniSuper, the joint statement from UniSuper and Google Cloud said backups "with an additional service provider" minimised data loss and significantly improved the ability to restore.

The same applies elsewhere: see why data in AWS isn't a backup yet and why multicloud is not a backup strategy.

Does an EU region make your Google Cloud data sovereign?

No. An EU region gives you data residency, meaning the servers are in Europe. Sovereignty is about who can be legally compelled to hand the data over, and Google is a US company.

The US CLOUD Act of 2018 added 18 U.S.C. § 2713, which requires US providers to disclose data in their "possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States". On the EU side, Article 48 of the GDPR says a third-country court order to transfer personal data is only recognised or enforceable when it's based on an international agreement such as a mutual legal assistance treaty. A backup with the same US provider shares production's exposure.

For organisations in scope of NIS2, Article 21(2)(c) of Directive (EU) 2022/2555 requires "business continuity, such as backup management and disaster recovery", and Article 21(2)(d) adds supply chain security. Keeping a copy with an EU operator outside your primary provider addresses both. Read more in what data sovereignty means in practice.

How do you build an independent backup for Google Cloud?

Keep Google's native tools for quick operational restores, and add one copy that lives outside Google Cloud, can't be altered, and is tested. Five steps get you there.

1. Map what matters. List the projects, VMs, databases and buckets your services depend on, and agree how much data loss and downtime each can tolerate. RPO is how much work you can afford to lose; RTO is how long you can be down. Our guide to RTO and RPO explains how to set both.
2. Harden the native layer. Raise soft delete retention, use vaults with enforced retention and restrict Owner roles.
3. Add an off-platform copy. Follow the 3-2-1-1-0 rule: three copies, two media, one off-site, one immutable or air-gapped, zero errors on verification.
4. Separate the credentials. The account that can delete production should not be able to delete the backup.
5. Test restores. Restore a VM and a database to an isolated environment on a schedule, and keep the results as evidence.

With Mindtime backup for Google Cloud, the off-platform copy is stored only in our own Tier III data centres in the Netherlands and Germany, under EU law and independent of US hyperscalers. Backups are immutable with Object Lock plus an air-gapped copy, every backup job is checked automatically, backups are scanned for malware and admin actions require MFA. We're ISO 27001 and NEN 7510 audited.

What to do next

Using Google Cloud is a sound decision. Assuming it backs up your data is not. Your data, access controls and ability to restore remain your responsibility, and the safest way to meet it is a tested, immutable copy outside Google's platform, under EU law.

This week, check your soft delete retention, who holds Owner rights, and when you last restored from a copy Google doesn't operate. Then see how an independent copy fits into your wider backup as a service approach.

Want to see it working against your own environment? Book a free 15-minute demo and we'll walk you through a Google Cloud restore.

This article is information, not legal advice.