OpenClaw-SQLite-Backup abnehmen? Mac-Wiederherstellung 2026

Symptom: Der Backup-Job meldet Erfolg, aber niemand hat nachgewiesen, dass OpenClaw auf einem anderen Mac wieder startet.
Schnellste Lösung: Behandeln Sie den Jobstatus nicht als Wiederherstellungsbeleg. Prüfen Sie zuerst den Datenumfang und stellen Sie das Backup anschließend in einem isolierten, neuen Ziel wieder her.

Dieser Leitfaden richtet sich an IT-Verantwortliche für OpenClaw Gateway und Agent-Daten, die den tatsächlich wiederherstellbaren Zustand feststellen müssen.
Plattformverantwortliche finden hier einen Ablauf zur Prüfung der Sicherung und des Wiederanlaufs auf einem Ziel-Mac.
Sicherheitsverantwortliche können damit sensible Inhalte und Zugriffsrechte in der Sicherung kontrollieren.

Zuletzt aktualisiert am 14.10.2026; Versions- und Verfahrensangaben mit dem offiziellen OpenClaw-Veröffentlichungsindex sowie den unten verlinkten Backup-, CLI- und Datenbankdokumenten abgeglichen.

SECTION 01Vor einer Änderung den wiederherstellbaren Zustand festlegen

Legen Sie das Wiederherstellungsziel fest, bevor Sie einen Backup-Lauf als ausreichend bewerten. „Die SQLite-Datei ist vorhanden“ ist kein belastbares Ziel. Entscheidend ist, ob Sie nach dem Ausfall einen betriebsfähigen OpenClaw-Zustand erhalten: Gateway-Konfiguration, gemeinsame Zustandsdaten, Daten der konfigurierten Agenten, Sitzungen und alle zusätzlich benötigten Verzeichnisse.

Klären Sie außerdem, welcher Fehlerfall geprobt wird. Bei einem defekten Mac brauchen Sie einen Wiederaufbau auf einem Ersatzsystem. Bei einem fehlgeschlagenen Update kann ein kompatibler Zustand derselben Umgebung genügen. Nach versehentlichem Löschen kann dagegen die Wiederherstellung eines bestimmten Datenbereichs wichtiger sein als eine vollständige Host-Migration. Dieselbe Sicherung kann für einen dieser Fälle brauchbar und für einen anderen unvollständig sein.

Prüfen Sie die tatsächlichen Pfade Ihrer Instanz anhand der offiziellen Beschreibung des OpenClaw-Datenbanklayouts. Übernehmen Sie keine angenommene Standardstruktur ungeprüft: Benutzerdefinierte Agent-Verzeichnisse und Workspaces können außerhalb des erwarteten Zustandsverzeichnisses liegen. Halten Sie Quellpfade, Zielpfade und bewusst ausgeschlossene Daten schriftlich fest. So wird beim Mac-Umzug sichtbar, ob Inhalte fehlen oder lediglich an einen anderen Ort gehören.

Entscheidung nach Wiederherstellungsziel:

• Wenn Sie einen vollständigen Host-Ausfall abdecken müssen, wählen Sie einen Sicherungsumfang, der Zustand, Konfiguration, erforderliche Agent-Daten und die tatsächlich genutzten Workspaces einschließt.
• Wenn Sie nur eine klar abgegrenzte Datenbankänderung prüfen, verwenden Sie einen dafür dokumentierten Wiederherstellungsweg und weisen Sie nach, dass die übrigen benötigten Dateien verfügbar bleiben.
• Wenn Pfade oder Fehlerfall nicht eindeutig sind, geben Sie die Sicherung nicht frei. Ergänzen Sie zuerst die Bestandsaufnahme; andernfalls besteht das Risiko, dass ein erfolgreicher Backup-Lauf die benötigten Daten nicht abdeckt.

Die offizielle Dokumentation unterscheidet Backup- und Wiederherstellungswege. Legen Sie deshalb nicht nach Bequemlichkeit fest, dass ein einzelnes Archiv, eine SQLite-Sicherung oder eine versionierte Kopie alle Anforderungen erfüllt. Vermerken Sie, welche Methode Sie nutzen und welchen Fehlerfall sie abdecken soll. Die OpenClaw-Backup-Dokumentation ist hierfür die Referenz für die jeweils dokumentierten Verfahren.

SECTION 02Beim Erstellen den SQLite- und Agent-Datenumfang erfassen

