DeepSeek Harness Daten-Backup: Upgrade sicher abnehmen

Die offizielle DeepSeek-Harness-Dokumentation nennt für die Web-Oberfläche standardmäßig 127.0.0.1:3080 als lokale Adresse. Genau deshalb reicht es nicht, nur den Quellcode oder eine einzelne Konfigurationsdatei zu kopieren: Für ein belastbares DeepSeek Harness Daten-Backup müssen Sie Umgebung, Sitzungszustand, Arbeitsbereich und Geheimnisse getrennt erfassen und anschließend eine echte Aufgabe in einer isolierten Umgebung wiederholen. (github.com)

Symptom: Nach Upgrade oder Cloud-Mac-Migration startet der Agent, aber Sitzungen fehlen, Werkzeuge zeigen auf das falsche Repository oder ein API-Schlüssel liegt im Backup.

Schnellste Lösung: Vier Schichten bilden, Schreibvorgänge vor der Kopie anhalten, jede Schicht mit einem eigenen Nachweis dokumentieren und die Übergabe erst nach einer erfolgreichen Ende-zu-Ende-Aufgabe unterschreiben.

Diese Anleitung richtet sich an Sie, wenn Sie eine Developer-Preview-Version aktualisieren, eine lokale Installation auf einen Cloud Mac verlagern oder einen dauerhaft genutzten Agent-Arbeitsbereich an ein anderes Teammitglied übergeben. Nicht gemeint ist eine allgemeine Sicherung Ihres gesamten Macs; dafür wären andere Aufbewahrungs- und Datenschutzregeln erforderlich.

SECTION 01Die vier Sicherungsschichten

Ein häufiger Fehler besteht darin, ein vermeintliches Hauptverzeichnis vollständig zu archivieren. Das wirkt zunächst sicher, vermischt aber wiederherstellbare Zustände mit Cache-Dateien, temporären Artefakten und sensiblen Zugangsdaten. Bei DeepSeek Harness ist diese Trennung besonders wichtig, weil das Projekt laut offizieller README noch als Developer Preview geführt wird und ausdrücklich mit kompatibilitätsbrechenden Änderungen rechnet. (github.com)

Die vier Schichten beantworten auch die Frage, welche Daten bei einer Neuinstallation wirklich benötigt werden. Sie müssen nicht jedes rekonstruierbare Paket dauerhaft aufbewahren. Sie müssen aber festhalten, wie die Umgebung wieder aufgebaut wird. Dazu gehören die konkrete Installationsquelle, die verwendete Version, der Startmodus sowie die abhängigen Runtime-Versionen. Die offizielle Entwicklungsdokumentation nennt beispielsweise Node.js-Anforderungen, eine festgelegte pnpm-Version und Git als Bestandteile der Entwicklungsumgebung. Diese Angaben sollten Sie als Rekonstruktionsprotokoll sichern, nicht als unkontrollierten Paketordner. (github.com)

Langfristig aufbewahren

• Installationsbefehl oder Paketquelle einschließlich Versionsangabe
• Lockfile und eigene Patch-Dateien
• Startparameter, Betriebsmodus und relevante Umgebungsvariablen ohne Geheimniswerte
• Modellkennung, Provider-Bezeichnung und gegebenenfalls eigener API-Endpunkt
• Projektanweisungen, Skills und Plugin-Liste mit Versions- oder Commit-Referenz
• Wiederherstellungsprotokoll mit Datum, Prüfer und Ergebnis

Nur nach Bedarf aufbewahren

• Paket- und Download-Caches
• temporäre Build-Verzeichnisse
• automatisch erzeugte Bundle-Dateien
• alte Logs ohne Sitzungs- oder Sicherheitsrelevanz
• Software, die anhand eines dokumentierten Lockfiles sicher neu installiert werden kann

Die entscheidende Grenze lautet: Ein Cache darf die Installation beschleunigen, darf aber nicht die einzige Quelle für einen benötigten Zustand sein.

SECTION 02Sitzungsintegrität und SessionEvent

Die Sitzungsdaten sind nicht automatisch mit einem Chat-Export gleichzusetzen. Für die Prüfung sollten Sie davon ausgehen, dass eine Session aus einer Folge persistenter Ereignisse besteht. Der relevante Prüfbegriff SessionEvent beschreibt dabei nicht nur den Textaustausch, sondern kann auch Werkzeugaufrufe, Rückgaben, Modellwahl, Genehmigungen und Statusänderungen abbilden. Welche Felder und welches Format aktuell gelten, müssen Sie gegen den offiziellen Persistence-Katalog von DeepSeek Harness und den aktuellen Quellstand prüfen. Bei einer Developer Preview darf aus einem früheren Format keine dauerhafte Kompatibilitätszusage abgeleitet werden.

