Google-Managed Backup and Recovery Solutions

Cloud SQL (opens in a new tab) provides managed, incremental backups of a whole database instance, while Cloud Storage (opens in a new tab) acts as a durable destination for files and database exports that you manage yourself. Cloud SQL backups are encrypted by default with Google-managed keys or customer-managed encryption keys (CMEK) and are stored separately from the instance. Cloud Storage protection in this workflow comes from keeping copies and exports in buckets, including lower-cost tiers for infrequently accessed data.

1.1Cloud SQL Managed Backups

Cloud SQL managed backups are incremental copies that restore lost data to a Cloud SQL instance. Only the first backup is full-sized like the database, and each later backup contains only data that changed after the previous backup. Cloud SQL uses these backups for three peer purposes:

• Restore an instance to a previous state when the instance has a problem.
• Set up disaster recovery (DR) by creating a new instance using a backup in a different region or zone.
• Create multiple instances using backups for development, testing, and migration.

Cloud SQL offers two backup service options for each instance. Standard backups are created, managed, and stored in the same project as the Cloud SQL instance. Enhanced backups (opens in a new tab) are managed and stored in a centralized backup management project that leverages the Backup and DR Service, with enforced retention, granular scheduling, and monitoring.

1.2Cloud SQL Backup Types and Restore Workflow

Cloud SQL backup types define when a copy is taken and how it is used for recovery. You can take on-demand, automated, or final backups, depending on the backup option selected for the instance. On-demand backups can be created at any time, even without automatic backups enabled, which is useful before a risky operation. Automated backups run on a scheduled cadence such as hourly, daily, weekly, or monthly during a backup window, and final backups are the last backups taken at the time of instance deletion.

The Cloud SQL restore workflow returns data to a new or existing instance, not to individual tables. A vaulted restore offers three destination choices: restore to a new instance with a new instance ID, overwrite an existing instance selected from a list, or overwrite the source instance. Overwriting the source instance replaces all current data, including previous point-in-time recovery logs, and the overwritten data cannot be recovered later. Point-in-time recovery (PITR) (opens in a new tab) follows a stricter rule: PITR recovers an instance to a specific point in time and always creates a new instance, so PITR cannot be performed to an existing instance.

1.3Cloud SQL Retention, Replicas, and Integrity

Cloud SQL retention rules control how long a backup remains available for restore. For automated backups, retention can range from 1 day to 10 years depending on the backup option and retention policy. For on-demand backups, standard backups are stored indefinitely until manually deleted, while enhanced on-demand backups use custom retention up to 10 years defined in the backup plan.

Retained backups are on-demand and automated backups that remain at the project level after an instance is deleted. Retained backups become independent of the instance and can be restored to a new or existing Cloud SQL instance at any time. Automated retained backups are deleted on a rolling basis after deletion, for example 7 days later if retention was set to 7, while standard on-demand retained backups remain until manually deleted or the project is deleted. Restoring from a backup does not retain the IP address of a deleted instance, and recovery to the exact state at deletion requires contacting Google Cloud Customer Care within four days.

Backups are maintained only with the primary instance, so replica instances have no separate backups. If a replica is promoted to a standalone instance during failover or switchover, the promoted instance needs its own backup configuration and cannot access the primary instance backups. Cloud SQL (opens in a new tab) also performs background database integrity checks by restoring a sampling of customer-initiated backups or recovery backups in an offline process.

1.4Cloud Storage Role and Backups Compared to Exports

Cloud Storage is the recovery destination when you need file-level copies, selective exports, or long-term tiered retention. A common pattern is a scheduled task that transfers data to Cloud Storage, or a database export uploaded to Cloud Storage where you manage the lifecycle. For production workloads on Google Cloud, older backup data can move to Nearline, Coldline, and Archive storage classes because access is less likely. Those classes have lower storage cost but add retrieval costs and minimum storage durations.

Cloud SQL backups and Cloud Storage exports protect against different scenarios:

Choose a Cloud SQL backup when the goal is to restore the whole instance, clone for DR in another region or zone, or recover quickly from corruption. Choose a Cloud Storage export when the goal is to keep a copy after instance deletion, move only a single database or table, or retain data in a chosen storage class. Backup and restore cannot upgrade a database version, so a backup can be restored only to an instance with the same database version as when the backup was taken.

Cloud Storage (opens in a new tab) handles protection and redundancy for object data, while Backup and DR Service provides secure storage and centralized backup management at scale for virtual machines (VMs) and other workloads running in Google Cloud. Storage Transfer Service and Transfer Appliance move or copy data for backup and migration, and managed databases add scheduled backups and point-in-time recovery for data-level disasters. Data flows from writers and VM disks to geographically separated buckets, so deletion, corruption, or a regional outage does not remove the only copy.

2.1Protection Against Accidental or Malicious Deletion

Protection against deletion in Cloud Storage keeps objects recoverable and helps meet legal or regulatory retention needs. These controls apply inside the bucket where the data lives and act before data is permanently lost. They are best used together when data is critical to the business and must survive human error or malicious deletion.