Verwenden Sie für die Datenbank einen von OpenClaw dokumentierten Backup-Ablauf. Kopieren Sie nicht einfach die Hauptdatei einer laufenden SQLite-Datenbank und erklären Sie diese Kopie zur gültigen Sicherung. Wenn SQLite im WAL-Modus arbeitet, können Änderungen zusätzlich in einer Write-Ahead-Log-Datei stehen. Eine isolierte Kopie der Hauptdatei ist daher kein ausreichender Nachweis, dass der gewünschte konsistente Stand enthalten ist. Folgen Sie dem für OpenClaw beschriebenen Backup-Verfahren, statt die Datenbank während laufender Schreibzugriffe manuell zu kopieren.

Die OpenClaw-CLI-Dokumentation für Backups beschreibt die unterstützten Befehle und ihre Verwendung. Übernehmen Sie Syntax und Optionen direkt aus der Dokumentation für die installierte Version. Führen Sie keine nicht verifizierten Befehlsvarianten aus einem älteren Runbook aus, und notieren Sie, ob der Lauf ein vollständiges Archiv, eine Datenbank-Sicherung oder einen anderen dokumentierten Pfad erzeugt hat.

Für jeden Lauf sollte Ihr Inventar mindestens diese Fragen beantworten:

• Ist die gemeinsame OpenClaw-Zustandsablage im gewählten Verfahren enthalten?
• Sind Datenbanken und Sitzungsdaten aller tatsächlich konfigurierten Agenten erfasst?
• Liegen Agent-Daten oder Workspaces in benutzerdefinierten Pfaden, die separat gesichert werden müssen?
• Sind Konfiguration und benötigte Zugangsdaten Teil des Sicherungsumfangs oder werden sie kontrolliert separat verwaltet?
• Ist das Zielmedium erreichbar, und können die für die Wiederherstellung nötigen Dateien daraus gelesen werden?

Führen Sie die Bestandsaufnahme gegen die aktuelle Konfiguration aus, nicht gegen eine frühere Installationsnotiz. Bei einem Mac-Wechsel vergleichen Sie die Quellpfade mit den Zielpfaden und markieren Sie Umleitungen ausdrücklich. Das verhindert, dass eine Datei zwar im Archiv vorhanden ist, der wiederhergestellte Dienst aber nach dem Start an einer anderen Stelle danach sucht.

Achtung: Behandeln Sie ein Backup mit Agent-Sitzungen, Authentifizierungskonfiguration oder API-Zugangsdaten wie vertrauliche Produktionsdaten. Übernehmen Sie die Zugriffsbeschränkungen und Verschlüsselungsanforderungen Ihrer Online-Zustandsdaten auch für Kopien, temporäre Ablagen und Testziele.

SECTION 03Nach dem Lauf das Backup-Artefakt nachvollziehbar prüfen

Ein grüner Jobstatus belegt zunächst nur, dass der Sicherungsprozess seinen eigenen Erfolg gemeldet hat. Prüfen Sie danach das Artefakt mit dem für das gewählte Verfahren dokumentierten Verifikationsschritt. Die Dokumentation zu OpenClaw-Backup und Wiederherstellung beschreibt, welche Prüfungen für den jeweiligen Weg vorgesehen sind. Halten Sie das Ergebnis fest, statt es nur im CI-Log zu belassen.

Trennen Sie in Ihrem Prüfprotokoll drei Aussagen:

• Datei vorhanden: Das erwartete Archiv oder Sicherungsartefakt liegt am vorgesehenen Ziel.
• Validierung bestanden: Die vorgesehene Integritätsprüfung meldet keinen Fehler.
• Wiederherstellung bestanden: OpenClaw wurde aus genau diesem Artefakt in einem Testziel wiederhergestellt und die erforderlichen Zustände wurden geprüft.

Keine dieser Aussagen ersetzt die jeweils nächste. Ein vorhandenes Artefakt kann unvollständig sein; eine bestandene Validierung beweist nicht, dass die Konfiguration und alle Agent-Verzeichnisse enthalten sind. Erst die Wiederherstellung zeigt, ob das Paket im vorgesehenen Betriebsfall nutzbar ist.

Speichern Sie mindestens Backup-Kennung, Zeitpunkt, Methode, erfasste Pfade, Ablageort und Validierungsergebnis. Ergänzen Sie, wer den Lauf ausgelöst hat und ob sensible Inhalte enthalten sind. Wenn ein Lauf fehlschlägt, sichern Sie die Fehlermeldung im Nachweis und wiederholen Sie den Test erst, nachdem Ursache und Umfang geklärt sind. Ein stiller Überschreibvorgang, der das einzige vorherige Artefakt ersetzt, ist kein akzeptabler Umgang mit einem noch ungeklärten Fehler.