Nur DSH_HOME kopieren?

Nein, nicht als allgemeine Wiederherstellungsgarantie. DSH_HOME kann einen wichtigen lokalen Speicherort enthalten, aber die bloße Existenz dieser Umgebungsvariable beweist weder, dass sämtliche Sitzungen dort liegen, noch dass Arbeitsbereiche, Plugins, Einstellungen und Provider-Konfigurationen vollständig darin enthalten sind. Die offizielle Web-UI-Anleitung beschreibt separat die Modellauswahl und die Auswahl eines Arbeitsbereichs. Das ist ein starkes Indiz dafür, dass „Sitzung vorhanden“ und „Arbeitsbereich korrekt verbunden“ getrennt geprüft werden müssen. (github.com)

Verwenden Sie deshalb keine universelle Verzeichnisliste aus einem Blog oder Forum. Ermitteln Sie den tatsächlich verwendeten Pfad in Ihrer Version und Ihrem Betriebsmodus, protokollieren Sie ihn und vergleichen Sie die enthaltenen Dateien mit dem Persistence-Katalog. Wenn DSH_HOME in Ihrer Installation nicht ausdrücklich als vollständige Sicherungsschnittstelle dokumentiert ist, behandeln Sie es nur als eine Quelle innerhalb der Sitzungsprüfung.

Konsistenzgrenze vor der Kopie

Eine SessionEvent-Datei, die während des Kopierens weiter beschrieben wird, kann formal vorhanden und dennoch logisch unvollständig sein. Vor dem Backup müssen Sie daher mindestens eine der folgenden Grenzen herstellen:

1. laufende Sessions sauber beenden;
2. den Harness-Prozess stoppen;
3. den Speicher auf einen dokumentierten Zeitpunkt einfrieren;
4. eine dateisystem- oder snapshotsichere Kopie erstellen und den Snapshot-Zeitpunkt protokollieren.

Danach zählen Sie die erwarteten Sitzungen, öffnen mindestens eine ältere und eine zuletzt aktive Sitzung und prüfen, ob Statusinformationen sowie Werkzeugereignisse lesbar sind. Ein reiner Dateizählwert reicht nicht aus.

Die Langzeitaufbewahrung von Sitzungsdaten sollte außerdem nach ihrem Zweck erfolgen. Für eine laufende Aufgabe benötigen Sie möglicherweise den vollständigen Ereignisstrom. Für eine abgeschlossene, revisionsrelevante Aufgabe kann zusätzlich ein exportierter Prüfbericht sinnvoll sein. Dieser Bericht ersetzt jedoch nicht automatisch den wiederaufnehmbaren Zustand.

SECTION 03Arbeitsbereichskonsistenz

Sitzungslogs und Arbeitsbereiche müssen nicht immer als eine einzige Datei verschmolzen werden, sie müssen aber gemeinsam migriert oder eindeutig zueinander referenziert werden. Eine Sitzung, die auf /Users/…/projekt-a zeigt, ist nach dem Umzug nicht automatisch korrekt, wenn das Zielsystem stattdessen /Volumes/Work/projekt-b geöffnet hat. Noch kritischer wird es, wenn beide Repositories ähnlich heißen.

Vor jeder Cloud-Mac-Migration erstellen Sie deshalb pro relevanter Sitzung einen kurzen Arbeitsbereichsnachweis:

• absoluter Pfad oder eindeutig benannter Mountpunkt;
• Repository-URL oder interne Herkunft;
• aktiver Branch;
• aktueller Commit;
• Zahl und Art nicht committeter Änderungen;
• lokale Dateien, die nicht aus Git rekonstruiert werden;
• externe Abhängigkeiten wie Datenbanken, lokale Services oder verschlüsselte Dateien;
• Projektanweisungen, Skills und Tool-Konfigurationen.

Die Datei git status --short ist dabei nützlich, aber nur als Nachweis des Git-Zustands zum Prüfzeitpunkt. Sie ersetzt keine Sicherung lokaler, nicht versionierter Assets. Umgekehrt sollten Sie den gesamten .git-Ordner nicht als Begründung verwenden, auf eine Session-Sicherung zu verzichten.

Wiederherstellungsreihenfolge

1. Zielverzeichnis anlegen und Berechtigungen prüfen.
2. Repository oder Arbeitsbereich in den dokumentierten Pfad bringen.
3. Commit, Branch und lokale Änderungen mit dem Quellprotokoll vergleichen.
4. Projektanweisungen und externe Abhängigkeiten kontrolliert einrichten.
5. Sitzungsdaten erst danach einspielen.
6. Den Agenten zunächst ohne Schreibrecht starten.
7. Eine lesende oder anderweitig reversible Aufgabe ausführen.
8. Schreibberechtigungen erst nach erfolgreicher Pfadprüfung freigeben.

