Backup und Recovery: die Zusage, das Protokoll und der Abfluss

Die Datenbank wird jede Nacht gesichert, alle Läufe melden Erfolg — und die Protokolldatei ist auf 400 GB gewachsen. Beides stimmt gleichzeitig, und beides folgt aus derselben dokumentierten Regel. Dieses Modul behandelt die Engine-Seite des Schutzversprechens: welches Wiederherstellungsmodell welche Zusage überhaupt erlaubt, warum eine eingeschaltete Archivierung eine Datenbank offline nehmen kann, und was ein grüner Sicherungsauftrag gerade nicht belegt.

Lehrtext · 10 Abschnitte · zuletzt geprüft: 2026-09-12

Eine Sicherung ist eine Zusage, kein Dateistapel

Die Frage „ist die Datenbank gesichert“ hat keine nützliche Antwort. Die nützliche Frage lautet: Auf welchen Zeitpunkt können wir zurück, wie lange dauert das, und wer hat das zuletzt nachgewiesen. Alles in diesem Modul hängt an dieser Umformulierung.

Möglich wird der Zeitpunkt durch dasselbe Bauteil, das auch die Dauerhaftigkeit einer einzelnen Transaktion sichert: das Protokoll. Jede Änderung wird erst dorthin geschrieben und dann in die Datendateien übernommen. PostgreSQL nennt es Write-Ahead-Log und legt es unter pg_wal/ ab, SQL Server nennt es Transaktionsprotokoll und legt es in Dateien mit der Endung .ldf.

Vollsicherung — Ein vollständiger Stand zu einem Zeitpunkt. Allein erlaubt sie die Rückkehr genau auf diesen einen Zeitpunkt — und auf keinen anderen.

Protokollsicherung — Die Änderungen seit der letzten Sicherung, in der Reihenfolge, in der sie geschrieben wurden. Sie ist das Bauteil, das aus einem einzelnen Zeitpunkt einen wählbaren macht.

Point-in-Time-Recovery — Eine Vollsicherung einspielen und danach Protokoll bis zu einem gewählten Moment nachfahren — zum Beispiel bis kurz vor das falsche DELETE.

Woran die meisten Sicherungskonzepte scheiternNicht daran, dass die Vollsicherung fehlt. Sondern daran, dass die Protokollseite nicht eingerichtet, nicht überwacht oder nicht verstanden ist. Die folgenden Abschnitte behandeln deshalb überwiegend das Protokoll.

Logisch oder physisch — zwei Sicherungen, die nicht dasselbe können

Bevor es um Zeitpunkte geht, die Grundunterscheidung. Eine logische Sicherung schreibt Anweisungen auf, mit denen sich der Inhalt wieder herstellen lässt. Eine physische Sicherung kopiert die Dateien, in denen der Inhalt liegt.

pg_dump (logisch): Erzeugt laut Dokumentation einen konsistenten Export, auch während die Datenbank benutzt wird, und blockiert dabei weder Leser noch Schreiber.
pg_basebackup (physisch): Kopiert den gesamten Cluster als Dateien oder Tar-Archiv. Die Grundlage für Point-in-Time-Recovery.
Vollsicherung (SQL Server): Physisch. Sichert die Datendateien einer Datenbank samt dem Protokollanteil, der für einen konsistenten Stand nötig ist.
Differenzsicherung (SQL Server): Nur was sich seit der letzten Vollsicherung geändert hat. Die Engine führt dafür eine eigene Karte mit, die vermerkt, welche Extents sich seit der letzten Vollsicherung geändert haben.

Der Satz, der viele Sicherungskonzepte umwirftDie PostgreSQL-Dokumentation schreibt über ihr eigenes Werkzeug: pg_dump ist außer in einfachen Fällen im Allgemeinen nicht die richtige Wahl, um regelmäßige Sicherungen von Produktionsdatenbanken zu erstellen. Der Grund steht in diesem Modul: Ein Dump ist ein einzelner Zeitpunkt. Ein Zeitpunkt allein lässt sich nicht feiner wählen, und zwischen zwei Dumps liegt der gesamte Verlust.

Die Lücke, die am Wiederherstellungstag auffälltpg_dump sichert laut Dokumentation nur eine einzelne Datenbank. Globale Objekte, die allen Datenbanken des Clusters gemeinsam sind — Rollen und Tablespaces — sind nicht enthalten; dafür gibt es pg_dumpall. Ein Dump lässt sich also fehlerfrei einspielen, und danach existiert kein einziges Konto, das sich anmelden könnte.

