CodeGym /Kurse /SQL SELF /Datenwiederherstellung nach einem Ausfall

Datenwiederherstellung nach einem Ausfall

SQL SELF
Level 44 , Lektion 2
Verfügbar

Ausfälle gibt's viele: Hardware-Defekte, Stromausfälle, Bugs im Code oder – was gar nicht so selten ist – das versehentliche Löschen der Datenbank durch einen Admin, der mal eben "was Altes" aufräumen wollte. In solchen Situationen werden Backups und ein gut eingeübter Recovery-Prozess zu deinem "Zauberstab".

Lass uns den Wiederherstellungsprozess Schritt für Schritt durchgehen, so wie wir einen IKEA-Schrank zusammenbauen würden: ohne Panik und schön nach Anleitung.

Schritt 1. Analyse der Ausfallursache

Bevor du mit Vollgas die Daten wiederherstellst, solltest du erstmal checken, was eigentlich passiert ist.

  1. Fehler in der App oder Datenbank?
    Check die Logs deiner App und von PostgreSQL (meistens findest du die unter /var/log/postgresql/ oder einem ähnlichen Verzeichnis, je nach OS). Such nach Fehler-Indikatoren.

  2. Hardware-Defekt?
    Wenn der Server physisch beschädigt ist (z.B. Probleme mit der Festplatte), dann prüfe zuerst, ob die Hardware noch läuft. Falls deine Platte hinüber ist, schließ eine andere an und stell alles davon wieder her.

  3. Netzwerk- oder Zugriffsprobleme?
    Wenn der Ausfall am Netzwerk liegt – dann braucht dein Server wahrscheinlich erstmal keine Recovery-Aktion.

  4. Menschlicher Faktor:
    Sei ehrlich... hat jemand DROP DATABASE ausgeführt? Falls ja, haben wir immer noch eine Chance, die Daten aus dem Backup zu holen.

Denk dran: Wenn du die Ursache des Ausfalls genau kennst, kannst du ihn in Zukunft vermeiden.

Schritt 2. Überprüfung der Backup-Verfügbarkeit

Jetzt ist es Zeit zu checken, ob wir ein brauchbares Backup haben. Such die letzten Backups deiner Datenbank, die du mit pg_dump oder pg_basebackup gemacht hast. Prüfe, ob sie intakt sind. Falls du nicht mehr weißt, wie das geht, hier eine kurze Erinnerung:

  • Benutze ls -l, um die Größe deiner Dateien zu checken. Wenn die Datei verdächtig klein ist, könnte das ein Problem sein.
  • Check die Datei mit file. Zum Beispiel:
    file backup_file.sql
    
    Du solltest Infos sehen, die zeigen, dass das ein SQL-Dump ist.

Für ein tar-Archiv prüfe, ob es sich entpacken lässt:

tar -tf backup.tar

Keine Fehler? Super! Dann können wir weitermachen.

Schritt 3. PostgreSQL stoppen

Bevor du mit dem Recovery loslegst, solltest du den PostgreSQL-Server stoppen, damit nichts dazwischenfunkt. Das geht so (als Server-Admin):

sudo systemctl stop postgresql

Das Stoppen der Datenbank stellt sicher, dass keine Prozesse das Recovery stören.

Schritt 4. Neue Datenbank für die Wiederherstellung vorbereiten

Wenn deine Datenbank komplett gelöscht oder beschädigt wurde, leg sie erstmal neu an. Beispiel:

createdb -U postgres new_database

Ersetze new_database durch den Namen deiner DB.

Schritt 5. Backup wiederherstellen

Es gibt zwei Hauptszenarien für die Wiederherstellung:

  1. Wenn du ein SQL-Backup (pg_dump) hast: Zum Wiederherstellen nutze:

    psql -U username -d new_database -f backup_file.sql
    
  • username — dein PostgreSQL-User.
  • new_database — die Datenbank, in die du importierst.
  • backup_file.sql — deine Backup-Datei.
  1. Wenn du ein Binary-Backup (pg_basebackup oder pg_dump mit custom) hast:
    Zum Wiederherstellen nutze:
    pg_restore -U username -d new_database backup_file.dump
    
    Beachte, dass diese Backups nicht im Textformat sind, sondern "gepackte" Daten enthalten.

Zusätzlich:

  • Wenn im Backup nur Daten sind, nutze --data-only.
  • Wenn du nur das Schema brauchst, häng --schema-only dran.

Schritt 6. PostgreSQL starten und testen

Nach dem Recovery starte den Server wieder:

sudo systemctl start postgresql

Jetzt solltest du Tests machen. Versuch, dich mit psql oder pgAdmin mit der wiederhergestellten DB zu verbinden. Mach ein paar SELECTs, um zu checken, ob die Daten passen:

SELECT * FROM your_table_name LIMIT 10;

Wenn alles gut aussieht, Glückwunsch: Die Daten sind wieder da!

Schritt 7. Datenintegrität prüfen

Nach dem Recovery ist es wichtig zu checken, ob die Daten vollständig sind. Zum Beispiel:

  1. Vergleiche die Zeilenanzahl in den Tabellen mit den Backups:

    SELECT COUNT(*) FROM your_table_name;
    

    Vergleiche das Ergebnis mit den Einträgen im Backup (falls vorhanden).

  2. Benutze Checksummen: Falls du vorher Checksummen für Tabellen erstellt hast, jetzt ist der Moment, sie zu vergleichen:

    md5sum backup_file.sql
    
  3. Check die Beziehungen zwischen Tabellen: Stell sicher, dass die wiederhergestellten FOREIGN KEY-Beziehungen korrekt funktionieren.

Schritt 8. App testen

Jetzt prüfe, ob deine App, die diese Datenbank nutzt, wieder läuft. Geh die wichtigsten Use Cases durch. Gibt's Fehler? Wird alles korrekt angezeigt?

Echte Fehlerbeispiele bei der Wiederherstellung

Jetzt schauen wir uns ein paar Cases an, damit du weißt, wie du Probleme vermeiden kannst:

  1. PostgreSQL-Versionen nicht kompatibel.
    Stell dir vor, das Backup wurde mit Version 12 gemacht, aber der Server läuft jetzt auf Version 15. Beim Wiederherstellen gibt's dann Fehler.
    Lösung: Nutze die gleiche PostgreSQL-Version wie beim Backup oder schau in die Doku zur Kompatibilität: PostgreSQL Documentation.

  2. Beschädigtes Backup.
    Wenn dein Backup beschädigt ist, können Daten verloren gehen.
    Lösung: Nutze Backup-Replikation (z.B. mehrere Versionen speichern).

  3. Fehler beim Wiederherstellen einer bestimmten Tabelle.
    Wenn du eine einzelne Tabelle wiederherstellst, aber die Abhängigkeiten (z.B. Foreign Keys) fehlen, kann der Prozess fehlschlagen.
    Lösung: Stell Tabellen immer in der richtigen Reihenfolge wieder her, beginnend mit den Parent-Tabellen.

Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION