Turbo replication is a Cloud Storage feature designed to asynchronously replicate newly written Cloud Storage objects associated with any insert, rewrite, copy, or compose operation—regardless of object size—to a separate region within a target of 15 minutes. Available for designated dual-region buckets, turbo replication offers a shorter, more predictable recovery point objective (RPO), helping to reduce data loss exposure.
Business continuity and disaster recovery
Turbo replication provides geo-redundancy for your Cloud Storage data within a target 15-minute window. While traditional storage models often rely on primary and secondary geographic locations, geo-redundancy simplifies the disaster recovery process by eliminating the need for users to redirect network usage between primary and secondary locations.
Cloud Storage uses Cloud Load Balancing to serve dual-region buckets from multiple regions. As a result, in the case of a regional outage, turbo replication is designed to substantially reduce the risk of data loss exposure to data written within the target of the last 15 minutes.
While dual-region storage and turbo replication help support business continuity and disaster recovery (BCDR) efforts, administrators should plan and implement a full BCDR architecture that's appropriate for their workload.
For more information, see Step-by-step guide to designing disaster recovery for applications in Google Cloud.
Should you use turbo replication?
Turbo replication provides the following benefits, backed by the Cloud Storage SLA:
Provides faster geo-redundancy for data in your dual-region buckets. Turbo replication reduces the risk of data loss exposure by targeting replication to a separate region within 15 minutes. Cloud Storage dual- and multi-region buckets include a default replication behavior designed to asynchronously replicate 99.9% of newly written objects to a separate region within a target of one hour—often most objects finishing replication within minutes. For users who require a shorter, more predictable replication target, turbo replication is designed to replicate 100% of newly written objects to a separate region within the recovery point objective of 15 minutes.
Helps support uninterrupted service following a regional outage. Cloud Storage always understands the current state of the bucket and will transparently serve objects from either region as required. As a result, dual-region buckets are designed to have a recovery time objective (RTO) of zero and temporary regional failures are normally invisible to users.
Turbo replication is only available for the specific dual-region buckets
NAM4. If you want to apply turbo replication to data stored in another bucket, you must move the data to an eligible bucket.
Turbo replication cannot be managed through the XML API, including creating a new bucket with turbo replication enabled.
When turbo replication is enabled on a bucket, it can take up to 10 seconds before it begins to apply to newly written objects.
Object writes that began prior to enabling turbo replication on a bucket replicate across regions at the default replication rate.
- Object composition that uses source objects subject to the default replication rate creates composite objects that are also subject to the default replication rate.
Objects uploaded using XML API multi-part uploads are always replicated using default replication and are not covered by the turbo replication SLOs defined in the Cloud Storage SLA.
Users can monitor turbo replication performance from the Google Cloud console.
Understanding RTO and RPO
The recovery time objective (RTO) is the window of time after the onset of an outage. It represents the maximum acceptable length of time before a service comes back online.
The recovery point objective (RPO) is the window of time prior to an outage. It represents the maximum acceptable length of time required to complete object replication. It also represents the amount of time that data could be considered "at-risk".
Data writes performed during the recovery point objective are considered at-risk because they might not have finished asynchronous replication to a separate region prior to a region outage. (Zonal replication within a region is synchronous, occurring immediately once an object upload is finalized.)
With the default replication behavior available in Cloud Storage, most objects finish replication in minutes. Turbo replication provides a more robust recovery point objective of 15 minutes or less, applying the objective to all object writes.
Any object that was successfully replicated to a separate geographic location should continue to be accessible if either region has an outage. However, any data that did not finish replicating remains unavailable until the downed region comes back online. Data could potentially be lost in the very unlikely case of physical destruction of the region.
Cloud Storage monitors the oldest unreplicated objects. If an object
took longer than 15 minutes to replicate, those extra or "bad" minutes are
displayed in the Google Cloud console as
Number of minutes missing RPO.
This number represents an aggregate of bad minutes from all objects in the
For example, if one object yielded 20 bad minutes from 9:00-9:20 AM, and another object yielded 10 bad minutes from 9:15-9:25 AM, the total number of bad minutes is 25 minutes, as at least one object missed the RPO from 9:00-9:25 AM. This service level indicator can be used to monitor your bucket's Monthly Replication Time Conformance. For more information, see the Cloud Storage SLA.
The Google Cloud console also tracks the number of completed object
replications, shown as
Object replications with turbo. This service level
indicator can be used to monitor the bucket's Monthly Replication Volume
Conformance. For more information, see the Cloud Storage SLA.
- Enable turbo replication on an existing bucket.
- Learn more about turbo replication pricing or see a pricing example.
- Learn how Cloud Logging tracks Cloud Storage operations such as enabling Turbo replication.
- Read the turbo replication Service Level Objectives (SLOs) in the Cloud Storage SLA.