SQL Server: das Wiederherstellungsmodell entscheidet, was überhaupt geht

Bei SQL Server hängt die gesamte Möglichkeitsmenge an einer Einstellung je Datenbank. Sie lässt sich jederzeit umstellen — und genau das macht sie zur Stelle, an der Zusagen unbemerkt verschwinden.

SIMPLE: Unterstützt laut Dokumentation keine Protokollsicherungen. Die Engine gibt Protokollplatz automatisch wieder frei, sodass niemand ihn verwalten muss. Kein Point-in-Time-Recovery.
FULL: Verlangt Protokollsicherungen. Kein Arbeitsverlust durch eine verlorene oder beschädigte Datendatei; Rückkehr auf einen beliebigen Zeitpunkt möglich — etwa vor einen Anwendungs- oder Bedienfehler.
BULK_LOGGED: Verlangt ebenfalls Protokollsicherungen. Eine Spielart von FULL, die Massenoperationen sparsamer protokolliert. Die Protokollsicherungen können dadurch groß werden.

Die Voreinstellung hängt von der Edition abEnterprise und Standard verwenden laut Dokumentation voreingestellt FULL, Express dagegen SIMPLE. Zwei Instanzen im selben Haus können also gegensätzliche Zusagen geben, ohne dass jemand etwas eingestellt hätte — und die Testinstanz auf Express verhält sich anders als die Produktion.

SIMPLE schließt darüber hinaus Funktionen aus, die auf die Protokollkette angewiesen sind: Protokollversand, Always-On-Verfügbarkeitsgruppen und Datenbankspiegelung. Wer eine dieser Funktionen einführen will, muss vorher das Modell umstellen — und damit die Protokollsicherung einrichten, die er bisher nicht brauchte.

Der Klassiker: die Protokolldatei, die nicht aufhört zu wachsen

Ein Ticket, das in jeder Umgebung mit SQL Server irgendwann auftaucht: Das Volume läuft voll, schuld ist eine .ldf-Datei von mehreren hundert Gigabyte. Die Datenbank wird nachweislich jede Nacht gesichert. Trotzdem wächst die Datei weiter.

Der Satz aus der Dokumentation, der das erklärtIm Wiederherstellungsmodell FULL — und ebenso in BULK_LOGGED — wächst das Transaktionsprotokoll weiter, bis eine Protokollsicherung durchgeführt wird. Eine Vollsicherung erfüllt diese Aufgabe nicht. Nur die Protokollsicherung gibt den Platz im Protokoll wieder frei.

Damit ist die häufigste Konstellation beschrieben: Jemand hat eine Datenbank angelegt, sie stand voreingestellt auf FULL, und der Sicherungsauftrag macht — wie überall sonst auch — eine nächtliche Vollsicherung. Das Protokoll wurde nie gesichert und deshalb nie freigegeben. Die Zusage „Rückkehr auf einen beliebigen Zeitpunkt“ war dabei nie eingelöst: Ohne Protokollsicherungen gibt es keine Kette, aus der man einen Zeitpunkt wählen könnte.

Zwei Wege aus der vollen Platte — mit sehr verschiedenen Folgen

Szenario

Eine Datenbank steht auf FULL, das Protokoll ist auf 400 GB gewachsen, das Volume ist zu 97 Prozent belegt. Die Fachabteilung fragt, ob man „das Protokoll einfach leeren“ kann.

Anforderungen

Nachts, im Wartungsfenster
Die Zusage an die Fachabteilung ist noch nicht geprüft
Es gibt keine bestehende Protokollsicherungskette

Schritte

Zuerst klären, welche Zusage überhaupt gilt. Braucht die Fachlichkeit die Rückkehr auf einen beliebigen Zeitpunkt, oder reicht der Stand der letzten Nacht? Diese Frage entscheidet alles Weitere und ist keine technische.
Wird der Zeitpunkt gebraucht: FULL behalten und eine regelmäßige Protokollsicherung einrichten. Ab dann gibt jede Protokollsicherung Platz frei, und die Kette entsteht überhaupt erst.
Reicht der nächtliche Stand: auf SIMPLE umstellen. Dann verwaltet die Engine den Protokollplatz selbst — und die Zusage sinkt ausdrücklich und dokumentiert auf „bis zur letzten Vollsicherung“.
Erst danach die gewachsene Datei verkleinern. Das Verkleinern ist der letzte Schritt, nicht der erste: Ohne geänderte Ursache wächst sie sofort wieder.

