Konsistenzpunkte: was eine Sicherung im Moment des Lesens wirklich einfängt

Ein Sicherungslauf über vier Stunden bildet keinen Zeitpunkt ab, sondern eine Mischung — und ob daraus ein verwertbarer Bestand wird, entscheidet die Bauart der Anwendung, nicht ihre Wichtigkeit. Dieses Modul zeigt, was ein eingefrorenes Dateisystem leistet und was nicht, warum eine Datenbank mit Vorabprotokoll mit Absturzkonsistenz zurechtkommt, warum anwendungskonsistente Sicherungen unter Last an einer 60-Sekunden-Grenze scheitern und warum zwei Snapshots im Abstand von drei Sekunden kein gemeinsamer Zeitpunkt sind.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Eine Sicherung ist kein Zeitpunkt, solange niemand einen daraus macht

Ein Sicherungslauf über vier Stunden liest die ersten Dateien um 23:00 und die letzten um 03:00. Was er ablegt, ist kein Zustand des Systems um 23:00 und keiner um 03:00, sondern eine Mischung — und je mehr die Anwendung in dieser Zeit gearbeitet hat, desto weniger ergibt diese Mischung zusammen einen Sinn.

Für einen Ordner mit Urlaubsfotos ist das gleichgültig. Für eine Datenbank, deren Indizes auf Datendateien verweisen, für eine Anwendung, die Belege in zwei Dateien gleichzeitig schreibt, oder für ein System, das seinen Zustand teils im Arbeitsspeicher hält, ist es der Unterschied zwischen einem verwertbaren und einem unbrauchbaren Bestand.

Der Begriff, um den es geht, hat einen unauffälligen Namen und trägt die halbe Wiederherstellbarkeit: der Konsistenzpunkt. Er ist die Antwort auf die Frage, welchen einen Zustand ein Bestand abbildet — und wenn niemand dafür gesorgt hat, ist die Antwort: keinen. Dieselbe Frage stellt sich auf drei Ebenen nacheinander, und auf jeder kann sie anders ausfallen: innerhalb einer Datei, innerhalb eines Datenträgers und über mehrere Systeme hinweg.

Die Frage dieses ModulsNicht „ist die Sicherung vollständig?“ — das war das Thema des Umfangs. Sondern: Ist das, was gesichert wurde, in sich stimmig, und wer sorgt dafür? Die Antwort hängt an drei Dingen: dem Dateisystem, der Anwendung und der Zahl der beteiligten Datenträger. Alle drei sind dokumentiert, und alle drei werden regelmäßig verwechselt.

Drei Stufen, die auseinandergehalten werden müssen

Dateisystemkonsistenz — Das Dateisystem selbst ist stimmig: Metadaten, Journal und Daten passen zusammen. Über den Inhalt der Dateien sagt das nichts.

Absturzkonsistenz — Der Bestand entspricht dem Zustand nach einem plötzlichen Stromausfall. Alles, was auf der Platte war, ist da; alles, was nur im Arbeitsspeicher stand, fehlt. Anwendungen mit eigenem Protokoll können daraus wieder hochkommen — andere nicht.

Anwendungskonsistenz — Die Anwendung hat vor dem Lesen mitgewirkt: offene Transaktionen abgeschlossen, Protokolle umgeschaltet, Zwischenspeicher geleert. Der Bestand entspricht einem sauberen Zustand, nicht einem abgebrochenen.

Die Reihenfolge ist aufsteigend, und jede Stufe kostet mehr. Die entscheidende Erkenntnis für den Entwurf: Welche Stufe nötig ist, bestimmt nicht die Wichtigkeit der Daten, sondern die Bauart der Anwendung. Eine Datenbank mit Transaktionsprotokoll kommt mit der mittleren Stufe zurecht; eine Anwendung, die Zustand über zwei Dateien ohne Protokoll verteilt, braucht die oberste.

Was ein eingefrorenes Dateisystem leistet

Unter Linux stellt fsfreeze(8) die untere Stufe her. Die Handbuchseite beschreibt genau, was beim Einfrieren passiert: Alle laufenden Transaktionen des Dateisystems dürfen abschließen, neue write(2)-Aufrufe werden angehalten, andere verändernde Aufrufe ebenfalls, und sämtliche schmutzigen Daten, Metadaten und Protokollinformationen werden auf die Platte geschrieben. Jeder Prozess, der danach schreiben will, blockiert, bis wieder aufgetaut wird.

