KI-Agenten auf dem eigenen Rechner sind eine feine Sache, und können bei vielen Dingen enorm nützlich sein. Aber dann liest man immer wieder, harmlose Aufgabe, zack, Home-Directory gelöscht, oder am besten gleich die ganze Platte. Und dann traut man sich doch nicht, das auf einem Produktiv-System einzusetzen. Wir hatten Ihnen dazu schon einmal eine Idee vorgestellt, heute haben wir eine weitere für Sie.
Die Variante, den KI-Agenten auf einem separaten System auszuführen, und die Kommunikation mittels SSHFS zu vereinfachen, wie in unserem Artikel „Der beste Freund der Agenten“ beschrieben, hilft nicht in jedem Szenario, beispielsweise dann nicht, wenn es tatsächlich erforderlich ist, dass der Agent auf dem System selbst konfigurieren kann. Aber wenn dabei etwas schiefgeht?
Dann wäre es doch nett, wenn man jederzeit schnell auf den letzten funktionierenden Stand zurücksetzen könnte. Ein Snapshot für eine gültige Konfiguration, der fehlerhafte Löschungen oder falsche Einstellungen zurücksetzen könnte.
So etwas gibt es tatsächlich, und zwar mit dem Filesystem BTRFS (gemeinhin gesprochen als „ButterFS“). Man kann es bei fast jedem Linux als Filesystem einstellen, Default / Standard ist es aber unseres Wissens nur mit Fedora.
Falls Ihr Rechner nicht mit BTRFS eingerichtet ist, ist das leider eine recht große Operation. Das läuft auf eine Neu-Installation hinaus. Falls Sie aber BTRFS haben, oder für Ihr nächstes System, hier eine Kurzanleitung, wie Sie Snapshots unter BTRFS aktivieren können und Ihr System so einrichten, dass es automatisch laufend Snapshots anlegt, mit denen Sie Ihr System sogar dann noch reparieren können, wenn ein wildgewordener Agent es so völlig zerstört hatte, dass es noch nicht einmal mehr booten kann.
Die Einrichtung ist in wenigen Schritten erledigt. Zunächst installieren Sie das Werkzeug snapper, das die Snapshot-Verwaltung für BTRFS übernimmt:
sudo dnf install snapper
Anschließend legen Sie für jedes Subvolume, das Sie überwachen möchten, eine eigene Konfiguration an. Root und Home sind die naheliegende Wahl:
sudo snapper -c root create-config /
sudo snapper -c home create-config /home
Snapper legt standardmäßig automatisch Snapshots nach einem Zeitplan an – bei aktuellen Fedora-Versionen ist diese Timeline-Funktion bereits aktiviert. Werfen Sie trotzdem einen Blick in die Konfiguration, um sicherzugehen:
sudo snapper -c root get-config | grep TIMELINE_CREATE
Auf die Häufigkeit der automatischen Snapshots gehen wir hier bewusst nicht weiter ein – die Standardeinstellung von Snapper erstellt stündlich einen Snapshot und hält davon eine sinnvolle Anzahl vor, bevor ältere automatisch aufgeräumt werden. Für den hier beschriebenen Zweck, ein Sicherheitsnetz gegen verunglückte Agenten-Aktionen oder fehlgeschlagene Updates, hat sich das in der Praxis als völlig ausreichend erwiesen, ohne dass man an den Zeitplänen noch etwas ändern müsste. Wer es dennoch enger oder großzügiger takten möchte, findet die entsprechenden Stellschrauben unter den TIMELINE_*-Einträgen der jeweiligen Konfiguration (etwa TIMELINE_LIMIT_HOURLY, TIMELINE_LIMIT_DAILY und so weiter) – für den Einstieg braucht es das aber nicht.
Wichtig ist außerdem, dass Snapshots beschreibbar bleiben, statt read-only zu sein – sonst lässt sich im Ernstfall nicht so einfach zurückrollen. Das stellen Sie für beide Configs so ein:
sudo snapper -c root set-config SNAPSHOTS_ARE_READ_ONLY="no"
sudo snapper -c home set-config SNAPSHOTS_ARE_READ_ONLY="no"
Damit die automatischen Snapshots und deren Aufräumarbeiten tatsächlich laufen, aktivieren Sie noch die passenden Systemd-Timer:
sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
Ab sofort haben Sie ein funktionierendes Snapshot-System – und genau hier beginnt das eigentliche Problem. Ein Snapshot nützt nämlich nichts, wenn Sie im Notfall nicht wissen, welche ID Sie zurückspielen müssen. Sie können zwar aus GRUB heraus auf einen früheren Snapshot booten, aber dafür brauchen Sie die passende Snapshot-ID – und die aus einem System auszulesen, das gar nicht mehr bootet, ist offensichtlich keine Option.
Die Lösung dafür ist denkbar einfach: Ein kleines Skript, das die Liste aller vorhandenen Snapshots regelmäßig in eine Textdatei außerhalb des Systems selbst schreibt – beispielsweise nach /root/, wo sie auch nach einem Fehlstart über ein Rettungssystem oder einen Live-Stick noch einsehbar ist. Im Kern liest so ein Skript einfach snapper -c root list und snapper -c home list aus und speichert die Ausgabe mit einem Zeitstempel ab. Per Cronjob lassen Sie das Skript regelmäßig laufen – etwa einmal pro Stunde reicht in der Praxis meistens aus. So haben Sie im Ernstfall immer eine aktuelle Referenzliste mit Snapshot-IDs zur Hand, ganz ohne auf das eigentliche System zugreifen zu müssen.
Hier ist ein Beispiel für ein solches Script, das via crontab von root alle 60 Minuten aufgerufen wird (mit minimaler Systemlast – Sie können es problemlos auch häufiger laufen lassen, z.B. alle 5 Minuten):
#!/bin/bash
{
echo "=== ROOT SNAPSHOTS ==="
echo "Stand: $(date)"
echo ""
snapper -c root list
echo ""
echo "=== HOME SNAPSHOTS ==="
snapper -c home list
} > /root/snapper-list.txt
Man kann damit im Rescue-System oder beim Booten mit einer Live-Disk in /root jederzeit die verfügbaren Snapshots mit Zeitstempel auslesen.
Der zweite Baustein betrifft nicht die automatischen, sondern die manuellen Snapshots. Die Timeline-Snapshots greifen ja nach einem festen Zeitplan – bei einem Systemupdate kann aber durchaus etwas dazwischen passieren, bevor der nächste automatische Snapshot fällig wäre. Deshalb lohnt es sich, in das eigene Update-Skript (also dort, wo Sie dnf upgrade oder Ähnliches aufrufen) eine Zeile einzubauen, die vor dem eigentlichen Update einen manuellen Snapshot mit erklärender Beschreibung erzwingt, etwa:
snapper -c root create --description "vor-update"
snapper -c home create --description "vor-update"
Geht beim Update etwas schief, wissen Sie durch die Beschreibung sofort, welcher Snapshot der richtige zum Zurückrollen ist – und mit der weiter oben beschriebenen Liste finden Sie auch die zugehörige ID wieder, selbst wenn das System danach nicht mehr hochfährt.
Mit diesen wenigen Bausteinen – Snapper-Konfiguration, aktive Timer, einer extern gesicherten Snapshot-Liste und einem erzwungenen Snapshot vor jedem Update – haben Sie ein Netz mit doppeltem Boden: Selbst wenn ein KI-Agent oder ein missglücktes Update das System in einen unbrauchbaren Zustand versetzt, bleibt der Weg zurück offen.
Und noch ein letzter Hinweis: Die Snapshot-Erstellung mit snapper ist sehr schnell. Sie merken davon im Betrieb, zumindest mit SSD oder NVMe, rein gar nichts.