FAQ zur OpenClaw-SQLite-Backup-Abnahme

Wie sichern Sie eine laufende SQLite-Datenbank samt WAL?

Kopieren Sie nicht bloß die laufende Hauptdatei. Nutzen Sie das dokumentierte OpenClaw-Backup-Verfahren für einen konsistenten Datenbankstand und prüfen Sie anschließend das erzeugte Artefakt mit dem vorgesehenen Verifikationsschritt. Halten Sie fest, welche Datenbanken und Agent-Pfade enthalten sind. Eine erfolgreiche Dateikopie allein weist weder die Vollständigkeit von WAL-bezogenen Änderungen noch eine funktionierende Wiederherstellung nach.

Wie prüfen Sie Agent-Sitzungen und Konfiguration nach der Wiederherstellung?

Kontrollieren Sie, ob die erwarteten Agent-Konfigurationen und Sitzungsdaten am wiederhergestellten Speicherort vorhanden und für den Dienst erreichbar sind. Prüfen Sie anschließend den Gateway-Status, führen Sie die dokumentierte Diagnose aus und testen Sie ausgewählte Integrationen. Trennen Sie Datenbankzugriff, Agent-Sichtbarkeit und externe Authentifizierung im Protokoll: Ein bestandener Teiltest ist kein Beleg für die anderen Bereiche.

Können API-Zugangsdaten und Chatverläufe im Backup enthalten sein?

Das richtet sich nach der gewählten Backup-Methode und den tatsächlich erfassten Pfaden. Sitzungsdaten und Authentifizierungsmaterial können in den gesicherten OpenClaw-Verzeichnissen liegen. Behandeln Sie ein umfassendes Archiv deshalb vorsorglich als vertraulich, gleichen Sie seinen Inhalt mit der dokumentierten Methode ab und prüfen Sie Zugriffsrechte, Verschlüsselung und Aufbewahrung, bevor Sie es an einen weiteren Ort übertragen.

Welche Agent-Verzeichnisse sind bei einem Mac-Umzug gesondert zu prüfen?

Prüfen Sie alle in Ihrer Konfiguration verwendeten Agent-Datenpfade und Workspaces, insbesondere benutzerdefinierte Verzeichnisse außerhalb des erwarteten Zustandsorts. Vergleichen Sie die Pfadzuordnung des Quell-Macs mit der des Ziels, bevor Sie den Dienst starten. Dokumentieren Sie fehlende, umgeleitete und absichtlich ausgeschlossene Inhalte, damit ein erfolgreicher Gateway-Start nicht irrtümlich als vollständige Datenmigration gilt.

SECTION 04Vor der Aktivierung eine isolierte Wiederherstellung durchführen

Stellen Sie das Backup zunächst in einem neuen, leeren Testziel wieder her. Verwenden Sie nicht das aktive Zustandsverzeichnis als Versuchsziel und überschreiben Sie keine laufende Instanz. Diese Trennung macht sichtbar, welche Dateien tatsächlich aus dem Backup stammen, und verhindert, dass vorhandene Dateien einen fehlenden Sicherungsbestand verdecken.

Prüfen Sie vor dem Wiederherstellen, ob das Ziel die erforderlichen Pfade aufnehmen kann. Eine Wiederherstellung kann zusätzlichen Speicherplatz benötigen, etwa wenn Archiv und entpackter Zustand gleichzeitig vorhanden sind. Leiten Sie daraus jedoch keine pauschale Kapazitätszahl ab: Der Bedarf hängt vom konkreten Artefakt und den eingeschlossenen Daten ab. Messen Sie den Platzbedarf für Ihren eigenen Sicherungsumfang und lassen Sie genügend Reserve, ohne aus einem nicht belegten Richtwert eine verbindliche Vorgabe zu machen.

Arbeiten Sie den Wiederherstellungsvorgang anhand der offiziellen CLI-Backup-Anleitung und der Backup-Dokumentation ab. Verwenden Sie die dort für Ihr Verfahren beschriebenen Optionen, statt einen Zielpfad zu erraten. Notieren Sie jeden Zielpfad und gleichen Sie ihn mit den benutzerdefinierten Agent-Verzeichnissen ab. Wenn die Zielinstanz eine andere OpenClaw-Version nutzt, prüfen Sie vor dem Start die dokumentierten Kompatibilitäts- und Strukturänderungshinweise. Die Dokumentation zu Änderungen am Datenbankschema ist dafür maßgeblich; schließen Sie nicht aus einer erfolgreichen Extraktion auf Versionskompatibilität.