Zwei Sätze, die viel Arbeit sparenErstens hält dieselbe Seite fest, dass fsfreeze bei Device-Mapper-Geräten unnötig ist: Der Device-Mapper und damit auch LVM friert das Dateisystem beim Anlegen eines Snapshots automatisch ein. Wer auf LVM arbeitet und das nachbaut, verdoppelt einen Mechanismus, den es schon gibt. Zweitens: Das Einfrieren erzeugt laut Beschreibung ein stabiles Abbild auf der Platte — es sagt nichts darüber, was die Anwendung noch im Arbeitsspeicher hält. Das ist genau die Grenze zwischen der ersten und der dritten Stufe.

Praktisch heißt das: Ein eingefrorenes Dateisystem plus Snapshot liefert einen absturzkonsistenten Bestand. Ob der brauchbar ist, entscheidet die Anwendung darüber — nicht das Dateisystem.

Anwendungskonsistenz braucht die Anwendung

Die oberste Stufe lässt sich von außen nicht herstellen. Nur die Anwendung weiß, was eine abgeschlossene Transaktion ist und welche Zwischenspeicher noch nicht auf der Platte stehen. Unter Windows ist dieser Mitwirkungsweg als Schnittstelle ausgeprägt und gut dokumentiert.

Die Anwendungskomponente meldet, was gesichert werden muss→Sie schließt offene Transaktionen ab, rollt Protokolle und leert Zwischenspeicher→Schreibzugriffe der Anwendung werden eingefroren, Lesezugriffe bleiben möglich→Die Dateisystempuffer werden geleert und das Dateisystem eingefroren→Der Schattenkopie-Anbieter legt die Kopie an→Dateisystem und Anwendung werden wieder aufgetaut

Die Anwendung friert zuerst ein und taut zuletzt auf

Die beiden Zahlen, die alles erklärenDie Dokumentation nennt harte Grenzen: Das Einfrieren der Anwendung darf 60 Sekunden nicht überschreiten, und das Anlegen der Schattenkopie höchstens 10 Sekunden. Wird eine der beiden überschritten, wird der Vorgang abgebrochen. Genau das erklärt einen verbreiteten Befund: Auf einem stark belasteten System scheitert die anwendungskonsistente Sicherung reproduzierbar, während sie auf demselben System am Wochenende durchläuft. Es ist kein Konfigurationsfehler, sondern eine Zeitgrenze — und die Abhilfe liegt bei der Last, nicht bei der Sicherungssoftware.

Welche Komponenten überhaupt mitwirken können, lässt sich abfragen: vssadmin list writers zeigt die auf dem System angemeldeten Schreiber. Steht die eigene Fachanwendung nicht darunter, wird sie auch nicht ruhiggestellt — dann ist die Sicherung absturzkonsistent, ganz gleich, was das Sicherungsprodukt in seinen Berichten behauptet.

Absturzkonsistent ist oft genug — unter einer Bedingung

Der verbreitete Reflex, Absturzkonsistenz sei grundsätzlich unzureichend, ist falsch, und die PostgreSQL-Dokumentation formuliert die Gegenposition ungewöhnlich klar. Zu einem Snapshot des Datenverzeichnisses im laufenden Betrieb heißt es dort: Die Sicherung enthält die Dateien in einem Zustand, als wäre der Server nicht ordentlich heruntergefahren worden; beim Start auf diesem Bestand nimmt der Server einen Absturz an und spielt das Write-Ahead-Log nach. Und dann der entscheidende Satz — das sei kein Problem, man solle es nur wissen und die WAL-Dateien in die Sicherung einschließen.

Kommt mit Absturzkonsistenz zurecht: Alles mit eigenem Vorabprotokoll: relationale Datenbanken, Nachrichtenspeicher mit Journal, journalierende Dateisysteme.
Kommt nicht damit zurecht: Anwendungen, die Zustand über mehrere Dateien ohne gemeinsames Protokoll verteilen; Dateien, die in großen Blöcken überschrieben werden; alles, was Zustand nur im Arbeitsspeicher hält.
Die Bedingung: Das Protokoll muss vollständig mitgesichert sein. Eine Datenbank ohne ihr Vorabprotokoll ist kein wiederherstellbarer Bestand, sondern ein Trümmerfeld mit ordentlichen Dateinamen.

