Spaces zu Hetzner migrieren: Die DigitalOcean-zu-Hetzner-Migration umfasst Datenübernahme, Zielarchitektur und Cutover im vereinbarten Umfang. Erstgespräch vereinbaren.
DigitalOcean Spaces zu Hetzner Object Storage migrieren heißt: Objekte übertragen und die verwendeten Speicherfunktionen getrennt abnehmen. Dieser Leitfaden behandelt den aktuell sichtbaren Objektbestand mit rclone. Stand: Oktober 2026. Die Befehle sind Vorlagen für eine Testmigration.
Inhaltsverzeichnis
- Funktionsgrenzen vor der Migration prüfen
- Inventar und Zugriffe vorbereiten
- Zwei rclone-Remotes konfigurieren
- Erstkopie und finalen Abgleich trennen
- Inhalte und Anwendung getrennt abnehmen
- CDN und eigene Domain gesondert umstellen
- Rollback vor dem Cutover festlegen
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Funktionsgrenzen vor der Migration prüfen
Hetzner ist eine mögliche DigitalOcean-Spaces-Alternative, wenn die tatsächlich genutzten Funktionen zum Ziel passen. Die folgende Liste beschreibt Grenzen des Ziels; sie behauptet nicht, dass Spaces jede ausgeschlossene Funktion anbietet.
| Funktion am Ziel | Konsequenz für die Planung |
|---|---|
| Keine nativen Custom Domains für Buckets | Eigene Domain über eine gesonderte Auslieferungsschicht planen |
| Keine native Bucket-Replikation | Benötigte Kopierjobs und deren Überwachung getrennt planen |
| Kein Tagging | Tag-basierte Anwendungslogik vor dem Umzug ersetzen |
| Kein S3-Website-Feature | Website-Endpunkte gesondert ersetzen |
Diese Grenzen stehen in den unterstützten S3-Aktionen. Hetzner Object Storage ist zudem kein CDN. Bei hoher öffentlicher Auslieferung ist deshalb ein eigener CDN-Entwurf Teil der Zielwahl.
Entscheidung: Ohne passenden Ersatz für eine benötigte Funktion den Cutover zurückstellen. Für die allgemeine Anbieterwahl dient der DigitalOcean-Hetzner-Vergleich; hier geht es um den Speicherpfad.
Inventar und Zugriffe vorbereiten
Erstellen Sie ein Migrationsinventar: Bucket, Region, Prefixe, Objektzahl und Datenvolumen; daneben Writer, öffentliche URLs, Signierung, CORS, Lifecycle-Regeln und Anforderungen an die Versionshistorie. Notieren Sie, welcher Bestand verbindlich sein soll und wie Löschungen während der Erstkopie erfasst werden.
Spaces unterstützt Bucket-Versionierung über die API. Ein normaler Kopierlauf ist deshalb kein Nachweis einer vollständigen Historienmigration. Planen Sie diese separat, falls alte Versionen oder Delete-Marker erhalten bleiben müssen. Spaces-S3-Kompatibilität.
Verwenden Sie für die Quelle nach Möglichkeit einen auf den betroffenen Bucket begrenzten Leseschlüssel. Bei bestehenden PutBucketPolicy-Policies sind eingeschränkte Schlüssel nicht kompatibel; prüfen Sie dann einen geeigneten Zugangspfad, ohne produktive Policies ungeprüft zu ändern. DigitalOcean bietet unter anderem objektbezogene Leseberechtigungen an. Prüfen Sie die tatsächlichen Rechte vor dem Lauf. Spaces-Zugriffsschlüssel. Den Zielbucket vorab privat anlegen; Konfiguration und Leserechte am Ziel getrennt vergeben. Secrets gehören in eine geschützte lokale Konfiguration, nicht in ein Repository oder einen geteilten Befehlsverlauf.
Zwei rclone-Remotes konfigurieren
Mit rclone config zwei Remotes anlegen. Für Spaces s3 und Provider DigitalOcean wählen; der Endpunkt enthält die Quellregion. Spaces-Konfiguration. Für Hetzner folgen Sie dem CLI-Leitfaden, der provider = Other dokumentiert. Beispiele ohne Zugangsdaten:
[spaces]
type = s3
provider = DigitalOcean
endpoint = fra1.digitaloceanspaces.com
[hetzner]
type = s3
provider = Other
endpoint = fsn1.your-objectstorage.com
region = fsn1
acl = private
Endpunkte und Hetzner-Region durch die tatsächlichen Standorte ersetzen und die jeweiligen Schlüssel über rclone config hinterlegen. spaces:source-bucket und hetzner:target-bucket stehen im Folgenden für bestehende Buckets. Erst einen abgegrenzten Testbestand verwenden und dessen Upload, Download und Header abnehmen.
Erstkopie und finalen Abgleich trennen
Prüfen Sie die Richtung zuerst im Trockenlauf, danach folgt die Erstkopie:
rclone copy spaces:source-bucket hetzner:target-bucket --metadata --dry-run
rclone copy spaces:source-bucket hetzner:target-bucket --metadata --log-file=spaces-initial.log --log-level=INFO
copy entfernt keine überzähligen Zielobjekte. Der --metadata-Schalter fordert Metadatenübernahme an; Bucket-Konfiguration ist ein eigener Arbeitsschritt. Legen Sie für diese Migration einen eigenen Zielbucket fest und verhindern Sie dort produktive Schreibzugriffe bis zur Abnahme.
Für den Abschluss empfehlen wir diese Reihenfolge: alle Writer anhalten, laufende Uploads beenden lassen, Hintergrundjobs und automatische Löschungen berücksichtigen, dann den finalen Lauf ausführen. Bei unklaren Änderungszeiten oder fehlenden gemeinsamen Hashes ist eine vollständige erneute Kopie die vorsichtige Variante:
rclone copy spaces:source-bucket hetzner:target-bucket --metadata --ignore-times --log-file=spaces-final.log --log-level=INFO
--ignore-times überträgt die Dateien erneut, statt sie aufgrund des normalen Vergleichs zu überspringen. Das verursacht erneuten Transfer; reservieren Sie dafür Kapazität und berücksichtigen Sie die Abrechnung beider Anbieter. copy-Optionen.
Prüfen Sie anschließend eine Liste aller nur am Ziel vorhandenen Keys gegen das Löschprotokoll. Solche Altobjekte dürfen nicht als aktuelle Dokumente wieder sichtbar werden. Löschungen einzeln freigeben; keine pauschale Synchronisierung mit Löschrechten auf einen ungeprüften oder anderweitig genutzten Zielbestand anwenden.
Inhalte und Anwendung getrennt abnehmen
Ein Inhaltsvergleich kann beide Bestände vollständig lesen:
rclone check spaces:source-bucket hetzner:target-bucket --download --combined=spaces-check.txt
check --download vergleicht die Daten beider Remotes streamend. Exit-Status und Differenzbericht gehören zur Abnahme; ein beendeter Kopierlauf allein reicht nicht. Die Prüfung erzeugt weitere Lesezugriffe und Datentransfer.
Zusätzlich empfehlen wir eine separate Prüfliste: Header und benutzerdefinierte Metadaten, private und öffentliche Zugriffe, Upload aus der Anwendung, Browserzugriff mit CORS, signierte URLs und Cache-Verhalten. Ein Bytevergleich belegt diese Eigenschaften nicht. Die S3-Metadatenliste von rclone nennt unter anderem Content-Type, Content-Encoding und Cache-Control. ETags dürfen bei Multipart-Objekten nicht als einfache MD5-Prüfsummen interpretiert werden. Hash-Verhalten.
CDN und eigene Domain gesondert umstellen
Spaces Standard kann öffentliche Inhalte über einen CDN-Endpunkt und eine eigene Subdomain mit TLS-Zertifikat ausliefern. Spaces Cold Storage unterstützt diese CDN-Integration nicht. Die Objektkopie überträgt diese Konfiguration nicht. Spaces-CDN-Konfiguration.
Planen Sie deshalb Origin, öffentliche Leserechte beziehungsweise abgesicherte Origin-Zugriffe, TLS, Cache-Regeln und Invalidierung als eigenen Pfad. Ein CNAME auf den neuen Bucket ersetzt diesen Entwurf nicht. Prüfen Sie vor der DNS-Änderung den vorgesehenen Hostnamen über die neue Auslieferungsschicht und aktualisieren Sie gespeicherte direkte Spaces-URLs. Für private Downloads neue signierte URLs durch die auf das Ziel konfigurierte Anwendung erzeugen lassen und testen.
Rollback vor dem Cutover festlegen
Unsere Empfehlung: Quelle bis zur dokumentierten Abnahme erhalten und den ersten Schreibwechsel bewusst freigeben. Solange das Ziel nur gelesen wird, bleibt der Rückweg überschaubarer. Sobald dort neue Uploads oder Löschungen stattfinden, ist die Quelle kein vollständiger Rückfallbestand mehr.
Für einen Rückwechsel Writer erneut anhalten, Änderungen einschließlich Löschungen nachvollziehbar abgleichen und erst danach Anwendung und Auslieferung zurückstellen. Definieren Sie Zuständigkeit, Freigabekriterien und Aufbewahrung vorab. Ein DNS-Rückwechsel allein stellt keinen konsistenten Datenbestand her. Das sind Planungsregeln, keine Zusage eines unterbrechungsfreien Umzugs.
Unser Vorgehen bei WZ-IT
Die DigitalOcean-zu-Hetzner-Migration grenzt Inventar, Funktionsersatz, Datenübernahme, Tests und Cutover im Angebot ab. Bei Spaces gehören insbesondere CDN-Abhängigkeiten und der Umgang mit Versionshistorie in diese Abstimmung. Einen nachgelagerten Betrieb vereinbaren wir gesondert über Managed Operations.
Weiterführende Guides
- DigitalOcean und Hetzner vergleichen
- AWS S3 zu Hetzner mit rclone und MinIO Client
- Cloud-Migration einordnen
Speicherpfad abstimmen: DigitalOcean-Migration anfragen mit Bucket-Inventar, Schreibquellen und CDN-Abhängigkeiten. Termin vereinbaren.
Server und Objektspeicher bleiben getrennte Umzüge: Der Droplet-Leitfaden behandelt Linux-Dateien, Datenbank und Cutover.