Arbeiten Sie die Wiederherstellung in dieser Reihenfolge ab:

1. Bestätigen Sie, dass das Ziel neu und leer ist und nicht auf aktive Produktionsdaten zeigt.
2. Prüfen Sie, ob die Backup-Validierung für genau dieses Artefakt bestanden wurde.
3. Gleichen Sie die Agent- und Workspace-Pfade des Quellsystems mit den Zielpfaden ab.
4. Prüfen Sie bei unterschiedlichen OpenClaw-Versionen die dokumentierten Hinweise zu Kompatibilität und Schemaänderungen.
5. Stellen Sie wieder her und protokollieren Sie verwendete Methode, Zielpfade und Fehlermeldungen.

Abbruchkriterien vor dem Start:

• Ein erforderlicher Agent-Pfad fehlt oder ist im Ziel nicht eindeutig zugeordnet.
• Die Artefaktprüfung meldet einen Fehler oder wurde für die verwendete Methode nicht ausgeführt.
• Die Zielversion ist nicht gegen dokumentierte Schema- oder Kompatibilitätshinweise geprüft.
• Der Test würde aktive Produktionsdaten überschreiben oder könnte laufende Schreibzugriffe beeinflussen.

Beheben Sie einen dieser Punkte, bevor Sie fortfahren. Wenn Sie die Ursache nicht sicher einordnen können, halten Sie die Wiederherstellung in der isolierten Umgebung an und bewahren Sie das unveränderte Originalartefakt für eine kontrollierte Prüfung auf.

SECTION 05Beim Umschalten Dienst und externe Abhängigkeiten getrennt abnehmen

Führen Sie den Wechsel nur nach dem dokumentierten Wiederherstellungsablauf aus. Stoppen Sie vorher die betroffenen Schreibzugriffe, damit der wiederhergestellte Zustand nicht parallel mit neuen Daten verändert wird. Führen Sie erforderliche Prüfungen und Diagnosen vor dem Start aus. Die konkreten Befehle und Voraussetzungen richten sich nach dem eingesetzten Verfahren; verwenden Sie dafür die offizielle CLI- und Backup-Dokumentation, nicht eine ungeprüfte Befehlsfolge.

Nach dem Start prüfen Sie die Betriebsfähigkeit schichtweise. Zuerst muss das Gateway den erwarteten Zustand melden. Danach kontrollieren Sie, ob die benötigten Agenten und Sitzungen sichtbar sind und ob die Anwendung auf ihre Konfiguration zugreifen kann. Testen Sie anschließend die für den Betrieb entscheidenden Integrationen, etwa Nachrichtenkanäle oder externe Authentifizierung. Ein wiederhergestellter Datenbankstand bedeutet nicht automatisch, dass Plugins, Zugangsdaten, externe Dienste oder Kanäle ebenfalls verfügbar sind.

Vergleichen Sie den Testzustand mit dem zuvor festgelegten Wiederherstellungsziel. Achten Sie besonders auf den zeitlichen Datenstand: Ein Backup stellt grundsätzlich den gesicherten Stand wieder her, nicht automatisch alle Änderungen, die nach seinem Erstellungszeitpunkt entstanden sind. Besprechen Sie vor einer produktiven Umschaltung, ob aus dem älteren Zustand ausstehende Freigaben, zuletzt bearbeitete Sitzungen oder Nachrichten-Deduplizierungsinformationen fehlen können. Verlassen Sie sich dabei auf die dokumentierten Eigenschaften der verwendeten Version und Ihres Datenumfangs, nicht auf Annahmen aus einem erfolgreichen Start.

Betriebshinweis: Datenbankprüfung und Integrationsprüfung sind unterschiedliche Abnahmeschritte. Wenn Gateway und Agent-Daten korrekt geladen werden, aber ein externer Kanal nicht authentifiziert, dokumentieren Sie die Datenwiederherstellung als bestanden und den Dienst als noch nicht vollständig einsatzbereit.

SECTION 06Nach dem Test das Protokoll und die Freigabeentscheidung festhalten

