Skip to content
For the workloads covered here, Google Cloud offers four common native backup paths. Persistent Disk snapshots protect disks. Backup and DR Service protects VMs and several database and file workloads through backup vaults. Backup for GKE protects Kubernetes workloads. And Cloud SQL provides its own standard backup capabilities.
Your workload narrows the available options first. From there, one of the most important questions is: Where and how do you want the backup data stored?
That question decides your recovery options, your compliance position, and most of your bill.
What Google gives you natively
| Service | Protects | Where backups live | Immutable |
|---|---|---|---|
| Persistent Disk snapshots | Compute Engine disks | Your project | No native lock |
| Backup and DR Service | Compute Engine, Cloud SQL, AlloyDB, Filestore (console); VMware Engine, Oracle, SQL Server (appliance) | Google-managed backup vault | Yes, immutable and indelible |
| Backup for GKE | GKE clusters and volumes | Google-managed | Optional delete lock; up to 90 days |
| Cloud SQL standard backups | Cloud SQL instances | Google-managed; backups can be retained after instance deletion. | No |
Source for the Backup and DR rows: Google’s backup vault documentation.
Persistent Disk snapshots
Snapshots are incremental, so subsequent snapshots store changed data rather than another complete copy of the disk. You’re billed for the resulting snapshot storage rather than the full provisioned capacity of the source disk. They’re associated with your project, governed through your IAM permissions, and globally scoped by default, so you can use them to create disks in other regions unless you restrict restore locations.
What they don’t have is a retention lock. Anyone with delete permission on the snapshot can delete it, which is the whole problem in a ransomware scenario where the attacker has your credentials.
Snapshot schedules cover the automation. They don’t cover application consistency on their own, and they don’t rebuild the network a restored VM needs to land in.
Backup and DR Service
This is Google’s managed backup product, built on the Actifio technology Google bought in 2020. The important design decision is the backup vault.
A backup vault is a Google-managed, isolated storage resource that can be regional or, for supported workloads, multi-regional. Backups written to it are immutable (they can’t be altered) and indelible (they can’t be deleted before the retention period expires), and the enforced minimum retention is set when you create the vault. The vault’s minimum enforced retention can be configured for up to 99 years, although supported ranges vary by workload.
That’s genuinely strong ransomware protection. The trade-off is control over the storage layer. Backup vault storage is operated and isolated by Google rather than exposed as customer-managed snapshot or Cloud Storage resources.
The vault itself still exists within a Google Cloud project and is controlled through Google Cloud IAM. If your requirement specifically calls for backups to remain in customer-managed storage resources, the vault model may not meet it.
Workload coverage splits in two. Compute Engine instances and disks, Cloud SQL, AlloyDB and Filestore are managed from the Cloud console. VMware Engine VMs, Oracle and SQL Server go through the management console appliance.
Backup for GKE and Cloud SQL backups
Backup for GKE captures Kubernetes resource configuration and persistent volume data according to a backup plan. Cloud SQL supports automated and on-demand backups, with retention depending on the backup option you choose. Standard backups can be configured for retention after instance deletion, while enhanced backups integrate Cloud SQL with Backup and DR backup vaults.
The four decisions that actually matter
Where the data lives. Your project, or Google’s. This drives everything else, and it’s the one axis most comparison content skips.
Whether it can be deleted. PD snapshots can. Backup vault contents can’t, until retention expires. If you’re writing a ransomware recovery plan, that distinction is the plan.
How far the copy travels. A same-region copy doesn’t protect you from a region-wide outage. Cross-region protection adds geographic isolation. Cross-project isolation can also reduce the blast radius of a compromised production project when permissions are properly separated.
What you’re actually paying for. What you’re actually paying for depends on the service: snapshot or vault storage, service-specific management charges, retrieval fees for archive snapshots, and network transfer when data crosses locations can all apply. The pricing breakdown walks through those components with a worked example.
Where third-party backup fits
Native tooling is a reasonable default for GCP-only environments whose workload coverage, isolation and storage-control requirements are met by Google’s native services.
Teams usually go looking for something else when one of these shows up:
- Backups must stay in storage the customer owns, for sovereignty or contractual reasons
- One backup policy has to cover GCP alongside AWS or Azure, from one console across clouds
- Cross-cloud copies are the air gap requirement, which native GCP can’t satisfy
N2W (formerly N2WS) covers the first two on GCP as of version 5.0. The software runs inside the customer’s own GCP project, so snapshots stay in the customer’s account rather than a managed vault, and GCP Compute Engine VMs and disks sit in the same console and the same policy model as the customer’s AWS and Azure workloads.
Worth being precise about the scope, because it’s narrower than N2W’s AWS and Azure coverage: GCP support at 5.0 is Compute Engine VMs and disks. Cloud SQL, GKE and Filestore aren’t covered, and cross-project VM recovery isn’t there yet, so Google’s own service is the better fit for anyone whose GCP estate is broader than VMs or whose DR plan depends on recovering into a second project.
Related content: AWS vs Azure vs Google Cloud
FAQ
No, not until you configure it, and what “configured” means differs by service. Compute Engine disks need a snapshot schedule or another backup configuration attached. Cloud SQL automated backups are configured when you create the instance. Backup and DR can protect new resources automatically using a default backup plan, once you’ve set that plan up.
Persistent Disk snapshots are project resources, with snapshot data stored in the location you configure. Backup and DR uses Google-managed, isolated backup-vault storage; the vault itself is created in a Google Cloud project and governed through IAM.
Persistent Disk snapshots can be deleted by anyone with the right IAM permission. Backups in a Backup and DR vault can’t be deleted before the vault’s enforced minimum retention expires, which is set at vault creation and ranges from 1 day to 99 years.
A standard Persistent Disk snapshot is a point-in-time copy of a disk that lives in your project with no retention enforcement. A backup, in the Backup and DR sense, is a managed copy in a vault with an enforced retention policy, application awareness for supported databases, and its own catalog.
Not necessarily. Native Google Cloud services may be enough if they meet your workload coverage, retention, isolation and operational requirements. A third-party platform becomes more relevant when you need capabilities such as unified backup management across GCP, AWS and Azure or a different storage/control model.