Some or all of the information on this page might not apply to Cloud de Confiance by S3NS. See Differences from Google Cloud for more details.

Bucket relocation

This document describes how Cloud Storage bucket relocation helps you to relocate buckets serverlessly between geographic locations. Using bucket relocation, you can move an existing bucket from one location to another without changing the bucket's name or requiring manual transfer of data within the bucket.

Before you begin the relocation process, plan your bucket relocation to minimize disruption. For instructions about how to perform the relocation, see relocate buckets.

Benefits

The benefits of bucket relocation are as follows:

Simplified migration: you can relocate buckets with minimal operational overhead. No complex scripting or multi-step processes are required.
Continuous operation: your applications remain accessible throughout the relocation process, with no downtime for read operations and minimal downtime for write operations.
Improved performance: colocating Compute Engine and Cloud Storage resources within the same region can reduce latency and enhance performance.
Metadata preservation: the bucket relocation process retains the object metadata. Retaining the object metadata maintains compatibility with existing applications and workflows after the bucket is moved.
Storage class configurations: you can maintain existing Cloud Storage class settings, including Autoclass. Preserving the storage class helps to keep your cost structure consistent after the relocation.

Note: If your bucket uses legacy storage classes, they are converted to Standard storage class during the bucket relocation process.

Use cases

The following are use cases you can achieve by relocating your buckets:

Reduce data transfer cost: avoid data transfer costs by relocating your bucket closer to the workloads accessing the bucket's data. For example, if your data is stored in the United States and primarily accessed from Europe, you can move your bucket to a European location to reduce data transfer costs.
Improve performance: improve your application's speed and response by moving your data closer to your Compute Engine workloads. For example, if your application runs in us-central1 but your data resides in asia-east1, you can relocate your bucket to us-central1 to reduce latency.
Enhance resilience: safeguard your critical data from regional outages. For example, if your data is stored in a single region, you can relocate it to a dual-region or multi-region for increased availability and disaster recovery.

Relocation types

There are two types of bucket relocations:

Bucket relocation with write downtime: in bucket relocation with write downtime, there is a period where you can't perform object write operations during the bucket relocation process.
Bucket relocation without write downtime: in bucket relocation without write downtime, you can continue to perform object write operations without interruption while the bucket relocation happens in the background.

The bucket's source and destination locations determine whether a bucket relocation involves write downtime. The following table shows how your bucket's location affects write downtime during a relocation, including the differences between relocations with and without downtime.

Specification	Bucket relocation with write downtime	Bucket relocation without write downtime
Bucket location	Relocating a bucket between the following locations causes downtime: Regions Dual-regions Multi-regions Multi-regions and predefined dual-regions Multi-regions and configurable dual-regions if the two locations have different multi-region codes	Relocating a bucket between the following locations causes no downtime if the two locations share the same multi-region code: Configurable dual-regions Multi-regions and configurable dual-regions
Write availability	You can't perform write operations during the final synchronization step.	Write operations continue uninterrupted during the relocation. Note: Policy changes with no write downtime take at least seven days to complete because they must wait for in-flight resumable uploads to finish first.
User involvement	You must initiate the write downtime finalization step.	No explicit finalization step is required.
Performance impact	You can't write or update objects in the bucket during the final synchronization step.	Object read and write latency might increase during the relocation.
Bucket relocation cancellation	Faster than relocations without write downtime.	Cancellation isn't instantaneous and can take longer due to the need to backfill objects.
Feature support	Provides less feature support than relocations without write downtime. For more information about the unsupported features, see Unsupported features.	Limitations exist for features such as multipart uploads, retention policies, Firebase, and appspot. For more information about these limitations, Review the bucket compatibility requirements and limitations.
Minimum relocation duration	None	Seven days

Understand the bucket relocation process

Bucket relocation helps you move your data from a source bucket to a destination bucket. The source bucket holds the data that you want to move and the destination bucket is where you want to move your data.

The following diagram shows the bucket relocation process flow:

^* Final synchronization is only required for relocations with write downtime.

The following table lists the three primary steps and the description for each step:

Step	Description
Perform a dry run (Optional)	Simulates the bucket relocation process to identify potential issues before the actual data transfer begins. Note: We recommend you perform a dry run as it allows for the early detection of potential problems without impacting the actual relocation process.
Initiate the relocation step	Copies data from the source bucket to the destination bucket. The bucket metadata is write-locked to prevent any changes to the bucket that might affect the relocation process. However, you can write, modify, and delete objects in the bucket. The factors influencing the duration are as follows: The frequency of object updates, deletions, or additions within the bucket directly impacts the copy duration. A higher rate of change requires more time. There's a maximum object movement rate `Rm, objects/second`. With `N` total objects and an update rate of `R objects/second`, the copy step duration can be estimated as `N / (Rm - R)` seconds. Large buckets require more relocation time due to finite bandwidth. The size of individual objects affects the copy time. Objects larger than 10 GB take longer to transfer than objects under 10 GB due to bandwidth constraints. For example, a 1 TB object takes one day to copy.
Initiate the final synchronization step (Only required for relocations with write downtime)	Once you initiate the final synchronization, the bucket is write-locked. As a result, you can't write or update any objects within the bucket during this time, preventing data inconsistencies. However, you can continue to read from the bucket. Note: During the final synchronization step, attempts to update objects in the bucket result in an HTTP `412` error. The error indicates that the bucket is undergoing a bucket relocation operation and has a write-lock in place, restricting any modifications to its objects. To successfully update the objects, it is necessary to defer the action until the ongoing bucket relocation operation and the associated synchronization process conclude. Upon completion, the write operations to the bucket are permitted. Once all data has been transferred, verified, and the bucket is operational in the new location, the write-lock is automatically removed. You can then resume writing and updating objects in the bucket.

Step

Description

Perform a dry run
(Optional)

Simulates the bucket relocation process to identify potential issues before the actual data transfer begins.

Initiate the relocation step

Copies data from the source bucket to the destination bucket. The bucket metadata is write-locked to prevent any changes to the bucket that might affect the relocation process. However, you can write, modify, and delete objects in the bucket. The factors influencing the duration are as follows:

The frequency of object updates, deletions, or additions within the bucket directly impacts the copy duration. A higher rate of change requires more time. There's a maximum object movement rate `Rm, objects/second`. With `N` total objects and an update rate of `R objects/second`, the copy step duration can be estimated as `N / (Rm - R)` seconds.
Large buckets require more relocation time due to finite bandwidth.
The size of individual objects affects the copy time. Objects larger than 10 GB take longer to transfer than objects under 10 GB due to bandwidth constraints. For example, a 1 TB object takes one day to copy.

Initiate the final synchronization step
(Only required for relocations with write downtime)

Once you initiate the final synchronization, the bucket is write-locked. As a result, you can't write or update any objects within the bucket during this time, preventing data inconsistencies. However, you can continue to read from the bucket.

Once all data has been transferred, verified, and the bucket is operational in the new location, the write-lock is automatically removed. You can then resume writing and updating objects in the bucket.

Limitations

To relocate your bucket, verify that your bucket's configurations support relocating buckets by reviewing the list of unsupported features and compatibility requirements.

Bucket relocation isn't supported if the source and destination buckets are in the following locations:

Location type	Unsupported locations
Regions	`ME-CENTRAL1` `ME-WEST1`

Pricing

For details on pricing associated with bucket relocation, see Cloud Storage pricing.

What's next

Learn how to plan a bucket relocation.
Learn how to relocate buckets.