Erstellen Sie für jede Übung einen Nachweis, den eine andere verantwortliche Person nachvollziehen kann. Ein geeigneter Eintrag umfasst Backup-Kennung und -Zeitpunkt, Fehlerfall, verwendete Methode, erfasste Datenbereiche, Ziel-Mac beziehungsweise Testziel, Validierungsergebnis, geprüfte Agenten und Sitzungen, Integrationsprüfungen, offene Fehler sowie Namen oder Rollen der Verantwortlichen. Vermerken Sie außerdem, ob Zugangsdaten im Artefakt enthalten waren und welche Schutzmaßnahmen für Ablage und Löschung des Testbestands galten.

Leiten Sie daraus eine klare Abnahme ab:

• Bestanden: Das vorgesehene Szenario wurde isoliert wiederhergestellt, die relevanten Agent-Daten und Konfigurationen sind verfügbar, und Gateway sowie erforderliche Integrationen erfüllen die festgelegten Prüfungen.
• Mit Frist nacharbeiten: Die Wiederherstellung funktioniert, aber ein begrenzter, dokumentierter Teilbereich – etwa eine nicht kritische Integration – ist noch ungeklärt. Benennen Sie Verantwortliche und Frist, bevor Sie die Sicherung als vollständig betriebsbereit einstufen.
• Nicht freigegeben: Datenumfang, Pfadzuordnung, Integrität oder Startfähigkeit ist ungeklärt. Erweitern Sie die Agent-Arbeitslast nicht auf Grundlage dieses Backups, bis die Lücke geschlossen und erneut geprüft wurde.

Abnahme-Checkliste für das Protokoll:

• [ ] Fehlerfall und erwarteter Wiederherstellungsumfang sind festgelegt.
• [ ] Gemeinsame Zustandsdaten, Datenbanken, Sitzungen und konfigurierte Agent-Verzeichnisse sind berücksichtigt.
• [ ] Benutzerdefinierte Agent-Pfade und Workspaces sind mit Quelle und Ziel abgeglichen.
• [ ] Das Artefakt wurde mit dem für die gewählte Methode vorgesehenen Verfahren validiert.
• [ ] Die Wiederherstellung erfolgte in einem neuen, isolierten Ziel, ohne aktive Produktionsdaten zu überschreiben.
• [ ] Gateway, erforderliche Agent-Daten und Konfigurationen wurden nach dem Start geprüft.
• [ ] Notwendige Integrationen und externe Authentifizierung wurden separat getestet.
• [ ] Sensible Inhalte, Zugriffsrechte, Ablage und Löschung der Testdaten sind dokumentiert.
• [ ] Offene Fehler haben eine verantwortliche Person und eine Frist; andernfalls ist die Freigabe ausgesetzt.

Entscheidung anhand der Prüfergebnisse: Wenn alle für das Wiederherstellungsziel erforderlichen Punkte belegt sind, geben Sie das Verfahren für genau dieses Szenario frei. Wenn ein begrenzter, nicht kritischer Test offen ist, erteilen Sie nur eine befristete Freigabe mit benannter Verantwortung. Wenn Datenumfang, Integrität, Pfade oder Startfähigkeit ungeklärt bleiben, geben Sie das Backup nicht als wiederherstellbar frei und vergrößern Sie die Agent-Arbeitslast erst nach einer erfolgreichen Wiederholungsübung.

Der offizielle Veröffentlichungsindex führt mit Stand 14.10.2026 v2026.10.3 als aktuelle Veröffentlichung. Das ist ein Versionsstand aus dem Index und kein Nachweis, dass Ihre Wiederherstellung auf dieser Version getestet wurde. Prüfen Sie vor dem nächsten Lauf den Index und die Hinweise zu relevanten Schemaänderungen erneut, insbesondere wenn eine neue Veröffentlichung oder ein geändertes Backup-Verfahren seit Ihrer letzten Übung vorliegt.

Wenn Sie eine verlässliche Testumgebung benötigen, führen Sie zuerst die beschriebene isolierte Wiederherstellung auf einem Ziel-Mac durch. Für dauerhaft hohe, planbare Last oder Anforderungen an physische Schnittstellen kann ein eigener Mac die passendere Wahl sein; ein gemieteter Host ersetzt weder Ihre Datenverantwortung noch die Prüfung externer Abhängigkeiten. Wenn Sie für einen zeitlich begrenzten Wiederanlauf oder eine zusätzliche Testumgebung keinen weiteren Mac beschaffen möchten, können Sie die Remote-Mac-Möglichkeiten von MACNOX und die veröffentlichten Preisangaben prüfen. Nehmen Sie die Umgebung erst dann in Ihre Notfallplanung auf, wenn Sie den Wiederherstellungsweg dort selbst abgenommen haben.

SECTION 07FAQ