Worktrees, Checkpoints und Berichte als Datensicherungen

Agentische Systeme verändern Dateien, erzeugen Artefakte, aktualisieren Konfigurationen und stoßen externe Prozesse an. Während ein Mensch häufig nach wenigen Schritten innehält, kann ein Agent lange Aktionsketten ausführen. Ein Fehler betrifft dann nicht nur das Endergebnis: Auch Zwischenstände, Entscheidungen und Abhängigkeiten können verloren gehen.

In diesem Umfeld werden Worktrees, Commits und Run-Berichte schnell als „Datensicherung" bezeichnet. Das ist verständlich, aber technisch zu ungenau. Ein Worktree ist ein paralleler Arbeitsbaum, kein unabhängiger Datenbestand. Ein Commit enthält nicht automatisch ungetrackte Dateien, Datenbanken oder Geheimnisse. Ein Bericht kann einen Zustand beschreiben, aber fehlende Bytes nicht wiederherstellen.

Eine belastbare Architektur trennt deshalb vier Aufgaben: Arbeitsisolation, Versionierung, Betriebsnachweis und Backup mit geprüftem Restore.

Worktrees isolieren Arbeit, nicht den Ausfall

Git kann mehrere Arbeitsbäume mit demselben Repository verbinden. Dadurch lassen sich verschiedene Branches gleichzeitig auschecken. Für agentische Arbeit ist das wertvoll: Ein Agent bearbeitet einen klar benannten Auftrag in einem eigenen Verzeichnis, während der Hauptarbeitsraum sauber bleibt. Diffs, Tests und Freigaben werden pro Aufgabe übersichtlicher.

Die Isolation besitzt jedoch Grenzen. Verknüpfte Worktrees teilen wesentliche Repository-Daten und Referenzen. Beschädigung, Fehlkonfiguration oder Verlust des gemeinsamen Repositorys kann mehrere Arbeitsbäume gleichzeitig treffen. Auch externe Abhängigkeiten – Datenbank, Objektablage, Cache, Modellartefakte oder Secret Store – werden durch einen zusätzlichen Worktree nicht kopiert.

Ein Worktree ist daher eine Kollisions- und Kontaminationsgrenze. Er hilft gegen versehentlich vermischte Änderungen und macht parallele Arbeit kontrollierbar. Gegen Hardwareverlust, Ransomware, fehlerhafte Bereinigung oder den Ausfall eines gemeinsamen Speichers ist er allein keine Sicherung.

Der Vorzustand muss bekannt sein

Bevor ein Agent arbeitet, braucht der Run eine Ausgangsreferenz. Dazu gehören Repository und Branch, Commit-ID, Zustand des Index, Änderungen im Arbeitsbaum, ungetrackte Dateien, Submodule, relevante Tool-Versionen und referenzierte externe Datensnapshots.

Ein sauberer Start ist einfacher zu prüfen als ein unbekannt „schmutziger" Arbeitsraum. Muss ein Run auf bestehenden Änderungen aufbauen, werden diese nicht unsichtbar übernommen. Ein Preflight-Manifest beschreibt sie ausdrücklich und legt fest, ob sie Bestandteil des Auftrags, geschützter Fremdzustand oder Blocker sind.

git status hilft, Index, Arbeitsbaum und ungetrackte Dateien sichtbar zu machen. Sichtbarkeit ist aber noch keine Sicherung. Nicht verfolgte Dateien bleiben außerhalb eines Commits, bis sie bewusst aufgenommen werden. Ignorierte Dateien benötigen eine eigene Behandlung.

Ein Checkpoint ist eine semantische Zustandsmarke

Nicht jeder Commit ist ein guter Checkpoint. Ein Checkpoint bezeichnet einen Zustand, an den fachlich und technisch sinnvoll zurückgekehrt werden kann. Er besitzt einen Zweck: etwa „Import abgeschlossen", „Schema migriert, Validierung erfolgreich" oder „Publikationspaket vorbereitet, noch nicht freigegeben".

Ein belastbarer Checkpoint ist atomar genug, um verstanden zu werden, und vollständig genug, um nicht von unsichtbaren Zwischenaktionen abzuhängen. Er enthält oder referenziert:

• die aufgenommenen Dateien und ihre Commit-ID,

• ein Manifest externer Snapshots und Artefakte,

• Versionen von Schema, Konfiguration und Werkzeugen,

• Prüfresultate und bekannte Abweichungen,

• Owner, Zeit, Run-ID und nächsten erlaubten Übergang.

