Azure Database for PostgreSQL zu Hetzner Cloud migrieren – pg_dump/restore Guide

Azure-Kosten explodieren? Flexible Server zu teuer? Wir migrieren eure PostgreSQL-Datenbanken von Azure zu Hetzner Cloud – mit minimalem Risiko und klarem Cutover-Plan. 👉 Zur Azure-Migration-Übersicht | Kostenlose Analyse anfragen

Wenn Teams aus Azure rausmigrieren, ist die Datenbank oft der kritischste Baustein: Kosten und Lock-in spielen eine Rolle, aber im Alltag zählen vor allem Planbarkeit, Datenintegrität und ein sauberer Cutover. Für Azure Database for PostgreSQL (Flexible Server) beschreibt Microsoft Dump & Restore als Standardweg und empfiehlt dabei u.a. Directory-Format + Parallelisierung für große Datenbanken (Microsoft Learn).

Für das Ziel: In der Hetzner Cloud gibt es kein "Azure-ähnliches Managed PostgreSQL" – ihr baut das Ziel als VM + selbst installiertes PostgreSQL (und sorgt selbst für Backups/Monitoring). Für VM-Backups könnt ihr bei Hetzner Daily Backups aktivieren (7 Slots, Rotation) (Hetzner Docs).

Inhaltsverzeichnis

• Empfehlung und Zielbild
• Vorab-Checkliste
• Zielsystem vorbereiten: Hetzner VM und PostgreSQL
• Weg 1: Dump und Restore (Offline)
• Validierung nach Migration
• Weg 2: Logical Replication (Low Downtime)
• Häufige Fallstricke
• Cutover-Checkliste
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

---

Empfehlung und Zielbild

Default-Empfehlung: pg_dump/pg_restore

Wenn ihr Azure nutzt und ein Wartungsfenster (Downtime) akzeptabel ist:

• Der Ansatz ist erprobt, stabil und transparent – Microsoft liefert sehr konkrete Best Practices (Microsoft Learn)
• Komplizierte Replikation oder DMS-Setups entfallen
• Für Datenbanken bis ca. 100-500 GB ist ein Wartungsfenster realistisch planbar

Low-Downtime (Weg 2) lohnt sich erst, wenn:

• euer Wartungsfenster zu klein ist
• die DB so groß ist, dass Restore zu lange dauert
• oder ihr Writes nicht sauber "freezen" könnt

---

Vorab-Checkliste

Bevor ihr irgendwas dump't:

1. Postgres Major Version prüfen (Azure → Ziel sollte kompatibel sein; ideal: gleiche Major-Version)
2. Extensions inventarisieren

   SELECT extname, extversion FROM pg_extension ORDER BY 1;
   

3. Rollen/Privileges: Wer braucht welche Rechte nach dem Umzug?
4. Größe + Downtime-Toleranz: bestimmt Dump-Format, Parallelität, Cutover-Fenster
5. Netzwerkzugriff: Ziel-VM muss aus Azure erreichbar sein

---

Zielsystem vorbereiten: Hetzner VM und PostgreSQL

VM und Storage anlegen

1. VM in Hetzner Cloud anlegen
   • Ubuntu LTS (z.B. 22.04) oder Debian
   • Genügend RAM/CPU entsprechend der DB-Last
   • Separates Volume für /var/lib/postgresql (Wachstum/Backups)
   • Private Network / Firewall: Port 5432 nur von Admin-/Migration-IPs

PostgreSQL installieren

sudo apt update
sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql

Datenbank und User anlegen:

sudo -u postgres createuser --pwprompt appuser
sudo -u postgres createdb -O appuser appdb

Backups aktivieren

In Hetzner könnt ihr Daily Backups für Cloud-Server aktivieren (7 Slots, ältestes wird überschrieben) (Hetzner Docs). Das ersetzt keine DB-logischen Backups, ist aber ein gutes Fallschirmnetz.

---

Weg 1: Dump und Restore (Offline)

Microsoft beschreibt für Azure Database for PostgreSQL Flexible Server explizit das Vorgehen inkl. Rollen-Export, Dump-Optionen und Restore; außerdem wird das Directory-Format empfohlen, weil es Parallelisierung ermöglicht (Microsoft Learn).

Ablauf (High-Level)

1. Wartungsfenster starten – App in Maintenance / Read-Only
2. Rollen sichern (separat mit pg_dumpall)
3. Dump erstellen (Directory-Format, parallel)
4. Transfer des Dumps zur Hetzner-VM
5. Restore auf Ziel-PostgreSQL (parallel)
6. Fixups – Ownership, Grants, Sequences, Stats
7. Validierung – Counts, Stichproben, Smoke Tests
8. Cutover – App-Connection-String umstellen
9. Monitoring – Azure DB vorerst behalten (Rollback-Fenster)

Schritt 1: Rollen/Users exportieren

Microsoft führt das Muster pg_dumpall -r explizit als Schritt für Rollen/Users auf (Microsoft Learn).

export PGPASSWORD="<AZURE_PASSWORD>"

pg_dumpall -h <AZURE_HOST> -p 5432 -U <AZURE_ADMIN_USER> -r > roles.sql

Tipp: Rollen-File später reviewen (nicht blind ausführen), um unerwünschte Owner/Privilegien zu vermeiden.

Schritt 2: Datenbank dumpen (parallel)

Directory Format (für große DBs empfohlen):

export PGPASSWORD="<AZURE_PASSWORD>"

pg_dump \
  -h <AZURE_HOST> -p 5432 -U <AZURE_ADMIN_USER> -d <DBNAME> \
  -Fd -j 8 \
  -f dumpdir/

Custom Format (für kleine/mittlere DBs):

