Coding-Agenten haben inzwischen Shell-Zugriff auf reale Systeme. Sie führen Migrationen aus, bereinigen Verzeichnisse, setzen Branches zurück und entfernen scheinbar überflüssige Dateien. Meist ist genau das beauftragt. Neu ist jedoch die Fehlerart, weshalb Backups für KI-Agenten eine eigene Kategorie bilden: Eine für den Agenten erreichbare Kopie kann er auch zerstören, häufig während einer eigentlich angeforderten Aufgabe.
Dies ist kein hypothetisches Risiko, das nur Speicher verkaufen soll. Wer Agenten gegen einen aktiven Checkout ausführt, hat häufig schon eine unbeabsichtigte Löschung beobachtet. Diese Seite beschreibt ein belastbares Sicherungsmuster und benennt ebenso deutlich seine Grenzen.
Warum Ihr vorhandenes Backup kein Backup für KI-Agenten ist
Das traditionelle Bedrohungsmodell geht von Hardwarefehlern, menschlichem Irrtum oder Ransomware aus. Agenten liegen quer zu allen drei Kategorien, weil sie mit Ihren Zugangsdaten, in Maschinengeschwindigkeit und mit einer plausiblen Begründung handeln.
Ein eingebundenes Netzlaufwerk ist für alles sichtbar, was als Ihr Nutzer läuft. Das gilt auch für synchronisierte Ordner, zugeordnete Laufwerke und Objektspeicher, deren Schlüssel in einer lesbaren Umgebungsdatei liegen. Hält der Agent ein Verzeichnis für alte Build-Ausgaben, möchte ein Repository zurücksetzen oder Speicher freigeben, kann alles Erreichbare betroffen sein. Die Synchronisierung überträgt die Löschung anschließend auf die vermeintliche Sicherung, denn genau dazu ist sie konzipiert.
Der entscheidende Unterschied liegt daher nicht zwischen Cloud und lokal, sondern darin, ob die Kopie aus der Agentenumgebung erreichbar und authentifizierbar ist.
Das Sicherungsmuster für KI-Agenten: übertragen, nicht synchronisieren
Dieser Punkt wird oft falsch umgesetzt und verdient eine eigene Überschrift.
Synchronisierung ist grundsätzlich bidirektional. Lokale Löschungen werden remote nachvollzogen. Das ist für Arbeitsdateien erwünscht, zerstört aber ein Archiv. Viele als Backup bezeichnete Systeme sind tatsächlich Synchronisierung: Sie schützen vor einem ausgefallenen Datenträger, nicht vor Löschung. Staatliche Empfehlungen zur Ransomware-Resilienz betonen dies seit Jahren. CISA empfiehlt, eine Kopie vom geschützten System zu isolieren. Ein Agent mit Shell-Zugriff ist lediglich eine schnelle neue Möglichkeit, diese Bedingung zu verletzen.
Ein funktionierendes Backup lädt neues Material hoch und spiegelt keine Löschungen. Ziele mit Zeitstempel oder Datum sorgen dafür, dass jeder Lauf ergänzt statt ersetzt. Dreißig tägliche Kopien eines Datenbank-Dumps kosten bei üblichen Größen häufig weniger als die Arbeitszeit, die eine nicht mögliche Wiederherstellung verursacht.
Getrennte Zugangsdaten sind der entscheidende Mechanismus
Der Mechanismus ist unspektakulär, was bei Backups ein Vorteil ist. Benötigt wird ein reiner Übertragungsweg mit Zugangsdaten, die die Arbeitsumgebung nie besitzt.
Drive unterstützt nach den beschriebenen Funktionen gerätebezogene App-Passwörter, die im Dashboard erstellt und einzeln widerrufen werden können. Ein eigenes Backup-Geheimnis liegt ausschließlich auf dem System oder im geplanten Job, der die Übertragung ausführt. Es gehört nie in den Projektbaum, eine gemeinsame Umgebungsdatei oder einen dem Agenten zugänglichen Ort. Der Agent arbeitet frei an der Arbeitskopie, besitzt aber keinen Zugang zum Ziel.
Läuft der Job auf demselben Rechner, muss das Geheimnis außerhalb des Projektbaums und mit restriktiven Dateirechten liegen. Läuft er auf einem getrennten Gerät oder Runner, ist die Trennung stärker, weil kein Dateisystem gemeinsam genutzt wird. Das Backup überlebt nicht allein wegen eines Löschverbots, sondern weil der Agent kein gültiges Geheimnis für das Ziel erhält. Betriebssystemweite oder privilegierte Zugriffe müssen dabei separat berücksichtigt werden.
Wogegen ein Backup für KI-Agenten schützt und wogegen nicht
Präzision ist hier wichtiger als Beruhigung.
Es schützt vor versehentlichem Löschen oder Überschreiben in der Arbeitsumgebung, einem bereinigenden Skript, einem unbeabsichtigten Repository-Reset und gewöhnlichen menschlichen Fehlern mit dem falschen Löschziel. Es kann auch gegen die getreue Synchronisierung einer unerwünschten Löschung schützen.
Es schützt nicht vor Personen mit Dashboard-Anmeldung und zweitem Faktor, denn diese können App-Passwörter widerrufen und den Papierkorb leeren. Es verhindert keine absichtliche Archivlöschung und ersetzt keine Versionskontrolle für Quellcode, die ein anderes Problem besser löst.
Ein Backup für KI-Agenten ist eine Schutzschicht, kein vollständiges Sicherheitsprogramm. Andere Behauptungen wären übertrieben.
Was sich zu sichern lohnt
Die Liste ist kürzer als erwartet, weil sich vieles in einem Arbeitsverzeichnis reproduzieren lässt.
- Datenbank-Dumps. Sie lassen sich tatsächlich nicht neu erzeugen. Nachts, datiert und so lange aufbewahrt, wie Tarif und Richtlinie erlauben.
- Umgebungs- und Konfigurationsdateien. Klein, selten gesichert und mühsam wiederherzustellen. Gerade sie werden von gut gemeinten Bereinigungen leicht entfernt. Geheimnisse erfordern verschlüsselte Sicherung und eingeschränkten Zugriff.
- Hochgeladene Nutzerinhalte. Nicht in der Versionskontrolle, nicht reproduzierbar und oft erst nach dem Verlust bemerkt.
- Wichtige erzeugte Artefakte. Berichte und Exporte aus einem inzwischen veränderten Prozess.
Quellcode gehört meist nicht hierher, weil ein korrekt konfiguriertes entferntes Git-Repository bereits eine unabhängige Kopie bietet. Die zusätzliche Sicherung schadet nicht, ist aber nicht Hauptzweck dieser Schicht.
Aufbau eines nächtlichen Jobs
Die Umsetzung ist bewusst kurz. Wenig Wartungsaufwand erhöht die Chance, dass sie dauerhaft funktioniert.
Ein geplanter Job läuft einmal pro Nacht. Er schreibt einen Datenbank-Dump in eine temporäre Datei, versieht sie mit dem Datum, lädt sie in einen datierten Drive-Pfad und entfernt die lokale temporäre Kopie. Konfigurationsdateien und Uploads folgen demselben Weg. Der Job besitzt eigene Zugangsdaten, bezieht sie nicht aus dem Projektverzeichnis und enthält in seiner Ziel-Logik keine Löschoperation.
Zwei Details unterscheiden ein funktionierendes Backup von einem unbemerkt defekten. Erstens muss der Zielpfad das Datum enthalten, damit jeder Lauf neu erstellt statt ersetzt. Jeden Abend denselben Dateinamen hochzuladen ergibt genau eine Sicherung, nämlich die letzte Nacht, und hilft nicht bei einem am Donnerstag bemerkten älteren Problem. Zweitens muss der Job Fehler deutlich melden. Ein seit sechs Wochen unbemerkt fehlschlagendes Backup ist besonders gefährlich, weil man sich darauf verlässt.
Wiederherstellung testen
Ein nie wiederhergestelltes Backup ist nur eine Hypothese. Genau hier sind viele Einrichtungen am schwächsten.
Nehmen Sie einmal pro Quartal eine Sicherungsdatei und stellen Sie sie in einer entsorgbaren, isolierten Umgebung wieder her. Prüfen Sie drei Dinge: vollständigen Download, Vollständigkeit statt Abbruch während des Jobs und die dokumentierte Beherrschung des Ablaufs. Der dritte Punkt ist wichtig, denn im Notfall sollte das Verfahren bereits bekannt sein.
Die Wiederherstellungsprüfung bestätigt außerdem, dass die erforderlichen Zugriffspfade weiterhin funktionieren und Geheimnisse nicht unbemerkt widerrufen oder rotiert wurden. Ein reines Übertragungsgeheimnis kann bei fehlender Überwachung in einer Richtung scheitern, während die Umgebung normal wirkt.
Wie lange Daten aufbewahrt werden sollten
Aufbewahrung ist eher eine Speicher- und Richtlinienfrage als eine technische. Die sinnvolle Dauer ist oft länger als zunächst gewählt.
Der geschützte Fehler wird nicht immer sofort erkannt. Ein gelöschtes Verzeichnis fällt innerhalb von Stunden auf, subtile Datenbeschädigung oder monatlich genutzte Dateien möglicherweise erst nach Wochen. Dreißig tägliche Kopien liefern einen Monat Historie und decken viele Fälle ab. Bei üblichen Dump-Größen ist dies oft wenig Speicher, bei sehr großen Datenbanken muss es berechnet werden.
Ein gängiges Muster behält einen Monat lang jede tägliche Kopie und danach ein Jahr lang eine pro Monat. Das begrenzt das Wachstum und ermöglicht ältere Wiederherstellungen. Bereinigen Sie bewusst mit einem getrennten, eng berechtigten Job und einer geprüften Richtlinie. Sobald der Uploader selbst löschen kann, wird das ursprünglich vermiedene Risiko wieder eingeführt.
Geeigneter Speicherort
Drive gehört zum selben Konto wie die E-Mail, wodurch weniger Dienste und Rechnungen nötig sind. Das Add-on beginnt nach den beschriebenen Preisen bei 250 GB für 3.20 $ im Monat und reicht über einen Regler bis 100 TB. Für ein Backup ist neben dem Preis wichtig, dass nach dem beschriebenen Modell keine Egress-Gebühren anfallen. Tarifbedingungen sollten vor einer großen Wiederherstellung dennoch geprüft werden.
Speicher kann kontoweit gemeinsam genutzt oder pro Postfach abgegrenzt werden, sodass das Backup-Ziel von anderen Verbrauchern getrennt bleibt. Uploads erfolgen über WebDAV oder API. Einzelheiten zur Einbindung bietet der WebDAV-Leitfaden. Ordner können nach Berechtigungsprüfung mit einem anderen Konto geteilt werden, damit Kollegen ohne Ihre Zugangsdaten wiederherstellen können. Dies erläutert unser Leitfaden zu Freigabelinks.
Nichts daran ist exotisch: ein datierter Ordner, nicht in der Arbeitsumgebung vorhandene Zugangsdaten und ein Job, der nur ergänzt. Agenten machen eine alte Empfehlung wieder entscheidend: Die rettende Kopie ist jene, zu der sich nichts in der Arbeitsumgebung authentifizieren kann.