Merksatz: Die Platte ist das Symptom. Die Entscheidung ist, welche Wiederherstellungszusage gelten soll — und die trifft nicht der Betrieb allein.

PostgreSQL: Archivierung einschalten heißt, einen Abfluss zu bauen

PostgreSQL löst dieselbe Aufgabe anders. Es gibt kein Wiederherstellungsmodell je Datenbank; es gibt eine Archivierung je Cluster, und sie besteht aus drei Einstellungen.

wal_level: Muss auf replica oder höher stehen. Bei minimal lassen manche Befehle die Protokollierung aus, sodass das Protokoll für eine Archiv-Wiederherstellung nicht ausreicht.
archive_mode: Auf on. Schaltet die Archivierung abgeschlossener Protokollsegmente ein.
archive_command: Der Shell-Befehl, der ein fertiges Segment an seinen Aufbewahrungsort bringt. %p ist der Pfad des Segments, %f nur der Dateiname.

Eine der drei lässt sich nicht im Betrieb ändernwal_level kann laut Dokumentation nur beim Serverstart geändert werden — eben weil bei minimal Informationen fehlen, die man nachträglich nicht erzeugen kann. archive_command dagegen lässt sich mit einem Neuladen der Konfiguration ändern. Wer die Archivierung einführt, plant also ein Neustartfenster ein; wer sie später anpasst, nicht.

Das Gegenstück beim Wiederherstellen heißt restore_command und holt die Segmente zurück. Es hat eine Eigenheit, die bei eigenen Skripten regelmäßig übersehen wird: Der Befehl wird auch nach Dateien gefragt, die im Archiv nicht vorhanden sind, und muss dann einen Wert ungleich null zurückgeben. Die Dokumentation hält ausdrücklich fest, dass das kein Fehlerzustand ist — so erkennt die Wiederherstellung ihr Ende.

Wenn der Abfluss verstopft, geht die Datenbank offline

Die Archivierung ist ein Abfluss. Solange er offen ist, bleibt pg_wal/ klein. Ist er zu, passiert genau das, was die SQL-Server-Seite beim fehlenden Protokoll-Backup auch tut — nur endet es härter.

Wörtlich aus der DokumentationSolange die Lage nicht behoben ist, füllt sich das Verzeichnis pg_wal/ weiter mit Protokollsegmenten. Füllt sich das Dateisystem, in dem `pg_wal/` liegt, führt PostgreSQL eine PANIC-Abschaltung durch. Es gehen keine bestätigten Transaktionen verloren, aber die Datenbank bleibt offline, bis Platz freigegeben wird.

Das ist eine bemerkenswerte Konstruktion und lohnt das Nachdenken: Das System nimmt lieber einen Totalausfall in Kauf, als eine Änderung zu bestätigen, die es nicht dauerhaft machen kann. Der Ausfall ist also kein Defekt, sondern die letzte Stufe der Dauerhaftigkeitszusage.

Praktisch folgt daraus, dass ein fehlschlagendes archive_command kein Nebenschauplatz ist. Die Dokumentation warnt ausdrücklich davor, dass die Archivierung wiederholt scheitern kann, weil sie einen Eingriff braucht oder der Zielspeicher voll ist — und rät, jede Fehlerlage so zu melden, dass sie zügig aufgelöst werden kann. Auch ein nur langsames Archiv fällt darunter: Hängt es deutlich hinterher, wächst sowohl der mögliche Datenverlust als auch pg_wal/.

Ein zweiter Zeitfaktor wird beim Einrichten gern übersehen. Das Archivkommando wird laut Dokumentation nur für abgeschlossene Protokollsegmente aufgerufen. Erzeugt ein Server wenig Protokollverkehr oder hat er ruhige Phasen, kann zwischen dem Abschluss einer Transaktion und ihrer sicheren Ablage im Archiv viel Zeit vergehen — der mögliche Datenverlust ist dann nicht durch den Sicherungsplan begrenzt, sondern durch das Schreibaufkommen. Die Obergrenze dafür setzt archive_timeout: Es zwingt den Server, mindestens in diesem Abstand auf ein neues Segment zu wechseln. Der Preis steht in derselben Quelle — vorzeitig gewechselte Dateien sind genauso groß wie vollständig gefüllte, ein sehr kurzer Wert bläht also den Archivspeicher auf. Die Dokumentation nennt Werte um eine Minute als üblich sinnvoll.