Checkpoint-Namen ersetzen keine unveränderliche Identität. Ein Branch oder Tag kann verschoben werden; die Commit-ID adressiert den konkreten Git-Zustand. Für externe Artefakte werden stabile Objekt-IDs, Versionen oder Hashes benötigt.

Commits erfassen nur den versionierten Ausschnitt

Ein Commit ist eine starke Grundlage für nachvollziehbare Dateizustände, aber kein Schnappschuss des gesamten Projekts. Er nimmt den Inhalt auf, der über den Index oder einen gezielten Commit ausgewählt wurde. Lokale Datenbanken, große Binärdateien, generierte Exporte, Logs, Zugangsdaten und ungetrackte Dateien können außerhalb bleiben.

Deshalb beginnt Sicherungsplanung mit einem State Inventory. Es unterscheidet mindestens:

1. versionierte Quellen und Konfiguration,

2. nicht versionierte, aber autoritative Projektdaten,

3. generierte, reproduzierbare Artefakte,

4. Laufzeitzustand und Queues,

5. externe Dienste und Datenbanken,

6. Secrets und Identitätsmaterial,

7. Cache, der gelöscht und neu aufgebaut werden darf.

Für jede Klasse gelten andere Sicherung und Wiederherstellung. Ein Cache benötigt möglicherweise gar kein Backup, wohl aber eine dokumentierte Neubildung. Secrets werden nicht in Git kopiert, sondern über einen gesicherten Secret-Lifecycle wieder bereitgestellt.

Ein Run-Bericht ist Nachweis, keine Kopie

Der Run-Bericht verbindet Auftrag, Vorzustand, Plan, Aktionen, Tool-Aufrufe, Diffs, Tests, Freigaben, Checkpoints und Ergebnis. Er beantwortet: Was sollte geschehen? Was ist tatsächlich geschehen? Welcher Zustand entstand? Welche Objekte wurden extern verändert? Was blieb offen?

Ein guter Bericht verwendet stabile Referenzen. Statt „die aktuelle Datei" nennt er Pfad, Version oder Hash. Statt „Backup erfolgreich" nennt er Sicherungsjob, Ziel, Prüfergebnis und letzten Restore-Test. Der Bericht wird getrennt vom flüchtigen Laufzeitzustand aufbewahrt und darf nicht nachträglich unprotokolliert überschrieben werden.

Trotzdem ersetzt der Bericht keine Nutzdaten. Eine Liste verlorener Dateien stellt sie nicht wieder her. Sein Wert liegt in Provenienz, Diagnose und Auswahl des richtigen Recovery-Punkts.

Echte Backups brauchen einen anderen Fehlerbereich

Eine Kopie auf demselben Datenträger, Konto oder administrativen Kontrollpfad kann vom selben Ereignis zerstört werden. Belastbare Backups liegen in einem getrennten Fehlerbereich. Je nach Risiko bedeutet das ein anderes Speichersystem, getrennte Berechtigungen, unveränderliche Aufbewahrung, geografische Trennung oder eine offline gehaltene Kopie.

Für Git kann ein Remote die Verfügbarkeit erhöhen, ist aber nicht automatisch ein vollständiges Backup: Nicht gepushte Commits und lokale Referenzen fehlen, und fehlerhafte oder böswillige Änderungen können repliziert werden. Ein vollständiges Bundle kann Git-Objekte und Referenzen transportierbar verpacken. Auch dieses Bundle muss getrennt gespeichert, geschützt, verifiziert und im Restore getestet werden.

Externe Daten benötigen anwendungskonsistente Snapshots. Eine bloße Dateikopie einer laufenden Datenbank kann unbrauchbar sein. Backup und Checkpoint müssen deshalb koordiniert werden: Der Bericht referenziert genau den Datenbanksnapshot, der zum Commit und zur Schema-Version gehört.

RPO und RTO machen Sicherungsziele konkret

Der Recovery Point Objective beschreibt, wie viel Datenverlust zeitlich akzeptabel ist. Der Recovery Time Objective beschreibt, wie schnell der Betrieb wiederhergestellt sein muss. Beide Werte folgen der Wirkung, nicht der Bequemlichkeit des Tools.

Ein tägliches Backup kann unzureichend sein, wenn ein Agent pro Stunde tausende Änderungen ausführt. Umgekehrt muss ein reproduzierbarer Zwischenexport nicht sekündlich gesichert werden. Autoritative Zustände, externe Wirkung und Freigabepunkte bestimmen die Frequenz.