Daraus folgt eine Prüffrage, die vor jeder Diskussion über Ruhigstellung steht: Hat diese Anwendung ein Vorabprotokoll, und ist es im gesicherten Umfang enthalten? Ist die Antwort zweimal ja, ist der Aufwand für die oberste Stufe oft nicht nötig. Ist sie einmal nein, hilft auch die beste Ruhigstellung nicht über die Lücke hinweg.

Zwei Handgriffe aus derselben QuelleDie PostgreSQL-Dokumentation nennt zwei kleine Maßnahmen, die man leicht übersieht. Ein CHECKPOINT unmittelbar vor dem Snapshot verkürzt die Zeit, die der Server beim Start für das Nachspielen des Protokolls braucht — er verkürzt damit direkt die Wiederanlaufzeit. Und für eine Sicherung mit minimaler Abschaltzeit beschreibt sie den zweistufigen Weg mit rsync: einmal im laufenden Betrieb, dann den Server kurz anhalten und ein zweites Mal mit rsync --checksum laufen lassen — die Prüfsummenoption sei nötig, weil rsync Änderungszeiten nur sekundengenau vergleicht.

Der Fall, den kein Snapshot löst: mehrere Datenträger

Sobald die Daten einer Anwendung auf mehr als einem Dateisystem liegen, entsteht ein Problem, das sich mit Snapshots nicht sauber lösen lässt — und die Dokumentation sagt das ausdrücklich, statt es zu beschönigen.

Der Grund ist einfach und lässt sich nicht wegkonfigurieren: Ein Snapshot ist immer die Aussage eines einzelnen Speicherobjekts über sich selbst. Zwei Snapshots, nacheinander ausgelöst, beschreiben zwei verschiedene Zeitpunkte — und zwischen ihnen hat die Anwendung weitergeschrieben. Für eine Datenbank, deren Datendateien auf den einen und deren Protokoll auf den anderen Zeitpunkt zeigen, ist das kein Rundungsfehler, sondern ein Bestand, dessen Verweise ins Leere laufen.

Datendateien und Protokoll auf getrennten Datenträgern

Szenario

Eine Datenbank liegt aus Leistungsgründen auf zwei Datenträgern: Datendateien auf dem einen, das Vorabprotokoll auf dem anderen. Gesichert wird über Snapshots beider Datenträger, nacheinander, wenige Sekunden auseinander.

Anforderungen

Der Bestand soll nach dem Restore anlauffähig sein.
Die Lösung soll ohne Abschaltung der Datenbank auskommen, wenn das möglich ist.

Schritte

Das Problem benennen: Die PostgreSQL-Dokumentation hält fest, dass es bei einer über mehrere Dateisysteme verteilten Datenbank möglicherweise keinen Weg gibt, exakt gleichzeitige Snapshots aller Datenträger zu erhalten — und dass die Snapshot-Technik dann nicht benutzbar sein kann.
Prüfen, ob das Speichersystem eine übergreifende, gleichzeitige Snapshot-Gruppe für beide Datenträger anbietet. Wenn ja, ist die Frage beantwortet; wenn nein, gilt der nächste Schritt.
Auf ein Verfahren wechseln, das gegen Dateisystemänderungen während der Sicherung unempfindlich ist — bei PostgreSQL die Basissicherung mit fortlaufender Archivierung, die die Dokumentation genau für diesen Fall empfiehlt.
Wo das nicht möglich ist, den dokumentierten Notweg wählen: die Datenbank für die Dauer des Anlegens aller Snapshots anhalten.
Die getroffene Wahl im Recovery-Vertrag als Konsistenzpunkt festhalten, damit sie bei der nächsten Speicheränderung nicht unbemerkt verloren geht.

