Wie lange dauert eine Azure Blob Migration zu Hetzner?

Die Dauer hängt von Datenmenge, Objektanzahl, Parallelität und Netzwerkbandbreite ab. Grob: Initial Copy dauert Stunden bis Tage, Delta Syncs Minuten bis Stunden.

Kann ich ohne Downtime migrieren?

Ja, meist mit Delta Syncs und kurzem Freeze/Read-Only-Fenster. Für reine Read-Workloads geht es oft komplett ohne Downtime.

AzCopy oder rclone – was ist besser?

AzCopy ist Azure-native und stark für Blob↔lokal / Blob↔Blob. rclone ist die bessere Bridge zwischen Azure Blob und S3-kompatiblen Zielen wie Hetzner.

Was passiert mit Custom Metadata bei der Migration?

rclone, s3cmd und aws s3 kopieren keine Custom Metadata. Wenn Custom Metadata kritisch ist, sollte MinIO Client evaluiert werden.

Welche URL nutze ich für Public Buckets bei Hetzner?

Das Format ist: https:// . .your-objectstorage.com/ – die Location (fsn1/nbg1/hel1) muss im Hostnamen enthalten sein.

Azure Blob Storage zu Hetzner Object Storage migrieren

Azure-Kosten explodieren? Blob Storage zu teuer? Wir migrieren eure Azure Blob Container zu Hetzner Object Storage – mit minimalem Risiko und klarem Cutover-Plan. 👉 Zur Azure-Migration-Übersicht | Kostenlose Analyse anfragen

Azure Blob Storage ist oft der „Sammelpunkt" für Assets, Backups, Logs, Medien – und damit ein typischer Kostentreiber (Storage + Requests + Egress) und ein Lock-in-Baustein. Wenn ihr eure Storage-Schicht vereinheitlichen wollt, ist Hetzner Object Storage attraktiv: Es ist S3-kompatibel, sodass ihr am Ziel mit Buckets und S3-Tools statt Azure-spezifischen APIs arbeitet. Objekte sind immutable (WORM: write once, read many), und Public Buckets folgen einem klaren URL-Format (Hetzner Docs).

Dieser Guide zeigt zwei praxiserprobte Migrationswege:

Variante A (safe & simpel): AzCopy → lokal (Staging) → rclone → Hetzner
Variante B (direkt): rclone azureblob → rclone s3 (Hetzner)

Dazu: Initial Copy → Delta Sync → Cutover, Integritätschecks, und ein wichtiges Gotcha zu Custom Metadata.

Inhaltsverzeichnis

Grundlagen: Azure Blob vs. Hetzner Object Storage
Voraussetzungen
Tool-Auswahl: AzCopy vs. rclone
Variante A: AzCopy → lokal → rclone → Hetzner
Variante B: rclone direkt (azureblob → s3/Hetzner)
Datenintegrität prüfen
Performance-Tipps
Häufige Fallstricke
Cutover-Checkliste
Unser Vorgehen bei WZ-IT
Weiterführende Guides

Grundlagen: Azure Blob vs. Hetzner Object Storage

Azure Blob – die Hierarchie

Storage Account → Container → Blobs
„Ordner" sind in Azure Blob meist virtuell (Prefix im Namen), nicht echte Verzeichnisse

Hetzner Object Storage – das Zielbild

Bucket → Objects (immutable)
Public URL-Format (wenn Bucket auf Public gesetzt): https://<bucket-name>.<location>.your-objectstorage.com/<file-name> (Hetzner Docs)

Das location ist dabei eine Region (z.B. fsn1/nbg1/hel1). Auch wenn ihr die Region in anderen Tools nochmal angebt: Endpoint muss die Location enthalten.

Voraussetzungen

Auf Azure-Seite

Zugriff auf Storage Account / Container
Auth-Strategie für AzCopy: User Identity / Managed Identity / Service Principal / SAS Token (Microsoft Learn)

Auf Hetzner-Seite

Bucket in Hetzner Object Storage erstellt
S3 Credentials (Access Key/Secret) bereit (Secret sicher ablegen)
Endpoint/Location festgelegt

Migration-Host / Netzwerk