Dieser Ablauf verhindert, dass ein Agent während eines Fehlers in ein falsches Repository schreibt. Die offizielle Web-UI-Dokumentation weist ebenfalls darauf hin, dass zunächst ein Workspace ausgewählt werden muss, bevor die Sitzung sinnvoll verwendet werden kann. (github.com)

SECTION 04Konfiguration, Plugins und Runtime-Kompatibilität

Einstellungen sind weder automatisch Sitzungsdaten noch bloß harmlose Komfortoptionen. Trennen Sie mindestens zwischen Benutzerkonfiguration, Projektkonfiguration und Laufzeitkonfiguration. Dazu gehören settings, Provider-IDs, Modellrouten, Plugin-Konfigurationen, Skills, Projektanweisungen und Startparameter.

Die Plugin-Architektur von DeepSeek Harness macht diese Prüfung wichtiger: Laut offizieller Projektbeschreibung ist „alles ein Plugin“. Dadurch kann ein Upgrade nicht nur den Kernprozess, sondern auch Session-, Speicher-, Modell-, Tool- oder UI-Komponenten verändern. (github.com)

Für jedes Plugin dokumentieren Sie:

• Name und Quelle;
• Version, Tag oder Commit;
• Konfigurationsdateien;
• erwartete Runtime;
• erforderliche Berechtigungen;
• abhängige lokale Dienste;
• Verhalten bei fehlender oder geänderter Konfiguration.

Ein alter Plugin-Ordner ist kein Beweis für Kompatibilität. In einer Vorabversion sollten Sie ein neues Zielsystem zunächst mit einer minimalen Konfiguration starten. Danach laden Sie Plugins einzeln oder in dokumentierten Gruppen. So erkennen Sie, ob eine fehlerhafte Sitzung, ein Provider, ein Skill oder ein Tool den Start verhindert.

Die offizielle Modellkonfigurationsanleitung sollte dabei die Referenz für Provider-IDs und Modellrouten bleiben. Für eigene OpenAI-kompatible Endpunkte müssen Sie zusätzlich Base-URL, Authentifizierung, Modellname und Berechtigungen getrennt prüfen. Eine Konfiguration, die syntaktisch akzeptiert wird, kann trotzdem auf ein falsches Modell oder einen nicht erreichbaren Endpunkt zeigen.

SECTION 05Geheimnisse und DSGVO-Prüfung

API Keys gehören nicht in ein gewöhnliches Backup-Archiv. Die offizielle Entwicklungsdokumentation zeigt, dass DeepSeek Harness Zugangsdaten aus der Umgebung oder einer von Git ignorierten .env-Datei lesen kann, warnt aber zugleich davor, echte Credentials zu committen. (github.com)

Unterscheiden Sie deshalb zwischen einem Verweis und einem Geheimnis:

• zulässig im normalen Backup: Provider-Name, benötigte Variable, Key-ID ohne geheimen Wert, Berechtigungsumfang;
• nicht zulässig im normalen Backup: vollständiger API Key, Token, Cookie, exportierte Schlüsselbunddatei oder unverschlüsselte .env;
• separat zu behandeln: verschlüsselte Übergabe, temporäre Freigabe, Ablaufzeitpunkt und Rotation.

Vor der Übergabe durchsuchen Sie nicht nur den aktuellen Arbeitsbereich, sondern auch:

1. Backup-Archive;
2. temporäre Kompressionsdateien;
3. Shell-Historien;
4. Debug- und Sitzungslogs;
5. Skripte und Testdateien;
6. CI/CD-Variablen;
7. Editor- oder Terminal-Snapshots.

Nach der Wiederherstellung ersetzen Sie die Zugangsdaten möglichst durch neu ausgestellte Schlüssel. Prüfen Sie anschließend die alten Schlüssel auf Nutzung und widerrufen Sie sie, sobald die neue Umgebung nachweislich funktioniert. Bei personenbezogenen oder vertraulichen Projektdaten müssen Sie außerdem Aufbewahrung, Zugriffsrechte und Speicherort nach Ihrer DSGVO-Vorgabe dokumentieren. Ein Cloud Mac ist keine automatische Datenschutzfreigabe; entscheidend sind Zugriffskontrolle, Verschlüsselung, Löschprozess und nachvollziehbare Verantwortlichkeit.

SECTION 06Durchführbare Abnahme in sieben Schritten

Die folgende Reihenfolge ist für Upgrade, Neuinstallation, Cloud-Mac-Migration und Übergabe verwendbar:

