Append-only Log: Warum Protokolle nur ergänzt statt überschrieben werden

Die Schreibregel eines Append-only Logs

Das Prinzip gilt unabhängig davon, ob ein Log Messwerte, Zugriffe oder fachliche Vorgänge aufzeichnet. Die geordnete Folge und der Umgang mit bereits aufgenommenen Einträgen bestimmen seine Struktur.

Eine spätere Berichtigung erscheint als zusätzlicher Eintrag. Die technische Absicherung gegen Eingriffe außerhalb des vorgesehenen Schreibmodells ist gesondert zu betrachten.

Zwei Einträge, eine erhaltene ursprüngliche Buchung

Ein fiktives Verbrauchsprotokoll enthält an Position 104 den Eintrag B-104: 12,5 Kilogramm verbraucht, bezogen auf eine bestimmte Charge und Aufgabe. An Position 105 folgt K-105 mit dem Bezug auf B-104 und der Berichtigung auf 11,5 Kilogramm. B-104 bleibt mit seinem ursprünglichen Inhalt lesbar.

Für die Append-only-Eigenschaft ist entscheidend, dass die spätere Information hinzukommt und die vorherige Folge erhalten bleibt. Ob K-105 schon geprüft ist und wie sich der Verbrauch auf den Bestand auswirkt, beantworten zusätzliche fachliche Regeln. Eine Lesesicht darf diese Angaben nicht allein aus der höheren Positionsnummer ableiten.

Data Provenance beschreibt ergänzend die Herkunftsbeziehungen: etwa wer den Verbrauch erfasst hat und welcher Beleg zur Berichtigung führte. Die Logposition erklärt dagegen, an welcher Stelle der Eintrag in die gespeicherte Folge aufgenommen wurde.

Reihenfolge ist mehr als ein Zeitstempel

Ein Append-only Log benötigt eine definierte Ordnung. In einem einzelnen Prozess kann eine fortlaufende Sequenznummer genügen. In verteilten Systemen können mehrere Komponenten nahezu gleichzeitig schreiben, Uhren voneinander abweichen oder Einträge verspätet übertragen werden. Dann ist „nach Zeitstempel sortieren“ nicht automatisch gleichbedeutend mit der tatsächlichen fachlichen Reihenfolge.

Deshalb sollte die Architektur unterscheiden zwischen dem Zeitpunkt, zu dem etwas geschah, dem Zeitpunkt, zu dem es erfasst wurde, und der Position, an der es verbindlich in das Log aufgenommen wurde. Zusätzlich können Kausalitätsbezüge ausdrücken, dass ein Eintrag auf einem anderen beruht oder durch ihn ausgelöst wurde.

Eine globale Reihenfolge ist nicht immer erforderlich. Für manche Fragen reicht eine verlässliche Reihenfolge je Charge, Aufgabe oder Datenstrom. Entscheidend ist, dass die gewählte Ordnung zum fachlichen Zweck passt und bei konkurrierenden Einträgen ein festgelegtes Verhalten besteht.

Was ein belastbarer Logeintrag enthalten sollte

Ein Log ist nur so aussagekräftig wie seine Einträge. Eine bloße Folge unstrukturierter Textmeldungen lässt sich später schwer zuordnen, filtern oder fachlich beurteilen. Ein belastbarer Eintrag benötigt deshalb eine stabile Identität und einen eindeutig beschriebenen Kontext.

Typische Bestandteile sind:

• Eintragskennung: eine eindeutige ID, über die andere Einträge und Auswertungen auf den Vorgang verweisen können;
• Ereignistyp: eine fachliche Bezeichnung wie „Messwert erfasst“, „Material gebucht“, „Prüfung abgeschlossen“ oder „Korrektur angelegt“;
• Zeitangaben: mindestens der Zeitpunkt der Erfassung und, wenn abweichend, der Zeitpunkt des fachlichen Geschehens;
• Akteur: die identifizierte Person, Rolle, Anwendung oder Maschine, die den Eintrag ausgelöst hat;
• Bezugsobjekte: etwa Charge, Produkt, Aufgabe, Gerät, Material oder Dokument;
• Nutzdaten: der erfasste Wert, Zustandswechsel oder fachliche Inhalt;
• Versionen: verwendete SOP-, Modell-, Schema- oder Regelversionen;
• Beziehungen: Verweise auf vorausgehende, korrigierte oder ausgelöste Einträge.

Die Felder müssen nicht in jedem System gleich heißen. Wichtig ist ihre definierte Bedeutung. Ein Zeitstempel ohne bekannte Zeitzone oder ein Benutzername ohne stabile Identität kann formal vorhanden sein und dennoch keine belastbare Zuordnung ermöglichen.

Logische Historie und physischer Speicher sind zu trennen

