Can I copy Google Cloud Storage to Hetzner with rclone?

Yes. This guide uses the native Google Cloud Storage backend as the source and the S3 backend with provider Hetzner as the destination. It covers current objects, not the complete transfer of every GCS service feature.

Does --metadata transfer all GCS metadata?

No. As of 19 October 2026, rclone lists no metadata-framework support for the native GCS backend. The flag alone therefore does not transfer arbitrary custom metadata. Required values need separate export, mapping and verification.

Are GCS IAM rules and signed URLs preserved?

No. Permissions and URLs must be configured for the target application. A successful object transfer does not confirm correct access control.

Does rclone copy transfer every old object generation?

No. This workflow copies the visible current object inventory. Historical generations, soft-deleted objects and retention rules require a separate plan.

Does an equal object count prove integrity?

No. Count and total size are inventory values. Content verification, metadata acceptance and application tests are separate checks. rclone check --download compares contents by reading both sides.

Does copy remove destination files deleted from the source bucket?

No. copy does not remove additional destination objects. Deletions between the initial copy and cutover must be reconciled explicitly so deleted content does not reappear.

Is returning to GCS just an endpoint change?

No, the application and access path must be switched back. Returning without transferring data back is possible only before new production writes occur at the destination. After that, new or changed destination objects and deletions must be reconciled consistently before switching back.

Is migration possible without additional transfer costs?

There is no general guarantee. GCS can charge for data transfer, reads and, depending on storage class, retrieval or minimum storage duration. Content verification also causes reads and data traffic.

Migrate Google Cloud Storage to Hetzner with rclone

Timo Wevelsiep02.11.2026

#GoogleCloudStorage
#Hetzner
#rclone

Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.

Plan GCS migration: Google Cloud migration to Hetzner covers assessment of storage, applications and cutover within the agreed scope. Arrange a consultation.

Migrating Google Cloud Storage to Hetzner Object Storage means switching both data and application access. This guide uses rclone with a native GCS remote as source and a Hetzner S3 remote as destination. It supplements the AWS S3 guide with GCS authentication, metadata and generation differences.

As of October 2026. The commands apply to existing buckets. Our recommendation: verify a bounded dataset and the target application first; switch production only after documented acceptance.

Define scope before the first copy
Configure GCS and Hetzner as separate remotes
Run initial and delta copies with copy
Handle metadata and generations separately
Accept content and application separately
Switch with a write freeze and preserve rollback
Our approach at WZ-IT
Further guides

Define scope before the first copy

We recommend an inventory per bucket: current objects, bytes, application owner, writing services, public access, required headers and historical data. Production upload storage has different acceptance criteria from an archive or backup destination.

Area	Establish before approval
Data scope	Current inventory or also old generations and deleted objects?
Application	GCS client library, stored URLs, signed downloads and uploads
Metadata	Content-Type, Cache-Control, Content-Encoding and business custom metadata
Protection	Private access, retention, deletion protection and key dependencies
Transition	Write freeze, deletion reconciliation, acceptance and return of new target data

Hetzner provides an S3-compatible interface, not a complete replacement for every GCS feature. Check required target features against the Hetzner feature overview. GCS IAM, Pub/Sub integrations and GCS-specific application paths are not object data copied by this workflow. Whether those dependencies can be replaced is an architecture decision.

Budget for initial transfer, repeated copies, verification reads and parallel storage. GCS storage class, region, retrieval and minimum storage duration can affect cost. Use the specific Cloud Storage pricing, rather than a universal egress assumption. The GCP traffic guide covers the cost question separately.

Configure GCS and Hetzner as separate remotes

The source migration identity needs read access to the relevant inventory. roles/storage.objectViewer includes storage.objects.get and storage.objects.list; grant it on the required bucket rather than unnecessarily across the project. Creating or listing all buckets is not part of the copying task. GCS IAM roles.

Use rclone config to create a remote named gcs with type google cloud storage. Use authentication approved for the runtime; the backend supports OAuth, service accounts and Application Default Credentials among other methods. Keep credentials out of the article, repository and shell history. Specific fields and conditions are in the GCS backend documentation.

For the destination, create the private bucket in Hetzner Console and configure hetzner with type s3 and provider Hetzner. Region and endpoint must match the bucket. An example for Falkenstein contains these non-secret values:

[hetzner]
type = s3
provider = Hetzner
region = fsn1
endpoint = fsn1.your-objectstorage.com
acl = private

