Azure Blob Storage zu Hetzner Object Storage migrieren – AzCopy & rclone Guide

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 | Cloud-Exit-Check

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

s3cmd und aws s3 kopieren keine Custom Metadata (Hetzner Docs). rclone überträgt Custom Metadata nur mit dem Flag --metadata (-M), ohne das Flag bleiben nur Änderungszeit und Content-Type erhalten (rclone Docs). Azure-seitig liest rclone die Custom Metadata aus den x-ms-meta-*-Feldern (rclone Docs). Wer Custom Metadata erhalten muss, nutzt daher Variante B mit -M, bei der rclone direkt von Blob zu Bucket überträgt.

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: s3cmd und aws s3 kopieren sie nicht, rclone nur mit --metadata (-M) (rclone 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

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:

1. Assessment: Größe, Objektanzahl, Änderungsrate, Metadaten-Anforderungen
2. Pilot: Testprefix + Validierungsplan
3. Bulk: Initial Copy (sharded, parallel)
4. Delta: 1–3 Sync-Runs
5. Cutover: App-Konfig/URLs umstellen
6. 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.

👉 Cloud-Exit-Check ansehen

Quellen

• Hetzner Docs: Object Storage Overview
• Hetzner Docs: Migrating from other providers
• rclone Docs: Metadata
• rclone Docs: Azure Blob Storage
• Microsoft Learn: Get started with AzCopy
• AWS Prescriptive Guidance: Migrate data from Azure Blob to Amazon S3 by using rclone