Der Begriff wird missverständlich, wenn „nur ergänzen“ als Verbot jeder physischen Veränderung gelesen wird. Datenbanken reorganisieren Seiten, schreiben Indizes neu, erzeugen Sicherungen oder verschieben Daten in andere Speicherklassen. Auch eine kontrollierte Migration kann Einträge in eine neue technische Struktur überführen.

Solche Operationen widersprechen dem logischen Append-only-Prinzip nicht zwangsläufig. Sie müssen jedoch die fachlich sichtbaren Einträge, ihre Reihenfolge, Identitäten und Beziehungen erhalten. Wenn Verdichtung oder Archivierung zulässig ist, braucht sie definierte Regeln. Eine Zusammenfassung darf beispielsweise die operative Abfrage beschleunigen, sollte aber nicht unbemerkt die einzige Kopie der ursprünglichen Historie ersetzen, wenn diese weiterhin aufbewahrt werden muss.

Auch Löschanforderungen müssen ausdrücklich behandelt werden. Datenschutz, Aufbewahrungsfristen oder berechtigte Bereinigung können mit einem unbegrenzten Log kollidieren. Die Lösung besteht nicht in der pauschalen Behauptung, Daten seien unveränderlich, sondern in einer abgestimmten Aufbewahrungs-, Sperr-, Archivierungs- und Löschstrategie.

Nach einer Wiederherstellung muss dieselbe Folge lesbar sein

Ein erfolgreicher Sicherungslauf allein zeigt noch nicht, dass das Log wieder verwendbar ist. Bei einer Wiederherstellung ist zu prüfen, ob Einträge, Positionen, Identitäten und notwendige Bezugsversionen zusammenpassen. Fehlt etwa der referenzierte Ursprung B-104, erklärt eine erhaltene Korrektur K-105 den Vorgang nicht mehr vollständig.

Das Betriebskonzept muss außerdem festlegen, welcher bestätigte Stand gesichert wurde und wie danach entstandene Einträge behandelt werden. Ein wiederhergestellter älterer Stand darf nicht unbemerkt als vollständiger aktueller Verlauf erscheinen. Indizes und Archivspeicher können den Zugriff unterstützen; der Nachweis der erhaltenen Folge bleibt davon getrennt.

Append-only allein schützt nicht vor Manipulation

Eine Anwendungsoberfläche kann nur das Hinzufügen neuer Einträge erlauben, während ein privilegierter Datenbankzugriff ältere Datensätze weiterhin verändern könnte. Deshalb ist die logische Schreibregel nur eine Kontrollschicht. Technische und organisatorische Maßnahmen müssen sie absichern.

Dazu gehören restriktive Schreib- und Administrationsrechte, getrennte Verantwortlichkeiten, protokollierte Wartung, gesicherte Zeitquellen, regelmäßige Sicherungen, Wiederherstellungstests sowie Überwachung auf unerwartete Änderungen. Die Anforderungen richten sich nach Kritikalität, Bedrohungsmodell und Einsatzkontext.

Kryptografische Verfahren können zusätzliche Prüfbarkeit schaffen. Eine Hash-Verkettung verbindet aufeinanderfolgende Einträge über ihre Prüfwerte; RFC 9162 beschreibt für Certificate Transparency ein öffentlich prüfbares Append-only Log, dessen Merkle-Baum Konsistenznachweise zwischen einem früheren und einem späteren Stand ermöglicht.^[1] Dieses Beispiel zeigt zugleich die Abgrenzung: Die überprüfbare Append-only-Eigenschaft entsteht dort erst durch eine konkrete kryptografische Struktur und ein Prüfverfahren. Sie ist keine automatische Eigenschaft jeder Tabelle, die nur INSERT-Operationen vorsieht.

NIST beschreibt Blockchains als manipulationssichtbare und manipulationsresistente verteilte Register, weist aber ebenfalls auf unterschiedliche Berechtigungs- und Vertrauensmodelle hin.^[2] Ein Append-only Log benötigt weder Blockchain noch Token. Ob Hash-Verkettung, externe Prüfpunkte oder digitale Signaturen erforderlich sind, ist eine separate Architekturentscheidung.

Korrekturen schreiben die Historie fort

In einem klassischen Datensatz wird ein fehlerhafter Wert häufig direkt ersetzt. Danach ist ohne zusätzliche Protokollierung nicht mehr erkennbar, welcher Wert zuvor vorhanden war. Im Append-only-Modell wird die Korrektur als eigener Vorgang behandelt.

Ein Korrekturereignis sollte den ursprünglichen Eintrag eindeutig referenzieren, den korrigierten Inhalt nennen und den fachlich erforderlichen Grund erhalten. Je nach Prozess gehören außerdem die ausführende Person, eine prüfende Rolle und eine Freigabe dazu. Die Anwendung kann anschließend eine aktuelle Sicht erzeugen, in der der korrigierte Wert gilt. Die zugrunde liegende Historie enthält weiterhin beide Einträge.

