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.