• Object holds: Object holds place metadata flags on individual objects to prevent those objects from being deleted or overwritten.
• Soft delete: Soft delete retains recently deleted objects and buckets for a specified period before permanent deletion, and Cloud Storage enables soft delete by default with a seven day retention period.
• Object Versioning (opens in a new tab): Object Versioning automatically archives an overwritten or deleted live object as a noncurrent version that remains accessible in the bucket until explicitly removed.
• Bucket Lock: Bucket Lock defines a retention policy on a per-bucket basis that retains all objects in the bucket for a minimum duration and locks the policy so it cannot be reduced or removed.
• Object Retention Lock: Object Retention Lock defines retention on a per-object basis with an immutable retain-until date and time, so the specific object cannot be deleted or replaced until that duration expires.

Together the bucket-level and object-level controls create layers of defense, where soft delete and versioning support rollback after overwrites and ransomware events, while Bucket Lock and Object Retention Lock enforce compliance retention that users cannot shorten.

2.2Redundancy for Regional Outages and Business Continuity

Redundancy for Cloud Storage protects the business against data loss, disaster events, and regional outages by keeping copies in more than one place. Data flows from the writer to geographically separated locations, so a zone or region disruption does not remove the only copy. This automatic replication supports multi-region availability and fast cross-region recovery without manual copying.

Dual-regions (opens in a new tab) store data simultaneously in two geographically separate regions, and dual-regions and multi-regions automatically replicate data across regions for 99.99% availability. Turbo replication replicates 100% of newly written objects between both regions in a dual-region pair within 15 minutes, which defines a recovery point objective (RPO) of 15 minutes. Cross-bucket replication asynchronously replicates data from a source bucket to a destination bucket in a different location, which supports a separate recovery copy when the destination must be isolated from the source location.

2.3Backup and DR Service for Centralized Workload Recovery

Backup and DR Service is the Google-managed backup and disaster recovery (DR) service for VMs and other workloads running in Google Cloud. The service depends on Cloud Storage buckets for secure backup storage and provides centralized backup management at scale. Data flows from Persistent Disk snapshots of Compute Engine VMs to Cloud Storage buckets, where backups are stored, monitored, and restored.

Backup and DR Service also supports compliance and security operations through comprehensive monitoring, auditing, and reporting, plus insights into security threat events to help defend against ransomware and other risks. Partner backup solutions such as Veeam and Cohesity from Google Cloud Marketplace offer a similar centralized management and automation model for databases, but they require additional cost and vendor management. Choose Backup and DR Service when many VMs and workloads need one managed place for backup storage, oversight, and recovery.

2.4Transfer, Backup Retention, and Point-in-Time Recovery Options

Transfer and database recovery options extend backup and recovery beyond a single bucket or VM for migration, archiving, and surgical data repair. Storage Transfer Service is a managed, high-scale transfer service that migrates or replicates online data to, from, or between object and file storage systems, such as Cloud Storage, Amazon S3, and on-premises storage. Transfer Appliance uses ruggedized physical appliances to transfer large amounts of offline data, up to hundreds of petabytes, from on-premises to Cloud Storage.

Managed databases complement these services with two recovery patterns that differ in retention, speed, and cost. Scheduled backups can be taken daily or weekly, support a maximum retention period of 14 weeks, and restore to a new database in the same project at a lower restore cost than point-in-time recovery (PITR) data. Point-in-time recovery (PITR) (opens in a new tab) reads documents from up to seven days in the past at 1-minute granularity, with a recovery time objective of 0 and a recovery point objective of 1 minute, so only the required data can be written back. A PITR data export captures a timestamp from up to seven days in the past and saves the full database in Cloud Storage indefinitely for archiving, but recovering from that export is generally more expensive than recovering from a backup.

Google Cloud Backup and DR Services are Google-managed backup and recovery capabilities that protect data stored in Cloud Storage (opens in a new tab) and Cloud SQL (opens in a new tab). Cloud Storage acts as durable object storage for backup files and tiered archives, while Cloud SQL provides built-in incremental backups for managed database instances. Together they support restore to a prior state, disaster recovery (DR) in a different zone or region, and reuse of backups for development and testing.

3.1Cloud Storage for Data Backup and Recovery

Cloud Storage for data backup and recovery is an object store that is ideal for storing backup files and long-term archives. A common pattern is tiered storage, where production data flows from higher-cost storage into Nearline, Coldline, and Archive storage classes as access becomes less frequent. Nearline is designed for access at most once a month and is well suited for regular DR tests, while Coldline and Archive fit even less frequent access at lower storage cost.

Cloud Storage tiering involves a tradeoff because Nearline, Coldline, and Archive charge lower storage rates but add retrieval costs and minimum storage durations. Data or metadata retrieved before the minimum duration still incurs charges for the full duration. To protect backup objects in a bucket, Cloud Storage depends on Soft Delete, which preserves deleted and overwritten objects for a set period, and Object holds, which prevent deletion or updates to objects.

3.2Cloud SQL Backup Options