Add Hetzner credentials through your protected configuration. These values are not a complete login. Do not use GCS credentials for the Hetzner remote. rclone Hetzner configuration, Hetzner S3 access.

Run initial and delta copies with copy

SOURCE_BUCKET and TARGET_BUCKET are placeholders. Start with a bounded test prefix in a designated target bucket. In particular, check object keys containing special characters and expected access paths from the application.

rclone version
rclone size gcs:SOURCE_BUCKET
rclone size hetzner:TARGET_BUCKET
rclone copy gcs:SOURCE_BUCKET hetzner:TARGET_BUCKET \
  --dry-run --log-level INFO --log-file gcs-copy-plan.log

After reviewing the plan, run the initial copy:

rclone copy gcs:SOURCE_BUCKET hetzner:TARGET_BUCKET \
  --log-level INFO --log-file gcs-copy-initial.log

copy skips files considered equal by its comparison rules and does not remove additional destination objects. It can overwrite differing destination objects with the same name. Use a separate migration destination where the application is not yet writing. A second run transfers detected changes, but does not produce a consistent snapshot of a source receiving concurrent writes. rclone copy semantics.

We recommend recording the command, rclone version, source and destination paths, start and end times, exit status and errors for each run. Treat logs as sensitive because object names can include business or personal information. Resolve errors and verify again before proceeding.

Handle metadata and generations separately

--metadata is not a complete solution here. As of 19 October 2026, the rclone backend matrix lists no metadata-framework support for the native GCS backend. The general metadata option cannot replace missing source support. Content type and modification time are separately supported properties; this does not establish transfer of arbitrary custom metadata or all HTTP headers.

We recommend exporting required values per object key separately, defining the destination model and verifying the mapping. For example, an individual source object can be described using the Google instructions:

gcloud storage objects describe gs://SOURCE_BUCKET/path/to/object \
  --format=json > source-object-metadata.json

This exports metadata for one object; it does not implement a complete metadata migration. When business IDs or cache headers are required, data transfer is ready for acceptance only after their documented transfer. Check values through the destination API and actual HTTP behaviour. Content comparison does not cover those properties.

GCS distinguishes current and noncurrent object generations. This guide's standard copy does not reproduce version history. Old generations, soft-deleted data, retention and key management require separate inventories and transfer strategies; GCS generation numbers do not become identical S3 version IDs. GCS Object Versioning. Change source retention only after business approval.

Accept content and application separately

Count and bytes provide an initial comparison, not proof of matching contents. GCS does not provide MD5 for every object, for example composite objects; an ETag is not a universally usable MD5 value either. GCS checksums, ETag conditions.

For the final quiescent inventory, we recommend comparing contents by reading both sides:

rclone check gcs:SOURCE_BUCKET hetzner:TARGET_BUCKET \
  --download --combined gcs-check-final.txt

check does not change object data; --download reads contents instead of relying on shared stored hashes. Without --one-way, additional destination objects are checked too. Budget for the extra reads and traffic. rclone check.

Our acceptance recommendation also covers metadata comparison, allowed and denied access, uploads, downloads, deletion, signed URLs and caching from the destination application. For backup data, include a restore attempt. A successful rclone exit status alone does not confirm those application properties.

Switch with a write freeze and preserve rollback

Our recommendation for a planned cutover:

Identify and stop all writers, including uploads, background jobs and deletion processes. Complete outstanding operations or abort them in a controlled manner.
Run copy again. Separately reconcile objects deleted at the source since the initial copy against the destination inventory and remove only approved destination leftovers. copy does not perform this deletion reconciliation.
Accept the now quiescent inventory, including metadata. Unresolved differences block the switch.
Switch the application to S3 access using the Hetzner endpoint, target bucket and destination permissions. Adapt GCS-specific client calls and old URLs accordingly.
Run application tests, then enable production writes exclusively at the destination. Document acceptance and switch time.

Initially preserve the source unchanged for rollback. After the first production write at the destination, changing the endpoint back is insufficient. Before returning, new destination data and deletions must be reconciled with writers stopped. Agree rollback criteria, owners and approval in advance. We do not recommend uncoordinated concurrent writes to both buckets.

Our approach at WZ-IT

For cloud migration from GCP to Hetzner, we define inventory, target architecture, data transfer, acceptance and cutover within the agreed scope. This includes decisions on historical data and metadata and adaptation of affected applications. Operational scope after migration is agreed separately.