Merksatz: Ein Snapshot je Datenträger ist kein gemeinsamer Zeitpunkt. Sobald ein Bestand über mehrere Dateisysteme verteilt ist, muss entweder das Speichersystem die Gleichzeitigkeit zusichern oder das Verfahren gewechselt werden — die Sekunden Abstand sind genau die Lücke, in der die Verweise auseinanderlaufen.

Konsistenz über Systemgrenzen

Dieselbe Frage stellt sich eine Ebene höher und wird dort noch seltener beantwortet. Zwei Dienste, die miteinander arbeiten, haben getrennte Sicherungen mit getrennten Zeitpunkten. Nach einer Wiederherstellung auf zwei verschiedene Stände fehlen dem einen Dienst Vorgänge, die der andere bereits kennt.

Der Auftrag ohne Beleg. Dienst A steht auf Dienstag, Dienst B auf Mittwoch: B kennt Aufträge, zu denen A keine Daten hat.
Der doppelte Vorgang. Umgekehrt verarbeitet A einen Vorgang erneut, den B längst abgeschlossen hat.
Die verwaiste Referenz. Verweise zeigen auf Objekte, die im anderen Stand noch nicht existieren.
Der stille Fall. Nichts davon erzeugt eine Fehlermeldung — es erzeugt falsche Zahlen, und die fallen Wochen später auf.

Kurzcheck

Zwei gekoppelte Dienste sollen nach einem Ausfall wiederhergestellt werden. Für Dienst A existiert ein Stand von 02:00, für Dienst B einer von 23:00 des Vortags. Was ist die tragfähige Entscheidung?

Beide auf 23:00 zurücksetzen und die Differenz fachlich nacharbeiten.
Jeden Dienst auf seinen jüngsten Stand setzen, um den Datenverlust zu minimieren.
Dienst B auf 02:00 vorrollen, indem die fehlenden Vorgänge aus Dienst A eingespielt werden.

Treffer. Richtig. Ein gemeinsamer, älterer Stand ist überprüfbar; zwei verschiedene Stände sind es nicht. Der Preis ist bekannter Datenverlust statt unbekannter Widersprüche.

Die Einheit der Konsistenz ist die Einheit des Restores

Ein häufiger Wunsch lautet, aus einem Bestand nur eine einzelne Tabelle oder ein einzelnes Objekt zurückzuholen. Ob das geht, entscheidet nicht das Sicherungswerkzeug, sondern die Frage, wie weit die Konsistenz des Bestands reicht.