Damit werden Fehler nicht konserviert, um sie weiterzuverwenden. Sie werden erhalten, damit der tatsächliche Verlauf nachvollziehbar bleibt. Die aktuelle Darstellung muss klar unterscheiden, welcher Wert gültig ist und welcher nur einen früheren Stand dokumentiert. Sonst kann eine vollständige Historie zu einer unklaren operativen Sicht führen.

Für geregelte Änderungen ist ein Audit Trail die nähere Kontrollperspektive: Er beschreibt, welche relevanten Eingaben und Änderungen mit Identität, Zeitpunkt und gegebenenfalls Grund nachvollziehbar sein müssen. PIC/S und FDA betonen dabei die Erhaltung ursprünglicher Informationen und die Rekonstruierbarkeit relevanter Änderungen.^[3][4] Das Append-only Log ist dagegen das allgemeinere Speicherprinzip, mit dem solche Änderungen als zusätzliche Einträge erhalten werden können.

Eine aktuelle Sicht kann das Log ergänzen

Aus B-104 und K-105 kann eine Anwendung eine Ansicht mit dem gültigen Verbrauch bilden, wenn die Bedeutung und der Prüfstatus beider Einträge feststehen. Ein Zugriffslog braucht eine solche Zustandsberechnung möglicherweise gar nicht. Projektionen gehören deshalb zu den möglichen Nutzungen eines Logs, nicht zu seiner Definition.

Event Sourcing geht weiter: Dort bilden fachliche Ereignisse die maßgebliche Grundlage des Anwendungszustands. Die Regeln für dessen Neuaufbau sind Teil dieses Entwurfs.[5]

Eine vollständige Historie kann dennoch falsche Daten enthalten

Das Erhalten früherer Einträge macht sichtbar, was aufgezeichnet wurde. Es beweist nicht, dass der Inhalt sachlich richtig war. Ein falsch kalibriertes Gerät, eine verwechselte Materialkennung oder eine unzutreffende manuelle Eingabe kann ordnungsgemäß in einem Append-only Log gespeichert sein.

Datenintegrität verlangt deshalb mehr als ein bestimmtes Speicherverhalten. Vollständigkeit, Konsistenz und Genauigkeit entstehen über den gesamten Datenlebenszyklus: durch geeignete Erfassung, Zuordnung, Prüfung, Schutz, Aufbewahrung und kontrollierte Korrektur. Das Append-only-Prinzip unterstützt die Nachvollziehbarkeit, ersetzt diese Kontrollen aber nicht.

Ebenso wichtig ist Vollständigkeit. Wenn relevante Vorgänge das Log umgehen, bleibt die gespeicherte Folge intern konsistent und bildet trotzdem nicht die gesamte betriebliche Wirklichkeit ab. Schnittstellenfehler, Offline-Arbeit und nachträgliche Sammelbuchungen müssen daher erkennbar und kontrolliert behandelt werden.

Was ein Append-only Log nicht automatisch ist

• Kein vollständiger Audit Trail: Ohne Akteur, Zeitpunkt, Grund und fachlichen Kontext bleibt eine Änderung möglicherweise unzureichend erklärt.
• Kein Event Sourcing: Ein Log kann Informationen fortschreiben, ohne die maßgebliche Quelle aller Anwendungszustände zu sein.
• Keine Unveränderbarkeit: Administrative Zugriffe oder technische Fehler können ältere Daten beeinflussen, wenn keine weiteren Kontrollen bestehen.
• Keine Blockchain: Verteilte Konsensmechanismen sind für das grundlegende Speicherprinzip nicht erforderlich.
• Keine automatische Datenrichtigkeit: Ein fehlerhafter Wert kann vollständig und geordnet gespeichert werden.
• Keine unbegrenzte Aufbewahrung: Fristen, Datenschutz und Archivierungsregeln müssen separat festgelegt werden.

Die alte Folge muss im neuen Stand wiederzufinden sein

Das Buchungsbeispiel lässt sich auf eine einfache Kontrollfrage zurückführen: Ist B-104 nach dem Hinzufügen von K-105 noch mit derselben Identität und demselben Inhalt vorhanden? Bei größeren Logs muss diese Frage für den maßgeblichen früheren Stand und seine Ordnung beantwortbar bleiben.

Damit wird Append-only konkret prüfbar. Die Schreibregel, ihre Absicherung und der Erhalt im Betrieb greifen ineinander. Die fachliche Bewertung einer Korrektur sowie die Berechnung einer aktuellen Ansicht bauen darauf auf, benötigen aber eigene Regeln.