pg_dump \
  -h <AZURE_HOST> -p 5432 -U <AZURE_ADMIN_USER> -d <DBNAME> \
  -Fc -Z 6 \
  -f db.dump

Microsoft hat einen eigenen Artikel "Best practices for pg_dump and pg_restore" mit Parallelitäts- und VM-Überlegungen (Microsoft Learn).

Schritt 3: Transfer zur Hetzner VM

rsync -avP dumpdir/ root@<HETZNER_VM_IP>:/root/dumpdir/
rsync -avP roles.sql root@<HETZNER_VM_IP>:/root/

Schritt 4: Restore auf Hetzner VM

Datenbank anlegen:

export PGPASSWORD="<HETZNER_PASSWORD>"
createdb -h <HETZNER_VM_IP> -p 5432 -U <HETZNER_USER> <DBNAME>

Rollen einspielen (mit Vorsicht):

psql -h <HETZNER_VM_IP> -p 5432 -U <HETZNER_USER> -f /root/roles.sql

Restore (Directory, parallel):

pg_restore \
  -h <HETZNER_VM_IP> -p 5432 -U <HETZNER_USER> -d <DBNAME> \
  --no-owner --no-privileges \
  -j 8 \
  /root/dumpdir/

Warum --no-owner --no-privileges? Beim Provider-Wechsel wollt ihr Rollen/Grants kontrolliert auf euer Zielmodell ziehen, statt Azure-Defaults zu importieren.

Statistiken aktualisieren:

ANALYZE;

---

Validierung nach Migration

Harte Checks (Daten)

• Rowcounts für kritische Tabellen vergleichen
• Summenchecks (z.B. Rechnungsbeträge)
• Stichproben (50-100 IDs) quer prüfen

SELECT 'users'  AS t, count(*) FROM public.users
UNION ALL
SELECT 'orders' AS t, count(*) FROM public.orders;

Smoke Tests (Applikation)

• Login funktioniert
• 2-3 wichtigste Geschäftsprozesse (Create/Update/Payment)
• Background Jobs / Cron
• Schreibpfade testen (Insert/Update/Delete)

---

Weg 2: Logical Replication (Low Downtime)

Azure Flexible Server unterstützt native logical replication und logical decoding; Microsoft beschreibt explizit Publisher/Subscriber-Modelle (Microsoft Learn). PostgreSQL erklärt dazu: Jede Subscription nutzt einen Replication Slot (PostgreSQL Docs).

High-Level Runbook:

1. Ziel-VM steht, Schema ist vorbereitet
2. Auf Azure: Publication erstellen
3. Auf Hetzner: Subscription (Initial Sync + Streaming)
4. Lag monitoren
5. Cutover: kurzer Write-Freeze → Catch-up → App umstellen → Subscription/Slots aufräumen

Logical Replication ist mächtig – aber mehr Moving Parts (Netz, Slots, Lag, Wartung). Darum bei akzeptabler Downtime: Dump/Restore bleibt Default.

---

Häufige Fallstricke

Problem	Lösung
Major Version Mismatch	Vorab festlegen, welche Postgres-Version auf Hetzner läuft
Extensions fehlen	Inventarisieren und installieren, bevor restore läuft
Sequences/Identity drift	Nach Restore prüfen (klassischer "Insert fails" Fehler)
Rollen/Grants fehlen	Mit --no-owner/--no-privileges bewusst nachziehen
Backup-Lücke nach Cutover	Sofort DB-Backup-Plan aktivieren

---

Cutover-Checkliste

T-7 bis T-2 Tage

• Hetzner VM + Volume + Firewall fertig
• PostgreSQL installiert, Monitoring/Logs ok
• Hetzner Server Backups aktiviert (7 Slots)
• Extensions & Versionen geprüft
• Testlauf (kleine DB oder Snapshot) erfolgreich

T-24h

• Wartungsfenster kommuniziert
• Rollback-Plan schriftlich (Connection String zurück)
• Smoke-Test-Szenarien fixiert

Cutover

• App Read-Only / Maintenance
• pg_dumpall -r + pg_dump + Transfer + pg_restore
• Validierung: Counts + Stichproben + Smoke Tests
• App auf Hetzner DB umgestellt
• Monitoring (Errors, DB connections, latency)

T+24h

• Azure DB noch als Fallback behalten
• Performance & Fehler beobachten
• Azure DB dekommissionieren, wenn stabil

---

Unser Vorgehen bei WZ-IT

Unser Standard-Flow für Azure PostgreSQL → Hetzner:

1. Assessment: DB-Größe, Extensions, Änderungsrate, Downtime-Budget
2. Zielsystem: Hetzner VM provisionieren, PostgreSQL installieren, Firewall/Backup
3. Testmigration: Probedump auf Test-DB, Validierung, Performance-Check
4. Cutover-Planung: Wartungsfenster, Rollback-Plan, Kommunikation
5. Migration: Dump → Transfer → Restore → Validierung → Cutover
6. Monitoring: Error Rates, Latenzen, App-Logs, Backup-Verifizierung

👉 Wir erstellen euch einen konkreten Cutover-Runbook mit allen Befehlen und Checklisten.

---

Weiterführende Guides

Diese Anleitungen könnten euch ebenfalls interessieren:

• Azure Blob Storage zu Hetzner Object Storage migrieren – AzCopy & rclone Guide
• Azure zu Hetzner Migration – Komplettübersicht – Alle Azure-Services im Überblick
• Cloud-Migration Hub – Alle Provider-Migrationen im Überblick
• 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 Datenbank-Infrastruktur – von Azure zu kosteneffizienten, europäischen Alternativen.

👉 Jetzt kostenlose Kostenanalyse anfragen