AWS RDS/Aurora PostgreSQL zu Hetzner Cloud migrieren – pg_dump/restore Guide

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

AWS ist für viele Teams der Startpunkt – und später der Kostentreiber. Spätestens wenn eine Anwendung stabil läuft, werden die „weichen" Posten sichtbar: laufende RDS-Instanzkosten, Storage/IO, Backups – und vor allem Datenverkehr/Egress. AWS weist selbst darauf hin, dass Data-Transfer-Kosten beim Architekturdesign oft übersehen werden (AWS Blog).

Dazu kommt bei EU-Unternehmen immer häufiger ein zweites Motiv: digitale Souveränität und Datenhoheit. Seit Schrems II ist das Thema Drittlandtransfer und EU-konforme Cloud-Architektur stärker auf dem Radar (EuroCloud). Hetzner betreibt eigene Rechenzentren in Nürnberg, Falkenstein (DE) und Helsinki (FI) (Hetzner Docs).

In diesem Beitrag geht es um den häufigsten Exit-Schritt nach Storage: AWS RDS PostgreSQL → PostgreSQL auf einer Hetzner Cloud VM. Und weil Downtime akzeptabel ist, ist die Default-Empfehlung klar: pg_dump/pg_restore – der pragmatischste, am besten kontrollierbare Weg.

Inhaltsverzeichnis

• Empfehlung und Zielbild
• Zielsystem vorbereiten: Hetzner VM und PostgreSQL
• Migration mit pg_dump/pg_restore
• CMD-Beispiele
• Validierung nach Migration
• Häufige Fallstricke
• Cutover-Checkliste
• Alternativen bei minimaler Downtime
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

---

Empfehlung und Zielbild

Default-Empfehlung: pg_dump/pg_restore

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

• Der Ansatz ist erprobt, stabil und transparent – native PostgreSQL-Tools reichen aus (AWS Docs)
• Komplizierte Replikation, Logical Replication oder DMS-Setups entfallen
• Für Datenbanken bis ca. 100-500 GB ist ein Wartungsfenster realistisch planbar

Zielbild bei Hetzner: Es gibt kein "Managed PostgreSQL" bei Hetzner Cloud. Das Ziel ist: VM anlegen und PostgreSQL selbst installieren/betreiben – mit voller Kontrolle über Konfiguration, Backups und Updates.

---

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-Regeln für Zugriff

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

Remote-Zugriff konfigurieren

• postgresql.conf: listen_addresses nur auf benötigte IPs
• pg_hba.conf: nur explizite Netze/IPs erlauben
• Firewall: Port 5432 nur von Migration-Host/App-Netz

Backup-Strategie definieren

Ab jetzt seid ihr selbst DBA. Minimum:

• Nightly pg_dump + Rotation
• VM/Volume Snapshots (zusätzlich, nicht allein)
• Optional: WAL-Archivierung für Point-in-Time Recovery

---

Migration mit pg_dump/pg_restore

Ablauf (High-Level)

1. Wartungsfenster starten – App in Maintenance / Read-Only
2. Dump erstellen (komprimiert, optional parallel)
3. Transfer des Dumps zur Hetzner-VM
4. Restore auf Ziel-PostgreSQL
5. Fixups – Extensions, Owner, Grants, Sequences
6. Validierung – Counts, Stichproben, Smoke Tests
7. Cutover – App-Connection-String umstellen
8. Monitoring – Altes RDS vorerst read-only lassen (Rollback-Fenster)

---

CMD-Beispiele

Dump (AWS RDS als Quelle)

Custom Format (kompakt, flexibel):

export PGPASSWORD="<AWS_PASSWORD>"

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

• -Fc: Custom Format (ideal für pg_restore)
• -Z 6: Kompression

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

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

Transfer zur Hetzner VM

rsync -avP db.dump root@<HETZNER_VM_IP>:/root/

Restore auf Hetzner VM

Datenbank anlegen:

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

Restore:

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

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

Statistiken aktualisieren:

ANALYZE;

---

Validierung nach Migration

Harte Checks (Daten)

• Rowcounts für kritische Tabellen vergleichen
• Summenchecks (z.B. Rechnungsbeträge)
• Stichproben (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)

Performance Quickcheck

• Connection Pooling konfiguriert?
• Error Rate & DB Connections nach Cutover beobachten

---

Häufige Fallstricke

Problem	Lösung
Extensions fehlen	Vorab inventarisieren (SELECT * FROM pg_extension) und auf Ziel installieren
Sequences falsch	nextval() stimmt nicht → per Script setval() anpassen
Grants/Owner fehlen	Nachziehen, weil --no-owner/--no-privileges genutzt wird
Timeouts beim Dump	Parallelisieren (-j), Wartungsfenster anpassen

---

Cutover-Checkliste

T-7 bis T-2 Tage

• Hetzner VM + Volume steht (Location gewählt)
• PostgreSQL installiert, Firewall/pg_hba konfiguriert
• Backup-Job auf Ziel aktiv
• Probedump/Proberestore durchgeführt

T-24h

• Wartungsfenster kommuniziert
• Rollback definiert (Conn-String zurück auf RDS)
• Smoke-Test-Szenarien dokumentiert

Cutover

• App Read-Only / Maintenance
• Dump erstellt + transferiert + restore
• Validierung: Counts + Stichproben + Smoke Tests
• App auf Hetzner DB umgestellt
• Monitoring (Errors, DB connections, latency)

T+24h

• RDS noch read-only behalten (Sicherheitsnetz)
• Performance & Fehler beobachten
• RDS dekommissionieren, wenn stabil

---

Alternativen bei minimaler Downtime

Wenn Dump/Restore zu lang dauert oder Downtime kritisch ist:

• Logical Replication (Publication/Subscription) – Low Downtime, mehr Setup (AWS Blog)
• AWS DMS (Full Load + CDC) – orchestriert, aber Setup-Aufwand (AWS Docs)

Für diesen Artikel – weil Downtime ok – bleibt pg_dump/restore die Default-Empfehlung.

---

Unser Vorgehen bei WZ-IT

Unser Standard-Flow für AWS RDS → Hetzner PostgreSQL:

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:

• AWS S3 zu Hetzner Object Storage migrieren – rclone & MinIO Client Guide
• AWS zu Hetzner Migration – Komplettübersicht – Alle AWS-Services im Überblick
• Cloud-Migration Hub – Alle Provider-Migrationen im Überblick
• Cloud-Kosten sparen: AWS EC2 & RDS – Bis zu 90% Ersparnis
• 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 AWS zu kosteneffizienten, europäischen Alternativen.

👉 Jetzt kostenlose Kostenanalyse anfragen