Ein Rechner/VM, der gleichzeitig Azure Blob und Hetzner Object Storage erreichen kann (die Tools laufen „bei euch", nicht server-to-server)

Tool-Auswahl: AzCopy vs. rclone

AzCopy (Microsoft Standard für Azure Storage)

AzCopy ist Microsofts CLI, um Daten in/aus Azure Storage zu kopieren. Es unterstützt u.a. SAS-Tokens an URLs und enthält viele Copy/Sync-Beispiele (Microsoft Learn).

Wichtig: AzCopy kann nicht „direkt" nach S3 sprechen. Daher ist AzCopy hauptsächlich für Blob ↔ lokal oder Blob ↔ Blob.

rclone (die Brücke: azureblob ↔ s3)

rclone unterstützt Azure Blob als Backend und kann ebenso zu S3-kompatiblen Zielen syncen (rclone Docs). AWS Prescriptive Guidance hat sogar ein Pattern „Azure Blob → S3 mit rclone" – das Prinzip ist identisch, nur dass euer S3-Ziel hier Hetzner ist (AWS Docs).

Metadaten-Gotcha

rclone, s3cmd und aws s3 kopieren keine Custom Metadata. Wenn eure Objekte Custom Metadata tragen und ihr sie erhalten müsst, solltet ihr MinIO Client in Betracht ziehen (Hetzner Docs).

Praktisch bedeutet das:

Nutzt ihr Custom Metadata in Azure (z.B. für App-Logik, Cache-Keys, Processing Flags)?
→ Plant explizit einen Metadaten-Spotcheck und entscheidet, ob „Custom Metadata erhalten" ein Muss ist

Variante A: AzCopy → lokal → rclone → Hetzner

Diese Variante ist ideal, wenn ihr:

eine klare Staging-Stufe wollt
Blob-Daten sauber aus Azure ziehen wollt
den Upload zu Hetzner getrennt und reproduzierbar machen wollt

Schritt A1: AzCopy installieren & authentifizieren

AzCopy v10 ist die aktuelle Version, mit Auth über Identity oder SAS Token (Microsoft Learn).

Typische Auth-Optionen:

azcopy login (User/Entra ID)
SAS Token an Source-URL anhängen

Schritt A2: Container rekursiv lokal herunterladen

# Quelle (Azure Blob Container)
SRC="https://<account>.blob.core.windows.net/<container>?<SAS_TOKEN>"

# Ziel (lokaler Pfad)
DST="/data/azure-export/<container>/"

azcopy copy "$SRC" "$DST" --recursive

Optional: Sync statt Copy

AzCopy Sync ist grundsätzlich rekursiv (Default) und kann Hash-Vergleich nutzen (GitHub):

azcopy sync "$SRC" "$DST" --compare-hash

Schritt A3: rclone zu Hetzner (S3) konfigurieren

rclone config

Remote hetzner als S3-kompatibles Ziel konfigurieren
Endpoint: https://<location>.your-objectstorage.com

Schritt A4: Upload/Sync von lokal nach Hetzner

rclone sync /data/azure-export/<container>/ hetzner:<bucket>/<prefix>/ \
  --progress --transfers 32 --checkers 32

Schritt A5: Delta Sync kurz vor Cutover

# T-24h
rclone sync /data/azure-export/<container>/ hetzner:<bucket>/<prefix>/ --progress

# T-1h (nach erneutem azcopy sync)
rclone sync /data/azure-export/<container>/ hetzner:<bucket>/<prefix>/ --progress

Variante B: rclone direkt (azureblob → s3/Hetzner)

Diese Variante ist schneller aufzusetzen, wenn ihr:

keine lokale Staging-Kopie behalten müsst
rclone ohnehin im Einsatz habt
initial+delta direkt durchlaufen wollt

Schritt B1: rclone Remote `azureblob` konfigurieren

rclone dokumentiert die Konfiguration von azureblob (Account Name/Key) (rclone Docs).

Schritt B2: rclone Remote `hetzner` (S3) konfigurieren

S3 provider: „Other" / S3-compatible
Endpoint: https://<location>.your-objectstorage.com

Schritt B3: Initial Copy

rclone sync azureblob:<container>/<prefix>/ hetzner:<bucket>/<prefix>/ \
  --progress --transfers 32 --checkers 32

Schritt B4: Delta Sync & Cutover

Wie oben: 1–3 Delta-Läufe, dann App umstellen.

Merke: Auch „direkt" bedeutet: rclone läuft auf eurem Host und streamt zwischen den APIs.

Datenintegrität prüfen

1. Objektanzahl & Gesamtgröße vergleichen

rclone size hetzner:<bucket>/<prefix>/

2. Stichproben-Downloads + Hash

100 zufällige Objekte verschiedener Größenklassen
Lokal hashen und vergleichen (SHA256)

3. Metadaten-Spotcheck

Gerade bei Frontend-Assets entscheidet Content-Type/Caching oft über „funktioniert / funktioniert nicht".

Custom Metadata ist die große Falle: rclone/s3cmd/aws s3 kopieren sie nicht (Hetzner Docs).

4. Public URLs testen (falls relevant)

Wenn ihr Public Buckets nutzt:

10 zufällige Assets direkt via Browser/curl abrufen
Statuscodes, MIME, Cache Header prüfen

Performance-Tipps

AzCopy

sync für wiederholte Läufe mit Hash-Vergleich (--compare-hash)
Große Container in Prefixe sharden und parallel laufen lassen

rclone

--transfers/--checkers erhöhen, aber Throttling beobachten
Große Prefixe sharden bei vielen kleinen Files
Logs/Reports sauber wegschreiben (--log-file)

Häufige Fallstricke

Problem	Lösung
Custom Metadata geht verloren	MinIO Client evaluieren, wenn Custom Metadata kritisch ist
Public Assets nach Cutover kaputt (MIME/Cache)	Metadaten-Spotcheck + CDN/Frontend-Smoke-Tests vor Umschalten
Falscher Endpoint (Location fehlt)	Endpoint muss Location enthalten: `fsn1.your-objectstorage.com`
Unterschätzte Änderungsrate	Delta Sync mehrfach einplanen + Freeze (wenn möglich)

Cutover-Checkliste

T-7 bis T-2 Tage

Hetzner Bucket + Location festgelegt
S3 Credentials erstellt & sicher gespeichert
Migration-Host hat Zugriff auf Azure + Hetzner
Metadaten-Anforderungen geklärt (Custom Metadata ja/nein)

T-24h

Testmigration + Validierung abgeschlossen
Plan für Initial + Delta Sync steht
Cutover-Schritte & Rollback schriftlich

Cutover

Final Delta Sync durch
Smoke Tests (Public URLs / App Reads/Writes) bestanden
App/Config/Origin umgestellt
Monitoring für 24h aktiv

Unser Vorgehen bei WZ-IT

Unser Standard-Runbook für Azure Blob → Hetzner Object Storage:

Assessment: Größe, Objektanzahl, Änderungsrate, Metadaten-Anforderungen
Pilot: Testprefix + Validierungsplan
Bulk: Initial Copy (sharded, parallel)
Delta: 1–3 Sync-Runs
Cutover: App-Konfig/URLs umstellen
Monitoring: 404s, MIME/Cache, Zugriffslatenz, Error-Rates

👉 Wir erstellen euch einen konkreten Cutover-Runbook (inkl. Kommandos, Parallelitäts-Tuning, Verifikationsplan).

Weiterführende Guides

Diese Anleitungen könnten euch ebenfalls interessieren:

Azure zu Hetzner Migration – Komplettübersicht – Alle Azure-Services im Überblick
Cloud-Migration Hub – Alle Provider-Migrationen im Überblick
AWS S3 zu Hetzner Object Storage migrieren – rclone & MinIO Client Guide
AWS RDS/Aurora PostgreSQL zu Hetzner migrieren – pg_dump/restore Guide
Hetzner Expertise – Unsere Hetzner-Services im Überblick

Bereit für die Migration? Bei WZ-IT übernehmen wir Analyse, Migration und Betrieb eurer Storage-Infrastruktur – von Azure zu kosteneffizienten, europäischen Alternativen.

👉 Jetzt kostenlose Kostenanalyse anfragen