RPO und RTO werden für das gesamte System geprüft. Ein Repository in fünf Minuten wiederherzustellen hilft wenig, wenn Datenbank, Artefakte, Berechtigungen und Run-Queue zwei Tage benötigen.

Restore-Tests sind die eigentliche Wahrheitsprobe

„Backup vorhanden" ist eine Behauptung. Ein Restore-Test liefert Evidenz. Er stellt Daten in einer isolierten Umgebung wieder her, prüft Integrität und Verknüpfungen, startet definierte Validierungen und vergleicht das Ergebnis mit dem Checkpoint-Manifest.

Git bietet Prüfmechanismen für Objektkonnektivität und Bundles. Sie sind wichtig, aber nicht ausreichend: Auch fachliche Vollständigkeit, externe Snapshots, Dateirechte, Schlüsselzugang und Startreihenfolge müssen stimmen. Ein Restore kann technisch erfolgreich und operativ wertlos sein, wenn die referenzierte Datenversion fehlt.

Tests finden regelmäßig und nach relevanten Architekturänderungen statt. Gemessen werden tatsächliche Wiederherstellungszeit, Datenlücke, manuelle Schritte und Abweichungen. Findings aktualisieren Runbooks, Automatisierung und Sicherungsumfang.

Agentische Wiederaufnahme braucht Idempotenz

Nach einem Abbruch darf ein Agent nicht blind am letzten Textsatz weitermachen. Der Orchestrator liest den letzten bestätigten Checkpoint und unterscheidet vorbereitete, ausgeführte und extern bestätigte Aktionen. Wiederholbare Schritte erhalten Idempotenzschlüssel oder eindeutige Aktions-IDs.

Das verhindert doppelte Nachrichten, doppelte Buchungen oder mehrfach angewandte Migrationen. Für nicht idempotente Aktionen braucht es vor Wiederaufnahme eine Zustandsabfrage und gegebenenfalls menschliche Entscheidung.

Locks und Leases verhindern, dass zwei Runs denselben Zielbestand gleichzeitig verändern. Ein verwaister Lock besitzt Ablauf- und Recovery-Regeln; er darf nicht einfach gelöscht werden, ohne den letzten Zustand zu prüfen.

Ein Sicherungsprotokoll verbindet die Ebenen

Ein robuster Run folgt einer kontrollierten Sequenz:

1 · INVENTORY: autoritative und abgeleitete Zustände erfassen.

2 · BASELINE: Commit, Arbeitsbaum und externe Snapshot-Referenzen festhalten.

3 · ISOLATE: eigenen Worktree und eng begrenzte Rechte bereitstellen.

4 · EXECUTE: kleine, prüfbare Änderungen mit laufendem Journal ausführen.

5 · CHECKPOINT: semantisch vollständigen Zustand committen und manifestieren.

6 · REPORT: Diffs, Tests, Wirkung, Freigaben und offene Punkte dokumentieren.

7 · REPLICATE: Repository und externe Sicherungen in getrennten Fehlerbereich übertragen.

8 · VERIFY: Integrität prüfen und Recovery-Punkt katalogisieren.

9 · RESTORE: regelmäßig in isolierter Umgebung wiederherstellen.

Diese Sequenz macht aus Versionskontrolle noch kein Backup. Sie verbindet jedoch die Systeme so, dass ein technischer Stand, seine Bedeutung und seine Wiederherstellbarkeit gemeinsam nachgewiesen werden können.

Übungsblatt: Entwirf eine Recovery Chain Map

1. Inventarisiere Git-Dateien, ungetrackte Daten, Datenbanken, Artefakte, Secrets, Queues und Caches.

2. Ordne jeder Klasse Owner, Autorität, Backup-Verfahren, RPO und RTO zu.

3. Definiere Worktree-Baseline und Preflight-Manifest.

4. Lege drei semantische Checkpoints mit Eintritts- und Austrittskriterien fest.

5. Entwirf den Run-Bericht mit stabilen Referenzen und Evidenzfeldern.

6. Wähle einen getrennten Fehlerbereich und beschreibe Verschlüsselung und Aufbewahrung.

7. Schreibe einen Restore-Test einschließlich Abbruch- und Wiederaufnahmeregeln.

Reflexion: Welcher wichtige Projektzustand liegt heute außerhalb der Versionskontrolle? Welches „Backup" wurde noch nie vollständig wiederhergestellt?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Das Modell ist produktunabhängig; konkrete Aufbewahrungs-, Verschlüsselungs- und Wiederherstellungsanforderungen folgen Datenklasse, Risiko und geltenden Pflichten. Fachlich geprüft am 17. Juli 2026.