Die PostgreSQL-Dokumentation ist auch hier deutlich: Aus einer Dateisystemsicherung lassen sich einzelne Tabellen nicht zurückholen, weil die Informationen in diesen Dateien ohne die Festschreibungsprotokolle unter pg_xact/* nicht verwertbar sind — eine Tabellendatei ist nur zusammen mit dieser Information nutzbar. Umgekehrt würde ein Zurückholen der Protokolle alle anderen Tabellen unbrauchbar machen. Deshalb funktionieren Dateisystemsicherungen dort nur für den vollständigen Cluster.

Das übertragbare PrinzipDer kleinste Bereich, innerhalb dessen ein Bestand in sich stimmig ist, ist zugleich der kleinste Bereich, den man sinnvoll wiederherstellen kann. Wer feinere Wiederherstellungswege braucht — eine Tabelle, ein Postfach, ein Dokument — braucht ein Verfahren, das die Anwendung kennt, nicht ein feineres Werkzeug auf Dateiebene. Diese Entscheidung fällt in der Architektur und lässt sich im Ernstfall nicht nachholen.

In der Praxis führt das zu einer Entscheidung, die früh fällt und spät wehtut: Wer feine Wiederherstellungswege will, zahlt sie mit einem zweiten Sicherungsverfahren neben dem groben. Ein Datenbankcluster wird dann sowohl als Ganzes gesichert — für den Totalverlust — als auch über einen anwendungsnahen Weg, der einzelne Objekte kennt. Das ist doppelter Betriebsaufwand und die einzige Konstruktion, die beide Anlässe bedient.

Zustand, der außerhalb des gesicherten Bestands liegt

Selbst ein perfekt anwendungskonsistenter Bestand fängt nur ein, was zum Dienst gehört. Ein erheblicher Teil des Zustands eines laufenden Systems liegt woanders — und dieser Teil kommt bei keiner Wiederherstellung zurück.

Nachrichtenwarteschlangen: Angenommene, aber noch nicht verarbeitete Vorgänge. Nach dem Restore sind sie entweder verschwunden oder werden erneut abgearbeitet — beides ist ein fachliches Ereignis, kein technisches.
Sitzungen und Zwischenspeicher: Angemeldete Benutzer, zwischengespeicherte Berechtigungen, halb ausgefüllte Formulare. Verloren, und das ist der harmlose Fall.
Übertragungen in Arbeit: Hochgeladene Dateien ohne abgeschlossene Übernahme, teilweise geschriebene Ausgabedateien. Sie liegen im Bestand und sind unvollständig.
Zustand bei Dritten: Der Zahlungsdienstleister, der den Auftrag bereits kennt; die Schnittstelle, die eine Bestätigung erhalten hat. Hier hilft keine eigene Sicherung.

Die vierte Zeile ist die folgenreichste, weil sie in beide Richtungen wirkt. Ein wiederhergestellter Dienst kennt einen Vorgang nicht mehr, den der Partner längst gebucht hat — oder er verschickt ihn ein zweites Mal, weil seine Warteschlange auf einem älteren Stand steht. Genau deshalb gehören ausgehende Verbindungen eines wiederhergestellten Systems hinter ein Freigabetor und nicht in den automatischen Anlauf.

Die Grenze sauber ziehenDer Konsistenzpunkt eines Dienstes endet dort, wo seine Daten enden. Alles darüber hinaus ist Abgleich, nicht Wiederherstellung — eine fachliche Aufgabe mit eigenem Ablauf, eigener Zuständigkeit und eigener Dauer. Sie gehört als eigener Posten in die Wiederanlaufzeit, sonst taucht sie erst in der Nachbereitung auf, wenn jemand fragt, warum der Dienst zwar lief, die Zahlen aber nicht stimmten.

Der Konsistenzpunkt gehört in den Vertrag

Alles bisher Gesagte lässt sich je Dienst in vier Zeilen festhalten. Sie gehören neben Verlustgrenze und Wiederanlaufzeit, weil sie dieselbe Eigenschaft betreffen: was im Ernstfall tatsächlich zurückkommt.

Erforderliche Stufe: Absturzkonsistent oder anwendungskonsistent — mit Begründung aus der Bauart der Anwendung.
Wer stellt sie her: Dateisystem, Speichersystem, die Anwendung selbst oder eine Abschaltung. Mit dem Namen des Mechanismus.
Umfang der Einheit: Was gemeinsam gesichert werden muss, damit der Bestand stimmig ist — und damit die kleinste Wiederherstellungseinheit.
Gekoppelte Dienste: Welche anderen Dienste auf denselben Zeitpunkt gesetzt werden müssen.

Der Auslöser, der diese Zeilen am Leben hältJede Änderung an der Speicherarchitektur eines Dienstes berührt sie. Wird ein Vorabprotokoll auf einen eigenen Datenträger verschoben — eine gängige Leistungsmaßnahme — ändert sich damit stillschweigend das Konsistenzverhalten der Sicherung. Die Änderung fällt niemandem auf, weil die Sicherung weiterhin grün meldet. Deshalb gehört „berührt das den Konsistenzpunkt?“ in das Änderungsverfahren, nicht in eine jährliche Prüfung.

Was dieses Modul nicht behandelt

Hier geht es um den Zustand des Bestands im Moment der Sicherung. Wie einzelne Arten von Diensten anschließend wieder anlaufen — Datenbanken auf einen Zeitpunkt, Dateidienste mit ihren Berechtigungen, zustandslose Dienste in der richtigen Reihenfolge — ist Gegenstand des Moduls über Workload-Recovery.

NachbartracksDie Bordmittel der jeweiligen Plattform stehen dort, wo sie hingehören: Schattenkopien und ihre Schreiber im Detail in windows-server-administration, Snapshots auf Speicherebene in storage-file-services und virtualization-private-cloud, Datenbankinterna in database-administration-basics. Hier interessiert die Entscheidung, welche Konsistenzstufe ein Dienst braucht und wer sie herstellt.

Jetzt anwenden

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

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-04