Sheet happens. In der letzten Vorlesung haben wir uns auch den Schritt-für-Schritt-Prozess zur vollständigen Wiederherstellung einer Datenbank nach einem Ausfall angeschaut. Aber die Realität liebt Überraschungen. Was tun, wenn dein Backup beschädigt ist? Jetzt ist es Zeit, das zu klären.
Wo sollte man den Lebenslauf ablegen?
Scherz. Jetzt geht's um technische Themen. Aber vergiss nicht: In jedem Scherz steckt ein Körnchen Wahrheit :)
Analyse der beschädigten Sicherungskopie
Beschädigtes Backup – das ist wie deine Abschlussarbeit, die sich kurz vor der Abgabe nicht mehr öffnen lässt. Die Symptome sind ähnlich:
- Fehler beim Versuch der Wiederherstellung: Beim Ausführen von
pg_restorekannst du Fehler wie diese sehen:
pg_restore: [archiver] input file does not appear to be a valid archive
- Ein Teil der Daten fehlt oder die Datei hat eine falsche Größe (zum Beispiel plötzlich sehr klein oder sogar null).
- Die entpackte SQL-Datei enthält Datenabbrüche, komische Zeichen oder leere Abschnitte.
Backups können aus vielen Gründen beschädigt werden:
- Abbruch des Backup-Prozesses (z.B. Stromausfall oder System-Shutdown).
- Fehlerhafte Dateiübertragung (Fehler beim Kopieren auf einen USB-Stick oder übers Netzwerk).
- Hardware-Probleme (Festplatten, RAM, Fehler im RAID-Array).
- Fehler in der Systemkonfiguration oder im Backup-Tool.
- Viren, Malware und natürlich der spontane "falsche Klick".
Datenwiederherstellung aus einer beschädigten Kopie
Wenn die Datei beschädigt ist, ist das noch nicht das Ende. Manchmal kann man trotzdem noch etwas retten. Lass uns ein paar Ansätze anschauen.
Wiederherstellungsversuch mit pg_restore
Wenn die Datei mit pg_dump im custom- oder directory-Format erstellt wurde, versuch die Wiederherstellung mit pg_restore und dem Flag --ignore-errors. Beispielbefehl:
pg_restore --dbname=your_database --ignore-errors backup_file.dump
Dieses Flag sagt dem Tool, Fehler beim Wiederherstellen zu ignorieren und weiterzumachen. Klar, die Daten an den beschädigten Stellen sind verloren, aber vielleicht kannst du wenigstens einen Teil retten.
Wenn das klappt, solltest du die wiederhergestellten Daten nach Abschluss sorgfältig prüfen und dokumentieren, was fehlt.
Verwendung von Teil-Daten
Angenommen, du hast ein Backup im Textformat SQL. Öffne es mit einem Texteditor (am besten was Modernes wie Visual Studio Code oder Notepad++), um zu sehen, wo es abbricht. Wenn die Datei lesbar ist und die meisten SQL-Statements intakt sind:
- Lösch den beschädigten Teil der Datei.
- Führe die restlichen SQL-Statements manuell oder mit
psqlaus:
psql -U username -d database_name -f partial_backup.sql
Lesen einer custom-Format-Datei
Wenn dein Backup im custom-Format ist, kannst du versuchen, den Inhalt stückweise zu extrahieren:
pg_restore --list backup_file.dump > file_list.txt
Dieser Befehl erstellt eine Liste aller Objekte im Backup. Dann kannst du versuchen, einzelne Elemente (z.B. Tabellen oder Schemas) mit folgendem Befehl wiederherzustellen:
pg_restore --dbname=your_database --use-list=file_list.txt backup_file.dump
Wenn du file_list.txt bearbeitest, kannst du beschädigte Elemente vom Restore ausschließen.
Wiederherstellung über Archiv-Logs (WAL)
Wenn du inkrementelle oder differenzielle Backups nutzt (z.B. mit pg_basebackup), hast du wahrscheinlich Archiv-Logs (WAL-Dateien). Sie speichern alle Änderungen seit dem letzten Backup. Um Daten wiederherzustellen, kannst du:
- Das letzte vollständige Backup finden.
- PostgreSQL sagen, wo die WAL-Dateien liegen:
restore_command = 'cp /path/to/wal_directory/%f %p'
- Die Wiederherstellung durchführen.
Verwendung von Drittanbieter-Tools
Manchmal kann man den Schaden mit File-Recovery-Tools minimieren. Ein beliebtes Tool ist ddrescue. Beispielbefehl:
ddrescue --force backup_file.dump recovered_dump.file
Dieses Tool versucht, so viele Daten wie möglich zu retten und eine neue Kopie der Datei zu erstellen.
Vorbeugung von Backup-Beschädigungen
Mit beschädigten Dateien zu arbeiten ist Stress pur. Lass uns überlegen, wie man sowas vermeiden kann.
Backups an mehreren Orten speichern
Wie im Projekt gilt beim Backup immer die Regel: "Leg nicht alle Eier in einen Korb". Du solltest deine Backups duplizieren:
- Auf dem lokalen Server.
- In der Cloud (Amazon S3, Google Cloud Storage oder sogar mit einem einfachen Service wie Dropbox).
- Auf externen Datenträgern (wenn du super-sicher sein willst).
Regelmäßige Integritätsprüfung der Backups
Es gibt ein Sprichwort in der IT: "Ein Backup, das nie getestet wurde, ist kein Backup." Teste deine Backups regelmäßig, indem du eine Test-Wiederherstellung machst. Dazu:
- Lade das Backup auf einen Testserver.
- Stelle die Daten daraus wieder her.
- Prüfe, ob alles korrekt ist.
Verwendung von Checksummen
Beim Erstellen von Backups solltest du Checksummen für die Dateien generieren (z.B. mit MD5 oder SHA256):
md5sum backup_file.dump > backup_file.md5
Beim Wiederherstellen vergleichst du die aktuelle Checksumme mit dem Original:
md5sum -c backup_file.md5
So erfährst du frühzeitig von einer beschädigten Datei.
Beispiele für die Wiederherstellung aus beschädigten Backups
Schauen wir uns ein paar echte Fälle an.
Case 1. Fehler beim Datei-Transfer
Du überträgst ein Backup per FTP, aber plötzlich merkst du, dass die Datei kleiner ist als erwartet. Du hast pg_dump im Textformat benutzt, also:
- Datei im Editor geöffnet.
- Den beschädigten Teil entfernt.
- Den funktionierenden Teil mit
psqlwiederhergestellt.
Case 2. Teilweiser Datenverlust in WAL
Dein Server nutzte inkrementelle Backups und archivierte WAL-Dateien. Plötzlich sind einige Dateien verschwunden. Aber du konntest die Daten mit pg_basebackup und den noch vorhandenen WAL-Dateien wiederherstellen, indem du deren Pfad in den Restore-Einstellungen angegeben hast.
Denk dran: Backup bedeutet nicht nur Kopien machen, sondern auch testen. Warte nicht auf die Apokalypse, um zu merken, dass deine Backups nutzlos sind. Und falls doch mal was kaputtgeht, keine Panik: PostgreSQL bietet viele Wege, deine Daten zurückzuholen. Wichtig ist, schnell und sorgfältig zu handeln!
Und wenn gar nichts hilft – lies nochmal den ersten Punkt dieser Vorlesung.
GO TO FULL VERSION