Backup klingt erstmal wie ein Regenschirm an einem nassen Tag: Du denkst, er schützt dich vor allem. Aber wenn der Schirm ein Loch hat, wirst du trotzdem nass. Mit Backups und Restore ist es genauso: Wenn was schiefgeht, verlierst du Daten oder – noch schlimmer – bekommst eine kaputte Datenbank. Deshalb ist es so wichtig, Fehler zu verstehen und sie zu vermeiden.
Probleme bei der Datenwiederherstellung
- Inkompatible PostgreSQL-Versionen
Eines der häufigsten und nervigsten Probleme ist der Versuch, Daten, die mit einer PostgreSQL-Version erstellt wurden, in einer anderen Version wiederherzustellen (zum Beispiel Backup von Version 11 auf 15 wiederherstellen). PostgreSQL garantiert keine Rückwärtskompatibilität zwischen Versionen.
Warum passiert das?
- Das Datenformat kann sich zwischen Versionen ändern.
- Manche Funktionen und Parameter werden entfernt oder geändert.
Wie vermeiden?
- Erstelle Backups immer mit
pg_dumpund nicht durch direktes Kopieren des PostgreSQL-Datenverzeichnisses.pg_dumperzeugt universelle SQL-Skripte, die du auf jeder kompatiblen Version wiederherstellen kannst. - Checke die Kompatibilität der Versionen vor dem Restore. Infos findest du in der offiziellen PostgreSQL-Doku.
Hier ein Beispiel. Du hast ein Backup mit PostgreSQL 14 erstellt:
pg_dump -U user -d my_database -f backup.sql
Jetzt versuchst du, es auf PostgreSQL 15 wiederherzustellen:
psql -U user -d my_database -f backup.sql
Und bekommst Fehler wie:
ERROR: unrecognized configuration parameter "old_function"
Lösung: Update die PostgreSQL-Version auf dem Server oder nutze das Tool pg_upgrade für die Migration.
- Fehlende WAL-Dateien
Manchmal bricht das Restore von einem inkrementellen oder differenziellen Backup plötzlich ab – alles wegen fehlender WAL-Dateien (Write-Ahead Logging). PostgreSQL braucht die, um Änderungen nach dem letzten Full-Backup „nachzuziehen“. Wenn die Dateien fehlen oder kaputt sind, kann die DB das Restore nicht abschließen.
Das passiert zum Beispiel, wenn das WAL-Archivieren nicht aktiviert war oder jemand den Ordner gelöscht hat, um Platz zu schaffen. Wenn du also keine vollständigen Backups nutzt, aktiviere unbedingt das Archivieren in postgresql.conf:
archive_mode = on
archive_command = 'cp %p /path/to/wal_archive/%f'
Und check regelmäßig, ob das Archivieren wirklich läuft und die Dateien da und heil sind. Das ist ein kleiner Aufwand für die Sicherheit, dass das Restore klappt.
- Beschädigtes Backup
Deine Backup-Datei kann beschädigt sein und ist dann für das Restore nutzlos.
Warum passiert das?
- Datei-Integrität wurde beim Übertragen oder Speichern verletzt.
- Unerwarteter Fehler beim Erstellen des Backups.
Wie vermeiden?
Nutze Komprimierung und Checksummen, um die Integrität des Backups zu prüfen. Zum Beispiel kannst du nach dem Erstellen einen MD5-Hash machen:
md5sum backup.sql > backup.sql.md5
Vor dem Restore immer die Backup-Datei checken:
md5sum -c backup.sql.md5
Problem und Lösung
Du versuchst, eine beschädigte Datei wiederherzustellen:
pg_restore -U user -d my_database backup.dump
Und siehst:
pg_restore: fatal error: input file appears to be a text file, but you are using the 'pg_restore' command-line tool; try using psql instead
Lösung: Öffne die Datei in einem Texteditor und prüfe, ob sie noch lesbar ist. Wenn der Schaden klein ist, kannst du die SQL-Datei vielleicht manuell reparieren.
- Unzureichende Benutzerrechte.
Manchmal bekommst du beim Restore Fehler wegen fehlender Rechte, vor allem wenn du mit einem eingeschränkten User arbeitest.
Warum passiert das?
Der User hat nicht genug Rechte, um Tabellen, Schemas oder DB-Objekte zu erstellen.
Wie vermeiden?
Führe das Restore mit einem User aus, der alle nötigen Rechte hat:
pg_restore -U postgres -d my_database backup.dump
- Überschreiben einer bestehenden Datenbank
Noch ein häufiger Fehler: Restore eines Backups, wenn schon Daten existieren. Wenn du versehentlich bestehende Einträge überschreibst, sind sie weg.
Warum passiert das?
Du nutzt das Flag --clean nicht, und das neue Backup wird einfach über die alten Daten geschrieben.
Wie vermeiden?
Beim Restore immer das Flag --clean nutzen, um die bestehende Struktur zu löschen:
pg_restore --clean -U user -d my_database backup.dump
- Fehler durch nicht abgeschlossene Transaktion
Beim Restore können Probleme mit Daten auftreten, die in einer offenen Transaktion „hängen“. Das ist besonders bei großen Datenbanken ein Thema.
Warum passiert das?
Die Transaktion wurde durch einen Serverabsturz „beschädigt“.
Wie vermeiden?
Stell sicher, dass der PostgreSQL-Server alle offenen Transaktionen sauber abschließt, bevor du ein Restore machst. Wenn es Probleme gibt, starte den Server neu mit:
sudo service postgresql restart
Wie du Restore-Fehler generell vermeidest
Wir haben besprochen, wie du einzelne Probleme umgehst, aber es gibt auch allgemeine Strategien, die die meisten Fehler verhindern:
Teste regelmäßig das Restore. Erstelle eine eigene Test-DB und probiere das Restore dort aus.
Bewahre mehrere Backup-Kopien auf. Nutze Cloud, lokalen Speicher und einen Remote-Server.
Automatisiere das Backup. Nutze cron oder ähnliche Tools für einen Zeitplan.
Checke die Dateiintegrität. Nutze Checksummen, um sicherzugehen, dass das Backup nicht beschädigt ist.
Halte die PostgreSQL-Versionen synchron. Verschiebe Updates nicht, sonst gibt’s später Kompatibilitätsprobleme.
Echte Beispiele und ihre Lösungen
Case 1: Verlust von WAL-Dateien. Dein Server ist plötzlich ausgegangen und du stellst fest, dass die nötigen WAL-Dateien fehlen. In dem Fall ist ein Restore nur mit einem vollständigen Backup möglich. Die einfachste Lösung: Check regelmäßig die WAL-Archiv-Konfiguration.
Case 2: Beschädigtes Backup. Du hast das Backup auf den Server geladen, aber beim Prüfen ist die Datei leer. In solchen Fällen nutze ein Backup aus einem anderen Speicher oder prüfe, ob ein Restore aus einer teilweise beschädigten Kopie möglich ist.
Case 3: Versionsinkompatibilität. Beim Umzug von PostgreSQL 12 auf PostgreSQL 14 bekommst du Fehler. Übertrage die Daten mit pg_dump und stelle sie mit der neuen Version wieder her.
GO TO FULL VERSION