1. Quellstand einfrieren: Notieren Sie Harness-Version, Installationsquelle, Betriebsmodus, Runtime-Versionen, Provider und aktuelle Arbeitsbereiche. Beenden Sie anschließend laufende Sitzungen oder stellen Sie eine konsistente Snapshot-Grenze her.
2. Vier Schichten inventarisieren: Erstellen Sie getrennte Listen für rekonstruierbare Umgebung, Sitzungszustand, Arbeitsbereich und Geheimnisverweise. Markieren Sie jeden Eintrag als „aufbewahren“, „neu erzeugen“ oder „separat übertragen“.
3. Sitzungen prüfen: Erfassen Sie die erwartete Anzahl, öffnen Sie eine alte und eine aktuelle Session und prüfen Sie bei einer Werkzeugaufgabe auch die Ereigniskette, nicht nur den sichtbaren Text.
4. Arbeitsbereiche protokollieren: Sichern Sie Repository, Branch, Commit und lokale Änderungen. Kennzeichnen Sie externe Abhängigkeiten, die nicht in Git enthalten sind.
5. Backup bereinigen: Entfernen Sie API Keys und andere direkt nutzbare Secrets. Lassen Sie anschließend einen Secret-Scanner über Archiv, Arbeitsverzeichnis und temporäre Kopien laufen.
6. Zielumgebung minimal aufbauen: Installieren Sie die dokumentierte Runtime und DeepSeek-Harness-Version. Spielen Sie Konfiguration, Plugins und Sitzungen nicht ungeprüft als Gesamtpaket ein.
7. Ende-zu-Ende signieren: Öffnen Sie eine wiederhergestellte Session, prüfen Sie das richtige Modell, führen Sie ein Werkzeug aus, kontrollieren Sie den Arbeitsbereich und testen Sie die aktive Genehmigungspolitik. Erst dann gilt die Migration als angenommen.

Für den End-to-End-Test wählen Sie eine reversible Aufgabe, etwa das Lesen einer Datei, das Erstellen einer temporären Ausgabedatei oder eine reine Analyse. Vermeiden Sie als ersten Test irreversible Änderungen an Produktivdaten. Wenn die Aufgabe nur nach manueller Reparatur funktioniert, lautet das Ergebnis nicht „bestanden“, sondern „mit Abweichung zurückgewiesen“.

SECTION 07Abnahmeprotokoll und Entscheidung

Ihr Übergabedokument sollte mindestens Quelle, Ziel, Prüfzeitpunkt, Prüfer, verwendete Versionen, Sitzungsanzahl, Arbeitsbereichsreferenzen, Geheimnisstatus und Testergebnis enthalten. Für jede Abweichung benötigen Sie eine Entscheidung: behoben, bewusst akzeptiert oder zurückgewiesen.

Wenn Ihr aktuelles Verfahren nur aus einem Git-Export besteht, fehlen typischerweise Sitzungszustand, lokale Plugin-Konfiguration und Genehmigungspolitik. Wenn Sie dagegen einen kompletten Benutzerordner kopieren, erhöhen Sie das Risiko, veraltete Runtime-Dateien, Cache-Ballast oder API Keys mitzunehmen. Eine temporäre Cloud-Mac-Umgebung von MACNOX kann hier als getrenntes Prüfziel sinnvoll sein, sofern Sie vorab den gewünschten Arbeitsbereich, die Zugriffsrechte und die Löschfrist festlegen.

Die faire Einschränkung bleibt: Für dauerhaft schwere Last, besondere physische Schnittstellen oder eine langfristig unveränderte Produktionsumgebung kann der Kauf eigener Hardware oder eine andere Infrastruktur besser passen. Für Upgrade-Tests, Übergaben und eine einzelne kontrollierte Wiederherstellung ist ein gemieteter Mac jedoch oft die sauberere Lösung als ein riskanter Test direkt auf dem einzigen Arbeitsgerät. Hinweise zur Auswahl einer passenden Cloud-Mac-Übergabe sollten Sie mit Ihrem Abnahmeprotokoll verbinden, nicht an dessen Stelle setzen.

Entscheidend ist am Ende nicht, ob DSH_HOME, ein Repository oder ein Archiv vorhanden ist. Entscheidend ist, ob Sie nachweisen können, dass eine Sitzung im richtigen Arbeitsbereich geöffnet wird, das richtige Modell angesprochen werden darf, Werkzeuge unter der erwarteten Genehmigung laufen und kein Geheimnis unkontrolliert im Backup verbleibt. Wenn Sie diese vier Bedingungen vor dem Upgrade schriftlich abnehmen, wird aus einer Dateikopie ein belastbarer Wiederherstellungsprozess.

SECTION 08Weiterlesen

• Harness-Compaction: Tokenkosten senken und Sitzungszustände zuverlässig prüfen
• Upgrade und API-Migration: Modelle, Kosten und Abnahme systematisch vergleichen