Der Schalter, den man dabei kennen mussUm die Archivierung vorübergehend anzuhalten, setzt man archive_command auf die leere Zeichenkette. Die Dokumentation nennt dabei sofort die Folge: Die Protokolldateien häufen sich dann in pg_wal/ an, bis wieder ein funktionierendes Kommando eingerichtet ist. Ein „kurz abschalten“ ohne Termin ist damit eine Uhr, die auf den PANIC-Zustand läuft.

Das Archivkommando, das zu früh Erfolg meldet

Am archive_command hängt die Unversehrtheit des gesamten Archivs, und die Dokumentation formuliert die Anforderung ungewöhnlich scharf.

Die BedingungDer Befehl muss den Rückgabewert null liefern genau dann, wenn er erfolgreich war. Bekommt PostgreSQL eine Null, nimmt es an, die Datei sei sicher archiviert, und entfernt oder recycelt sie. Ein Wert ungleich null sagt dem Server, dass nicht archiviert wurde; er versucht es dann in Abständen erneut.

Ein Kommando, das fälschlich null meldet, löscht damit das Original einer Datei, die nie ankam. Der Schaden fällt nicht beim Sichern auf, sondern erst beim Wiederherstellen — dann fehlt mitten in der Kette ein Segment, und alles danach ist unerreichbar.

Deshalb verlangt die Dokumentation zusätzlich, dass ein Archivkommando sich weigert, eine bereits vorhandene Archivdatei zu überschreiben. Sie nennt das eine wichtige Sicherheitsfunktion für den Fall eines Bedienfehlers — etwa wenn die Ausgaben zweier verschiedener Server in dasselbe Archivverzeichnis geleitet werden. Das dokumentierte Beispiel für Unix baut die Prüfung deshalb als eigenen Schritt vor das Kopieren.

Die Abkürzung, die genau das Falsche tutNaheliegend wäre, statt des Prüfschritts einfach cp -i zu verwenden. Die Dokumentation warnt davor namentlich: GNU cp liefert mit -i den Rückgabewert null, wenn die Zieldatei bereits existiert — und das ist nicht das gewünschte Verhalten. Der Server hält die Datei dann für archiviert und wirft sie weg.

Wo mehr als ein Befehl nötig ist, empfiehlt die Dokumentation ein eigenes Skript und dazu den logging_collector: Alles, was das Skript auf die Standardfehlerausgabe schreibt, erscheint dann im Serverprotokoll und macht eine fehlschlagende Archivierung überhaupt erst diagnostizierbar.

Die Kette, die nicht reißen darf

Point-in-Time-Recovery ist kein einzelner Vorgang, sondern eine Kette aus einer Grundsicherung und allen Protokollteilen danach. Jedes fehlende Glied begrenzt die Wiederherstellung auf den Moment davor — alles Spätere ist verloren, auch wenn es im Archiv liegt.

Grundsicherung einspielen→Archivierte Protokollsegmente nachfahren→Zielzeitpunkt festlegen→Wiederherstellung abschließen→Fachlich prüfen, bevor die Anwendung wieder darf

Kette vor Zeitpunkt

Der Fallstrick beim Erstellen der GrundsicherungWird eine Grundsicherung über die einfache Schnittstelle erstellt, wartet der Abschluss voreingestellt darauf, dass alle benötigten Protokollsegmente archiviert sind. Dieses Warten lässt sich abschalten, um Zeit zu sparen. Die Dokumentation warnt ausdrücklich: Wird die Archivierung nicht ordentlich überwacht, enthält die Sicherung dann möglicherweise nicht alle Protokolldateien, ist unvollständig und nicht wiederherstellbar. Eine Sicherung, die schneller fertig war, kann also eine sein, die es nicht gibt.

