Associate Data Practitioner

Compare backup and recovery solutions offered as Google-managed services

Cloud Storage and Cloud SQL each provide built-in, Google-managed options for backing up and recovering data, but they work differently because the services are designed for different types of data. For Cloud Storage, you use Object Versioning to keep previous copies of every object in a bucket. When an object is overwritten or deleted, the old version is preserved, and you can easily restore it. You can also set retention policies and bucket locks to prevent deletion for a fixed period, which protects against accidental or malicious data loss. For recovery, you either restore a previous version of an object or copy data from another bucket if you have set up a secondary copy.

For Cloud SQL, the managed service automatically creates daily backups of your database and stores them in Cloud Storage. These backups can be used to restore the entire database to any point in time within the retention window (usually up to seven days). You can also manually export the database to Cloud Storage for long-term archival or import a database dump to recover from a major failure. The key difference is that Cloud Storage’s versioning is focused on object-level protection, while Cloud SQL’s backups give you point-in-time recovery for the entire database. Your choice depends on how quickly you need to recover (RTO) and how much data loss you can tolerate (RPO). For a database, automated backups are the simplest way to meet those goals; for files, versioning is the standard approach.

Determine when to use replication

Replication in Cloud Storage and Cloud SQL creates copies of your data in separate locations to improve availability and protect against failures. For Cloud Storage, you can enable Cross-Region Replication (or dual-region/multi-region location types, discussed in the next section). Cross-Region Replication automatically copies every new object from a source bucket in one region to a destination bucket in another region. Use this when you need a full copy of your data to survive a region-wide outage, for example if you are building a disaster recovery plan that requires the data to be available in a different geographic area.

For Cloud SQL, replication works through read replicas. A read replica is a copy of the primary database that applies changes asynchronously. You can create a read replica in the same region (for high availability and to offload read queries) or in a different region (for disaster recovery). When you set up regional high availability for Cloud SQL, the service automatically creates a standby instance in a different zone within the same region and uses synchronous replication to keep it fully up to date. If the primary zone fails, the standby takes over with no data loss. For cross-region disaster recovery, use an asynchronous read replica in another region—this introduces a small delay (replication lag) but protects against a regional breakdown. Decide based on your tolerance for downtime and data loss: synchronous replication in the same region for high availability, asynchronous cross-region replication for disaster recovery.

Distinguish between primary and secondary data storage location type for data redundancy

Cloud Storage location types define where your data is physically stored and how it is replicated for redundancy. A region is a specific geographic area (like us-central1). Data is stored and replicated automatically across multiple zones within that region, so a single zone failure does not cause data loss. This is the most cost-effective option when low latency within one area is critical. A dual-region (such as us-central1 and us-east1) stores data in two distinct regions within the same continent. Data is still kept in separate zones within each region, and replication between the two regions provides higher availability and disaster recovery protection without the cost and latency of a multi-region. A multi-region (such as US, EU, or Asia) spans multiple geographic areas and offers the highest redundancy: data is stored in at least two regions separated by a continent, and it is geo-redundant across those regions. Multi-region is best for serving global users and surviving large-scale outages, but it costs more and may have higher read latency from distant locations.

For Cloud SQL, the primary database runs in a single zone by default. To achieve high availability, you can enable regional persistence, which creates a standby instance in a second zone within the same region. This is the equivalent of zone-level redundancy for a Cloud SQL instance. The primary and standby use synchronous replication, so no data is lost if the primary zone fails. For cross-region redundancy, you create a secondary copy using a cross-region read replica, which asynchronously replicates data to another region. Understanding these location types helps you choose the right balance of cost, availability, and latency. Use region or zone redundancy for applications that need minimal latency within one area, dual-region or cross-region replication for disaster recovery, and multi-region for global resilience.