Cloud SQL backup options control where backups live and how retention and scheduling work. Every instance must use one backup option, and all backups after the first contain only data that changed since the previous backup. All backups are encrypted by default with Google-managed keys or customer-managed encryption keys (CMEK).

Cloud SQL backups can be used for three peer purposes:

• Restore an instance to its state at the time of the backup when the instance has a problem.
• Create a new instance from a backup in a different region or zone for disaster recovery.
• Create multiple instances from backups for development, testing, and migration.

3.3Creating Cloud SQL Backups

Cloud SQL backup creation supports on-demand, automated, and final backups. On-demand backups can be created at any time for any instance, whether automatic backups are enabled or not, which makes them useful before a risky change or when waiting for the next window is not acceptable. Automated backups run on a scheduled cadence such as hourly, daily, weekly, or monthly while the instance is running, and each backup starts during its configured backup window. Scheduling automated backups when the instance has less activity is recommended to reduce impact on performance.

Automated backup retention ranges from 1 day to 10 years depending on the Cloud SQL edition and backup option, with some engines starting at 7 days. Standard on-demand backups are kept indefinitely until manually deleted, while enhanced on-demand backups use custom retention up to 10 years defined in the associated backup plan. Cloud SQL also attempts to keep at least one daily recovery backup for every active instance when no good automated backup exists, and that recovery backup is available through Google Cloud Customer Care.

3.4Managing Retention and Backups After Deletion

Backup retention in Cloud SQL is defined by the backup request type and the selected backup option. When the oldest backup in an incremental chain is deleted, the next oldest backup grows to become the new full backup, and later incremental backups are adjusted to match it. The billable size of each backup can be viewed in the console, with the oldest backup close to full database size and later backups sized by the rate of data change.

Retained backups are on-demand and automated backups that remain after a Cloud SQL instance is deleted. Retained backups become independent of the instance, move to project-level storage, and can be restored to a new or existing Cloud SQL instance at any time. Retained backups are different from final backups, which are the last backups taken at the time of instance deletion.

Retention after deletion cannot be changed, and manually deleted retained backups cannot be recovered. Standard on-demand retained backups persist until deleted or until the project is deleted, while enhanced on-demand retained backups follow the backup plan retention rule. Automated retained backups are removed on a rolling basis of one backup per day, based on the retention setting before deletion, so a setting of 7 means the latest automated backup is deleted 7 days after deletion. For standard backups, retained backups include an instance_deletion_time field that identifies whether a backup belongs to a live or deleted instance when instance names are reused.

3.5Recovery, Point-in-Time Recovery, and Exports

Recovery in Cloud SQL restores data from a backup to a Cloud SQL instance, including recovery to a different zone or region for disaster recovery. Restoring from a backup does not retain the deleted instance IP address, but Cloud SQL keeps backups of deleted instances for four days so Customer Care can help recover the exact state including the IP address. Cloud SQL also runs automatic background integrity checks by restoring a sample of customer-initiated backups and recovery backups through an offline process.

Point-in-time recovery (PITR) and exports complement backups in a complete protection strategy. Backups are lightweight restores of the entire instance disk to the backup time, but a single database or table cannot be backed up alone. Point-in-time recovery recovers an instance to a specific moment before an error, such as accidental data loss, and point-in-time recovery always creates a new instance rather than overwriting the existing instance. Exports create an external file in Cloud Storage that can recreate selected databases or tables, take longer to create, survive instance deletion, and require the owner to manage the file lifecycle.

3.6Centralized Protection With Backup and DR Service

Centralized protection with Backup and DR Service backs up and recovers cloud and hybrid workloads with fast resumption of business operations. The service underlies enhanced backups for Cloud SQL and also protects self-managed databases such as MySQL, PostgreSQL, and SQL Server running on Compute Engine. A backup plan template from Backup and DR Service can be applied automatically to new Compute Engine instances using tags, so protection starts without manual configuration per virtual machine.

Backup and DR Service connects Compute Engine, Cloud Storage, and Cloud SQL into one dependency chain for disaster recovery. Database backup files and transaction logs flow from the source database to Cloud Storage for cold storage, and recovery recreates the database from those files plus later logs. Storage Transfer Service (opens in a new tab) supports this flow by importing data into Cloud Storage from Amazon S3, Azure Blob Storage, or on-premises sources, which lets Cloud Storage serve as the durable destination for backup copies across environments.

Key Facts

• Cloud SQL backups are incremental and encrypted by default, with only the first backup full-sized and later backups containing only changed data.
• Standard backups are stored in the same project as the Cloud SQL instance, while enhanced backups are stored in a centralized backup management project using the Backup and DR Service.
• Point-in-time recovery (PITR) in Cloud SQL always creates a new instance and cannot overwrite an existing instance.
• Cloud Storage enables soft delete by default with a seven day retention period, and dual-regions with Turbo replication replicate new objects within 15 minutes for a 15-minute RPO.
• A Cloud SQL backup restores the entire instance disk under Cloud SQL retention, while a Cloud Storage export saves selected databases or tables as owner-managed files that survive instance deletion.