Auf der SQL-Server-Seite heißt dieselbe Sache Protokollkette. Sie beginnt mit einer Vollsicherung und setzt sich aus lückenlosen Protokollsicherungen zusammen. Ein Wechsel des Wiederherstellungsmodells nach SIMPLE und zurück unterbricht sie — danach ist eine neue Vollsicherung nötig, bevor wieder ein Zeitpunkt wählbar ist. Wer also „nur kurz“ auf SIMPLE stellt, um eine große Umstellung schneller zu machen, wirft die bestehende Zusage weg und muss sie danach neu aufbauen.

Was in der Sicherung nicht drin ist

Die letzte Kategorie von Fehlern betrifft nicht die Technik, sondern den Umfang. Drei Dinge fehlen regelmäßig, und alle drei fallen erst am Wiederherstellungstag auf.

Konfigurationsdateien. Die PostgreSQL-Dokumentation hält ausdrücklich fest, dass die Protokollarchivierung zwar alle Änderungen an den Daten wiederherstellen kann, nicht aber Änderungen an postgresql.conf, pg_hba.conf und pg_ident.conf — diese werden von Hand bearbeitet, nicht über SQL. Sie gehören in die Dateisicherung.
Globale Objekte. Rollen und Tablespaces sind laut Dokumentation nicht Teil eines pg_dump. Auf der SQL-Server-Seite entspricht dem, dass Logins in master liegen und nicht in der Nutzdatenbank — nach dem Wiederherstellen auf einer anderen Instanz fehlen sie.
Der Betrieb um die Daten herum. Die Sicherungshistorie und alle Aufträge des SQL Server Agent liegen in msdb. Wird nur die Fachdatenbank gesichert, sind die Nutzdaten vollständig und der gesamte automatisierte Betrieb muss von Hand rekonstruiert werden.

Kurzcheck

Ein Restore-Test auf einer Ersatzinstanz läuft technisch fehlerfrei durch. Was belegt er noch nicht?

Dass die Anwendung mit dem wiederhergestellten Stand arbeiten kann
Dass die Sicherungsdateien lesbar waren
Dass die Grundsicherung zum eingespielten Zeitpunkt passt

Treffer. Richtig. Fehlende Rollen, fehlende Konfiguration oder eine unvollständige Protokollkette zeigen sich nicht im Erfolg des Wiederherstellungsbefehls, sondern erst, wenn sich etwas anmelden und lesen soll.

Preis des einzigen echten NachweisesWiederherstellbarkeit lässt sich nur durch einen Wiederherstellungsversuch belegen, und zwar auf einer getrennten Instanz mit anschließender fachlicher Prüfung. Das kostet Speicher, Rechenzeit und einen Menschen, der die Fachlichkeit beurteilen kann — regelmäßig, nicht einmalig. Wer diesen Preis nicht zahlt, hat keine geprüfte Zusage, sondern eine Vermutung mit Zeitstempel.

Die Reihenfolge, die das zusammenhält

Zusage klären: welcher Zeitpunkt, welche Dauer, wessen Entscheidung→Modell beziehungsweise Archivierung danach einstellen→Abfluss überwachen, nicht nur einrichten→Umfang prüfen: Konfiguration, Rollen, Betriebsdaten→Auf einer getrennten Instanz wiederherstellen und fachlich prüfen

Zusage vor Technik

Schritt drei ist der, der in den meisten Umgebungen fehlt. Eine eingerichtete Archivierung meldet sich nicht von selbst, wenn sie stehen bleibt — sie füllt still ein Verzeichnis, und die Meldung kommt erst, wenn das Volume voll ist. Auf beiden Systemen ist das dieselbe Geschichte mit verschiedenen Namen: ein Schutzmechanismus, dessen Abfluss verstopft ist, wird vom Schutz zur Ausfallursache.

AbgrenzungWie aus einer vorhandenen Sicherung wieder ein benutzbarer Dienst wird — Reihenfolge über mehrere Dienste, Priorisierung unter Knappheit, Führung der Lage — steht im Track backup-disaster-recovery, unter anderem im Modul über den Wiederanlauf einzelner Workloads. Hier ging es ausschließlich um die Engine-Seite: wie das Schutzversprechen konfiguriert, am Leben gehalten und nachgewiesen wird. Die Trennung von Datenadministration und Sicherungsverwaltung steht im Modul über Zugriff und Identitäten.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität6 Primärquellen · zuletzt geprüft: 2026-09-12