GCS-Migration planen: Die Google-Cloud-Migration zu Hetzner umfasst die Einordnung von Storage, Anwendungen und Cutover im vereinbarten Umfang. Erstgespräch vereinbaren.
Google Cloud Storage zu Hetzner Object Storage migrieren heißt, Daten und Anwendungszugriffe zusammen umzustellen. Dieser Leitfaden verwendet rclone mit einem nativen GCS-Remote als Quelle und einem Hetzner-S3-Remote als Ziel. Er ergänzt den AWS-S3-Leitfaden um die Unterschiede bei GCS-Authentifizierung, Metadaten und Generationen.
Stand: Oktober 2026. Die Befehle gelten für bereits angelegte Buckets. Unsere Empfehlung: zuerst einen abgegrenzten Datenbestand und die Zielanwendung prüfen; erst nach dokumentierter Abnahme produktiv umschalten.
Inhaltsverzeichnis
- Umfang vor der ersten Kopie festlegen
- GCS und Hetzner als getrennte Remotes einrichten
- Erstkopie und Delta mit copy ausführen
- Metadaten und Generationen separat behandeln
- Inhalte und Anwendung getrennt abnehmen
- Mit Schreibstopp umschalten und Rückweg sichern
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Umfang vor der ersten Kopie festlegen
Unsere Empfehlung ist ein Inventar pro Bucket: aktuelle Objekte, Bytes, Anwendungseigentümer, schreibende Dienste, öffentliche Zugriffe, benötigte Header und historische Daten. Ein produktiver Upload-Speicher hat andere Abnahmekriterien als ein Archiv oder ein Backup-Ziel.
| Prüffeld | Vor der Freigabe klären |
|---|---|
| Datenumfang | Aktueller Bestand oder zusätzlich alte Generationen und gelöschte Objekte? |
| Anwendung | GCS-Clientbibliothek, gespeicherte URLs, signierte Downloads und Uploads |
| Metadaten | Content-Type, Cache-Control, Content-Encoding und fachliche Custom Metadata |
| Schutz | Private Zugriffe, Aufbewahrung, Löschschutz und Schlüsselabhängigkeiten |
| Übergang | Schreibstopp, Löschabgleich, Abnahme und Rückführung neuer Zieldaten |
Hetzner bietet eine S3-kompatible Schnittstelle, aber keinen vollständigen Ersatz aller GCS-Funktionen. Prüfen Sie die benötigten Zielmerkmale gegen die Hetzner-Funktionsübersicht. GCS-IAM, Pub/Sub-Anbindungen oder an GCS gebundene Anwendungspfade sind in diesem Ablauf keine kopierten Objektdaten. Ob diese Abhängigkeiten ersetzt werden können, ist eine Architekturentscheidung.
Kalkulieren Sie Ersttransfer, Wiederholungen, Prüflesevorgänge und parallele Speicherung. Bei GCS können Speicherklasse, Region, Abruf und Mindestaufbewahrung die Kosten beeinflussen. Verwenden Sie die konkrete Cloud-Storage-Preisliste, keine pauschale Egress-Annahme. Der GCP-Traffic-Leitfaden ordnet die Kostenfrage separat ein.
GCS und Hetzner als getrennte Remotes einrichten
Für die Quelle benötigt die Migrationsidentität Leserechte auf den betroffenen Bestand. roles/storage.objectViewer enthält storage.objects.get und storage.objects.list; vergeben Sie die Rolle am benötigten Bucket statt unnötig projektweit. Das Anlegen oder Auflisten aller Buckets ist nicht Teil der Kopieraufgabe. GCS-IAM-Rollen.
Richten Sie mit rclone config ein Remote namens gcs mit Typ google cloud storage ein. Verwenden Sie eine für die Laufzeit freigegebene Authentifizierung; das Backend unterstützt unter anderem OAuth und Service Accounts sowie Application Default Credentials. Hinterlegen Sie keine Zugangsdaten im Artikel, Repository oder Shell-Verlauf. Die konkreten Felder und Bedingungen stehen in der GCS-Backend-Dokumentation.
Für das Ziel legen Sie den privaten Bucket in der Hetzner Console an und konfigurieren hetzner mit Typ s3 und Provider Hetzner. Region und Endpoint müssen zum Bucket passen. Ein Beispiel für Falkenstein enthält diese nicht geheimen Werte:
[hetzner]
type = s3
provider = Hetzner
region = fsn1
endpoint = fsn1.your-objectstorage.com
acl = private
Ergänzen Sie die Hetzner-Zugangsdaten über Ihre geschützte Konfiguration. Diese Werte sind kein vollständiger Zugang. Verwenden Sie keine GCS-Zugangsdaten für das Hetzner-Remote. rclone-Konfiguration für Hetzner, Hetzner-S3-Zugriff.
Erstkopie und Delta mit copy ausführen
Die Namen SOURCE_BUCKET und TARGET_BUCKET sind Platzhalter. Beginnen Sie mit einem klar begrenzten Testpräfix in einem dafür vorgesehenen Zielbucket. Prüfen Sie insbesondere Objektschlüssel mit Sonderzeichen und erwartete Zugriffspfade aus der Anwendung.
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
Nach Prüfung des Plans folgt die Erstkopie:
rclone copy gcs:SOURCE_BUCKET hetzner:TARGET_BUCKET \
--log-level INFO --log-file gcs-copy-initial.log
copy überspringt nach seinen Vergleichsregeln bereits gleiche Dateien und entfernt keine zusätzlichen Zielobjekte. Es kann abweichende gleichnamige Zielobjekte überschreiben. Verwenden Sie deshalb ein getrenntes Migrationsziel, in das die Anwendung noch nicht schreibt. Ein zweiter Lauf überträgt erkannte Änderungen, erzeugt aber keinen konsistenten Snapshot einer gleichzeitig beschriebenen Quelle. Semantik von rclone copy.
Unsere Empfehlung: Pro Lauf Befehl, rclone-Version, Quell- und Zielpfad, Start- und Endzeit, Exitstatus sowie Fehler protokollieren. Behandeln Sie Logs als schützenswert, weil Objektnamen fachliche oder personenbezogene Angaben enthalten können. Fehler erst auflösen und erneut prüfen, bevor der Ablauf weitergeht.
Metadaten und Generationen separat behandeln
--metadata ist hier keine vollständige Lösung. Stand 19.10.2026 führt die rclone-Backend-Matrix beim nativen GCS-Backend keine Unterstützung des Metadaten-Frameworks auf. Die allgemeine Metadatenoption kann diese fehlende Quellunterstützung nicht ersetzen. Content-Type und Änderungszeit sind separat unterstützte Eigenschaften; daraus folgt keine Übernahme beliebiger Custom Metadata oder sämtlicher HTTP-Header.
Unsere Empfehlung: benötigte Werte je Objektschlüssel separat exportieren, das Zielmodell definieren und die Zuordnung prüfen. Ein einzelnes Quellobjekt lässt sich nach Google-Anleitung beispielsweise so beschreiben:
gcloud storage objects describe gs://SOURCE_BUCKET/path/to/object \
--format=json > source-object-metadata.json
Dies ist ein Metadatenexport für ein Objekt, keine Implementierung einer vollständigen Metadatenmigration. Werden fachliche IDs oder Cache-Header benötigt, ist die Datenkopie erst nach ihrer dokumentierten Übernahme abnahmefähig. Prüfen Sie Werte mit der Ziel-API und das tatsächlich ausgelieferte HTTP-Verhalten. Ein Inhaltsvergleich erfasst diese Eigenschaften nicht.
GCS unterscheidet aktuelle und nicht aktuelle Objektgenerationen. Die Standardkopie dieses Leitfadens bildet keine Versionshistorie ab. Alte Generationen, Soft-Delete-Daten, Retention und Schlüsselkonzepte benötigen eine gesonderte Inventarisierung und Übernahmestrategie; GCS-Generationsnummern werden nicht zu identischen S3-Version-IDs. GCS Object Versioning. Die Quellaufbewahrung erst nach fachlicher Freigabe ändern.
Inhalte und Anwendung getrennt abnehmen
Anzahl und Bytes sind ein erster Abgleich, kein Inhaltsnachweis. GCS stellt nicht für jedes Objekt einen MD5 bereit, etwa bei Composite Objects; ein ETag ist ebenfalls kein universell nutzbarer MD5-Wert. GCS-Prüfsummen, ETag-Bedingungen.
Für den endgültigen ruhenden Bestand empfehlen wir einen Inhaltsvergleich durch Lesen beider Seiten:
rclone check gcs:SOURCE_BUCKET hetzner:TARGET_BUCKET \
--download --combined gcs-check-final.txt
check verändert keine Objektdaten; --download liest die Inhalte statt sich auf gespeicherte gemeinsame Hashes zu verlassen. Zusätzliche Zielobjekte werden ohne --one-way ebenfalls geprüft. Planen Sie die zusätzlichen Lesezugriffe und den Datenverkehr ein. rclone check.
Unsere Abnahmeempfehlung umfasst zusätzlich: Metadatenabgleich, erlaubte und verbotene Zugriffe, Upload, Download, Löschung, signierte URLs und Caching aus der Zielanwendung. Bei Backup-Daten gehört ein Wiederherstellungsversuch dazu. Ein erfolgreicher rclone-Exitstatus allein bestätigt diese Anwendungseigenschaften nicht.
Mit Schreibstopp umschalten und Rückweg sichern
Unsere Empfehlung für einen geplanten Cutover:
- Alle schreibenden Dienste erfassen und anhalten, einschließlich Uploads, Hintergrundjobs und Löschprozessen. Offene Vorgänge abschließen oder kontrolliert abbrechen.
copyerneut ausführen. Seit der Erstkopie an der Quelle entfernte Objekte gesondert gegen das Zielinventar abgleichen und nur freigegebene Zielreste entfernen.copyerledigt diesen Löschabgleich nicht.- Den nun ruhenden Bestand einschließlich Metadaten abnehmen. Ungeklärte Unterschiede blockieren die Umschaltung.
- Anwendung auf S3-Zugriff mit Hetzner-Endpoint, Zielbucket und Zielberechtigungen umstellen. GCS-spezifische Clientaufrufe und alte URLs entsprechend anpassen.
- Anwendungstests ausführen, danach produktive Schreibzugriffe ausschließlich am Ziel freigeben. Abnahme und Umschaltzeit dokumentieren.
Für den Rückweg die Quelle zunächst unverändert erhalten. Nach dem ersten produktiven Zielschreibvorgang reicht ein Endpoint-Rückwechsel nicht mehr. Vor einer Rückkehr müssen neue Zieldaten und Löschungen bei gestoppten Schreibern nachvollziehbar zurückgeführt werden. Rückfallkriterien, Verantwortliche und Freigabe dafür vorab vereinbaren. Unkoordinierte parallele Schreibzugriffe auf beide Buckets empfehlen wir nicht.
Unser Vorgehen bei WZ-IT
Bei der Cloud-Migration von GCP zu Hetzner grenzen wir Bestand, Zielarchitektur, Datenübernahme, Abnahme und Cutover im vereinbarten Umfang ab. Dazu gehören die Entscheidung über historische Daten und Metadaten sowie die Anpassung betroffener Anwendungen. Der Betriebsumfang nach dem Umzug wird separat festgelegt.
Weiterführende Guides
- AWS S3 zu Hetzner Object Storage für eine S3-Quelle.
- GCP-Egress und Hetzner-Traffic für die Kostenabgrenzung.
- Migrationsübersicht für die Einordnung weiterer Workloads.
Datenübernahme und Umschaltung abgrenzen: GCP-Migration zu Hetzner mit Bestand, Abnahme und Rückweg planen. Termin vereinbaren.
