Datenintegritätsprüfung nach der Wiederherstellung

Ein Datenbank-Restore ist nicht immer easy: Es sieht vielleicht alles gut aus, aber dann tauchen im Log Fehler auf, manche Tabellen fehlen oder die Daten wirken irgendwie komisch. Genau deshalb ist es so wichtig, nach dem Restore immer zu checken, ob wirklich alles passt.

Manchmal werden einfach nicht alle Daten wiederhergestellt – zum Beispiel, wenn das Backup beschädigt war. Es kann auch passieren, dass die Tabellenstruktur durcheinanderkommt: Foreign Keys verschwinden, Indizes fehlen oder es tauchen seltsame Werte auf. Und selbst wenn auf den ersten Blick alles okay aussieht, können die Logs schon andeuten, dass die DB nicht ganz gesund ist.

Integritätsprüfung ist wie ein Check nach der Reparatur. Lieber kurz Zeit investieren und sicherstellen, dass alles läuft, als später plötzlich im Prod auf Probleme zu stoßen.

Analyse der Restore-Logs

Wenn du Daten mit pg_restore wiederherstellst, erzeugt PostgreSQL immer ein Log. Das Log enthält viele nützliche Infos zum Restore-Prozess, inklusive Warnungen und Fehlern. Hier ein Beispiel für einen Befehl mit Logfile:

pg_restore -U username -d database_name backup_file.dump > restore_log.txt 2>&1

Achte auf > restore_log.txt 2>&1 – das leitet sowohl die Standardausgabe als auch Fehler in eine Datei um.

Worauf solltest du im Log achten?

1. Fehler. Schau nach Keywords wie "ERROR" oder "FATAL". Beispiel:

   ERROR:  relation "students" does not exist
   

2. Warnungen. Manchmal siehst du "WARNING". Die sind zwar nicht kritisch, aber lies sie trotzdem – vielleicht deuten sie auf Probleme hin:

   WARNING:  no privileges could be granted for table "grades"
   

3. Dateninkonsistenzen. Check, ob alle wichtigen Objekte wiederhergestellt wurden: Tabellen, Indizes, Foreign Keys.

Schneller Check mit grep

Wenn das Logfile zu lang ist (und die können echt wie "Krieg und Frieden" sein), kannst du mit grep nach Keywords suchen:

grep -i "error" restore_log.txt
grep -i "warning" restore_log.txt

Fehleranalyse aus den Logs

Schauen wir uns ein echtes Beispiel aus dem Log an:

ERROR:  constraint "fk_student_course" for relation "enrollments" does not exist
DETAIL:  Key (course_id)=(2) is not present in table "courses".

Was sagt uns dieser Fehler? PostgreSQL versucht, eine Zeile in der Tabelle enrollments wiederherzustellen, aber es gibt keinen passenden course_id in der Tabelle courses.

Wie lösen? Wahrscheinlich sind die Daten in der Tabelle courses beschädigt oder wurden nicht wiederhergestellt. Du musst entweder die fehlenden Zeilen manuell hinzufügen oder das Restore nochmal machen.

Checksummen zur Integritätsprüfung nutzen

Wenn du sicher sein willst, dass dein Backup-File vor und nach dem Restore nicht beschädigt ist, kannst du Checksummen verwenden.

Eine Checksumme ist eine kleine Zahl, die die Daten einer Datei repräsentiert. Wenn sich die Datei auch nur um ein Bit ändert, ändert sich auch die Checksumme. So findest du raus, ob die Datei beschädigt wurde.

Zum Erstellen einer Checksumme kannst du md5sum nutzen. Beispiel:

md5sum backup_file.dump

Das Ergebnis sieht so aus:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Checksummen vergleichen

Wenn du die Checksumme vorher notiert hast, kannst du sie jetzt vergleichen:

md5sum -c checksum.md5

Die Datei checksum.md5 sollte eine Zeile mit Checksumme und Dateiname enthalten:

4c9b5f5d31ae2b53e9e3d56dfedc3fe4  backup_file.dump

Wenn die Checksumme passt, siehst du OK. Wenn nicht – die Datei ist beschädigt.

Daten auf Datenbank-Ebene prüfen

Checksummen und Logs sind nice, aber wie checkst du, ob die Daten selbst stimmen? Hier ein paar Standard-Checks:

1. Zeilenanzahl vergleichen

Vergleiche die Anzahl der Zeilen in den Tabellen vor und nach dem Restore. Zum Beispiel:

-- Zeilenanzahl in der Tabelle students zählen
SELECT COUNT(*) FROM students;

Wenn die Anzahl unterschiedlich ist, war das Restore nicht komplett.

2. Integrität der Keys prüfen

Check die Beziehungen zwischen den Tabellen, um sicherzugehen, dass alle Foreign Keys funktionieren:

-- Check für Studenten, die in Kursen eingeschrieben sind
SELECT *
FROM enrollments e
LEFT JOIN courses c
ON e.course_id = c.course_id
WHERE c.course_id IS NULL;

Wenn die Query Ergebnisse liefert, gibt es in enrollments Zeilen mit fehlenden Kursen.

3. Daten mit dem Original vergleichen

Wenn du eine Kopie der Daten hast (z.B. ein Dump einer anderen DB), kannst du die Ergebnisse vergleichen:

-- Daten aus der Tabelle courses prüfen
SELECT * FROM courses WHERE course_id NOT IN (
  SELECT course_id FROM courses_backup
);

Echte Restore-Cases

Ein Praxisbeispiel: Einmal wollte der DB-Admin Bob nach einem Servercrash Daten aus dem Backup wiederherstellen. Er hat diesen Befehl ausgeführt:

pg_restore -U admin -d my_database my_backup.dump

Aber beim Log-Check kam ein Fehler:

ERROR:  could not create file "base/16385/pg_internal.init": No space left on device

Das hieß, dass der Speicherplatz auf der Platte voll war. Nachdem er Platz geschaffen und das Restore nochmal gemacht hat, hat er gemerkt, dass nicht alle Tabellen wiederhergestellt wurden. Zum Glück konnte Bob dank vorher erzeugter Checksummen und aktivierter WAL-Archivierung die Datenbank komplett wiederherstellen.

Fazit zur Integritätsprüfung

Zum Abschluss der Integritätsprüfung nach dem Restore solltest du Folgendes machen:

1. Check die Logs auf Fehler und Warnungen.
2. Nutze Checksummen, um sicherzugehen, dass die Files nicht beschädigt sind.
3. Vergleiche die Datenbank auf Zeilenanzahl und Beziehungsintegrität.
4. Wenn was schiefgeht, analysiere die Fehler und starte das Restore nochmal.

Jetzt bist du ready für einen gründlichen Check und kannst sicherstellen, dass deine Daten so wiederhergestellt wurden, wie du es erwartet hast. Das Wichtigste beim Datenbank-Admin-Job ist schließlich das Vertrauen ins eigene Backup!