#Beste Backup und Restore plan

1 messages · Page 1 of 1 (latest)

past herald
#

Wie sieht aktuell der empfohlene und möglichst sichere Migrationsweg für folgendes Szenario aus?

Ich plane einen Umstieg von Ubuntu 24.04 LTS Desktop auf das künftig erscheinende Ubuntu 26.04 LTS Server.
Auf dem bestehenden System läuft bereits OpenClaw 4.15 in der Non-Docker-Variante (Node-basiert).
Zusätzlich soll mein bestehender Agent bzw. meine bestehende Arbeitsumgebung auf das neue System übernommen werden.

Dabei stellen sich mir vor allem diese Fragen:

Wie wird ein Backup einer bestehenden OpenClaw-Installation korrekt in eine neue Installation eingespielt, wenn die Instanz nicht per Docker, sondern direkt über Node.js betrieben wird?
Ist der empfohlene Weg, auf dem neuen Server zunächst eine saubere Neuinstallation inklusive Initial-Setup durchzuführen und erst danach das Backup bzw. die relevanten Daten manuell zurückzuspielen?
Oder ist es sinnvoller, nur die Konfigurationsdateien sowie die relevanten Workspace-/Markdown-/Anwendungsdaten aus der alten Installation zu sichern und diese gezielt in eine frische Neuinstallation zu übernehmen?
Welche Variante ist aus heutiger Sicht robuster, upgrade-sicherer und weniger fehleranfällig, insbesondere im Hinblick auf Versionswechsel, Pfade, Abhängigkeiten und Agent-/Workspace-Daten?

Falls es Best Practices gibt, wäre für mich besonders wichtig zu wissen, welche Dateien/Ordner zwingend gesichert werden sollten und welche Daten besser nicht 1:1 übernommen werden, um Altlasten oder Inkompatibilitäten zu vermeiden.

dapper drumBOT
drowsy marshBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

dapper drumBOT
hollow plazaBOT
#

Ich prüfe kurz die Doku und die echten Pfade, damit ich dir nichts Falsches erzähle.

#

Kurzfassung: frische Installation auf dem neuen Server, danach kompletter Restore von State-Dir + Workspace ist aktuell der robusteste Weg.

Wichtig vorab: bitte einmal das exakte

openclaw --version

posten. „4.15“ klingt nach 2026.4.15, aber wenn es doch älter ist, wird das relevant.

Meine klare Empfehlung

Für Non-Docker / Node-basiert würde ich nicht nur selektiv openclaw.json + ein paar Markdown-Dateien übernehmen, wenn du wirklich den bestehenden Agenten samt Verlauf/Auth/Arbeitsumgebung erhalten willst.

Am sichersten ist:

  1. Altes System anhalten
    openclaw gateway stop
#

  1. Backup ziehen
    Wenn verfügbar:

    openclaw backup create --verify --output ~/Backups

    Das sichert laut aktueller Doku:

    • State-Dir, meist ~/.openclaw
    • aktive Config
    • externe credentials/, falls außerhalb des State-Dirs
    • Workspace(s) aus der Config

    Zusätzlich ist für Migration oft ein klassisches Verzeichnis-Backup gut:

    • kompletter State-Dir
    • kompletter Workspace

  2. Neuen Server sauber installieren

    • Node neu installieren
#
  • OpenClaw neu installieren
    • idealerweise zuerst auf derselben OpenClaw-Version wie auf dem Alt-System

  1. Dann restore / zurückkopieren

    • komplettes migriertes State-Dir zurückspielen
    • kompletten Workspace zurückspielen
    • nicht die alte Node-/npm-Installation kopieren

  2. Danach reparieren / migrieren lassen

    openclaw doctor
openclaw gateway restart
openclaw status
#

Was du unbedingt sichern solltest

Für einen echten 1:1-Umzug:

  • ~/.openclaw/ bzw. dein echtes $OPENCLAW_STATE_DIR
  • den aktiven Workspace, standardmäßig meist ~/.openclaw/workspace
  • falls genutzt: ~/.openclaw/.env
  • falls du mit custom profile oder custom state dir arbeitest, genau diesen Pfad, nicht blind nur ~/.openclaw

Besonders wichtig darin:

  • ~/.openclaw/openclaw.json
  • ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
  • ~/.openclaw/credentials/
  • ~/.openclaw/agents/<agentId>/sessions/
  • Workspace-Dateien wie AGENTS.md, SOUL.md, USER.md, MEMORY.md, skills/, etc.
#

Was ich nicht 1:1 übernehmen würde

  • globale Node-/npm/pnpm-Installation
  • alte Service-/Daemon-Installation blind kopieren
  • nur openclaw.json ohne den Rest des State-Dirs
  • mehrere alte/vergessene Workspace-Pfade parallel mitschleppen, z. B. altes ~/openclaw, wenn heute ein anderer Workspace aktiv ist

Restore aus openclaw backup

Aktuell gibt es laut CLI/Doku backup create und backup verify, aber keinen dokumentierten backup restore One-Shot. Heißt praktisch:

  • Backup-Archiv ist gut zum sicheren Wegsichern
  • für Migration ist der dokumentierte Weg weiter: neue Installation, dann State-Dir + Workspace zurückkopieren, dann openclaw doctor

Für minimale Risiken

#

Ich würde den Umzug in 2 getrennten Schritten machen:

  1. Migration auf neue Maschine mit gleicher OpenClaw-Version
  2. Erst wenn alles läuft, OpenClaw dort upgraden

Also: OS-Wechsel und OpenClaw-Upgrade nicht in einem einzigen großen Sprung vermischen.

Docs:

Wenn du magst, schreibe ich dir als Nächstes eine konkrete Ubuntu-zu-Ubuntu Migrations-Checkliste mit tar/rsync und Verifikationsschritten.

past herald
#

Vielen Dank schon mal - und ja, es ist die aktuellste 2026.4.15 Version. Feedback wäre: Wirklich schade das es keinen "backup restore One-Shot" gibt, dann ist der vorhandene "backup" part eher nice to have, insofern dieser auch ggf. gesichert ist mit passwort - stell dir vor das backup file enthält wichtige / sicherheitsrelevante informationen und ist nur ein einfaches "zip" archiv was jeder entpacken könnte und die secrets hat. Folgefragen sind: Warum dann den manuellen backup cli weg mittels create backup erst nutzen wenn ich die wichtigsten files manuell sowieso auch so rüber kopieren kann und anschließend repariert wird mit dem doctor?

hollow plazaBOT
#

Ich prüfe kurz noch den Sicherheitsaspekt vom Backup, damit ich da sauber bleibe.

#

Ja, dein Bauchgefühl ist ziemlich richtig.

Kurz gesagt

  • openclaw backup create erzeugt aktuell ein .tar.gz, also komprimiert, aber nicht verschlüsselt.
  • Die Doku sagt auch ausdrücklich: Backups verschlüsselt lagern.
  • Für deinen konkreten 1:1-Umzug ist manuelles Kopieren von State-Dir + ggf. externem Workspace absolut sinnvoll und oft sogar der pragmatischere Weg.
  • Der Backup-CLI ist eher Archivierungs-/Verifikationshilfe, nicht der magische Restore-Mechanismus.

Warum backup create trotzdem nicht ganz nutzlos ist

Der Mehrwert ist vor allem:

  • ein einzelnes Archiv statt mehrere lose Ordner
  • automatische Erkennung von:
    • State-Dir
    • aktiver Config
    • externem credentials/
    • Workspace(s) aus der Config
#
  • manifest.json im Archiv
  • openclaw backup verify prüft das Archiv
  • praktisch vor Reset / Upgrade / Uninstall / Offsite-Backup

Aber: du hast recht, für eine direkte Host-zu-Host-Migration ersetzt das aktuell kein Restore.

Mein Rat für dein Szenario

Ich würde es so machen:

Wenn du nur migrieren willst

  1. openclaw gateway stop
  2. komplettes State-Dir kopieren
  3. Workspace nur dann extra kopieren, wenn er außerhalb des State-Dirs liegt
  4. auf neuem Server frisch installieren
  5. Daten zurücklegen
  6. openclaw doctor
  7. openclaw gateway restart
#
  1. openclaw status

Wichtige Nuance:
Wenn du den Default-Workspace nutzt (~/.openclaw/workspace), dann steckt der bereits im State-Dir. Dann reicht oft schlicht ~/.openclaw/ komplett.

Nur wenn du einen custom Workspace-Pfad hast, musst du den zusätzlich separat migrieren.

Wann ich openclaw backup create nehmen würde

Ich würde es eher so sehen:

  • Manuelle Kopie = beste Wahl für gezielte 1:1-Migration
  • openclaw backup create --verify = beste Wahl für
    • zusätzlichen Sicherheits-Snapshot vor dem Umzug
    • archivierte Backups
    • spätere Wiederherstellung per Hand
    • automatisierte/offsite Backups
#

Also nicht entweder/oder, eher:

  • Migration: manuell kopieren
  • zusätzliche Absicherung: Backup-Archiv erzeugen

Zum Security-Punkt

Da bin ich bei dir. Das Archiv enthält potentiell:

  • Auth-Profile
  • Channel-Credentials
  • Sessions
  • Secrets/Provider-State

Deshalb würde ich ein Backup-Archiv nie unverschlüsselt herumliegen lassen. Wenn du openclaw backup create nutzt, dann nur mit:

  • verschlüsseltem Storage oder
  • anschließend extern verschlüsseln (z. B. age, gpg, restic, borg)

Meine klare Empfehlung

Für 2026.4.15, Non-Docker, Ubuntu alt → neu:

#
  • Frische Installation
  • komplettes State-Dir übernehmen
  • externen Workspace nur falls nötig zusätzlich
  • Doctor danach
  • Upgrade-/Versionssprünge getrennt vom Host-Umzug halten

Und ja, fairer Kritikpunkt:
Aktuell ist backup create eher Backup/Archiv + Verify, nicht vollwertiges Backup/Restore.

Docs:

Wenn du willst, schreibe ich dir als Nächstes eine konkrete Schritt-für-Schritt-Migration für genau Ubuntu 24.04 → 26.04 Server, mit dem Fall:

  • Default-Workspace
#
  • Custom-Workspace
  • und optional verschlüsseltem Backup.
past herald
#

Folge Frage- was ggf. auch wichtig ist, wenn das Memory Backend QMD ist: Laut openclaw backup create Help wird automatisch gesichert:

• ✅ Config (config.json)
• ✅ Credentials (Tokens, Keys)
• ✅ Sessions
• ✅ Workspace (optional, default: inklusive)

Aber QMD Memory ist separat unter /.openclaw/memory/main.sqlite — das ist KEIN Workspace-File, sondern Core-State. Das könnte glatt vergessen werden - dann ist ggf. die Memory "weg" genauso wie Dreaming korrekt?

hollow plazaBOT
#

Guter Punkt. Ich prüfe kurz die QMD-Pfade, damit ich dir da nichts Falsches erzähle.

#

Ja, guter Catch, aber beim Default-Pfad ist das nach aktueller Doku/Implementierung mit drin.

Der entscheidende Punkt ist:

openclaw backup create sichert nicht nur ein paar Teilordner

Es nimmt den kompletten State-Dir als Backup-Quelle, normalerweise also:

~/.openclaw

Und darin liegt bei QMD standardmäßig auch der Index:

~/.openclaw/memory/{agentId}.sqlite
#

Also z. B. für main:

~/.openclaw/memory/main.sqlite

Heißt konkret

Default-QMD-Memory geht bei backup create nicht verloren, weil es Teil des State-Dirs ist.

Und Dreaming?

Auch da ist es zweigeteilt:

1. Machine State von Dreaming

Laut Doku schreibt Dreaming Machine-State nach:

# 
memory/.dreams/

Das ist Workspace-Inhalt.

2. Human-readable Dreaming Output

Außerdem schreibt Dreaming nach:

  • DREAMS.md
  • optional memory/dreaming/<phase>/YYYY-MM-DD.md

Das ist ebenfalls Workspace-Inhalt.

Daraus folgt

Wenn du openclaw backup create mit Default-Einstellung nutzt, also inkl. Workspace, dann sind normalerweise dabei:

#
  • QMD SQLite Index unter ~/.openclaw/memory/...sqlite
  • Dreaming Machine-State unter workspace/memory/.dreams/
  • Dream Diary / Reports unter DREAMS.md und memory/dreaming/...

Der echte Caveat

Gefährlich wird es nur, wenn du Pfade aus dem Default rauskonfiguriert hast, also z. B.:

  • QMD/Memory-Store außerhalb von ~/.openclaw
  • Workspace außerhalb des Standardpfads
  • oder andere Export-/Store-Pfade außerhalb von State-Dir und Workspace

Dann würde ich diese separat zusätzlich sichern, weil backup create laut Doku primär diese Quellen sammelt:

  • State-Dir
  • aktive Config
#
  • externe credentials/
  • Workspace(s)

Nicht pauschal „irgendwelche frei konfigurierten Zusatzpfade überall im Filesystem“.

Kurzantwort auf deine konkrete Sorge

  • ~/.openclaw/memory/main.sqlite: ja, ist beim Default-Setup mit drin
  • Dreaming: ja, ebenfalls, wenn Workspace mitgesichert wird
  • nicht automatisch garantiert nur dann, wenn du die Pfade bewusst aus dem Standardbereich herausgezogen hast

Docs:

#

Wenn du willst, schreibe ich dir noch eine „was ist bei QMD konkret zu sichern“ Checkliste mit Default- vs Custom-Path-Fällen.

past herald
#

Jap - mach mir eine "„was ist bei QMD konkret zu sichern“ Checkliste"

hollow plazaBOT
#

Klar, hier ist die QMD-Backup-Checkliste.
Die Kurzfassung zuerst:

Wenn du Default-Pfade nutzt, ist die simpelste sichere Regel:
komplett ~/.openclaw/ sichern.
Dann sind QMD-Index, Config, Sessions, Credentials und der Default-Workspace mit drin.

QMD konkret sichern, Checkliste

1) Immer sichern

  • [ ] komplettes State-Dir
    ~/.openclaw/
    Darin liegen bei Default-Setup u. a.:
    • openclaw.json
    • credentials/
#
  • agents/<agentId>/agent/auth-profiles.json
    • agents/<agentId>/sessions/
    • QMD/Memory-Index:
      ~/.openclaw/memory/{agentId}.sqlite
      also z. B.
      ~/.openclaw/memory/main.sqlite

2) Workspace sichern

  • [ ] aktiven Workspace sichern
    • wenn Default-Workspace: meist schon in ~/.openclaw/workspace, also durch ~/.openclaw/ bereits abgedeckt
    • wenn Custom-Workspace außerhalb von ~/.openclaw/: separat sichern

Für QMD/Dreaming im Workspace besonders relevant:

#
  • [ ] MEMORY.md
  • [ ] memory/YYYY-MM-DD.md
  • [ ] DREAMS.md
  • [ ] memory/.dreams/ ← Dreaming Machine-State
  • [ ] memory/dreaming/ ← Dreaming Reports
  • [ ] ggf. skills/, AGENTS.md, SOUL.md, USER.md, falls Verhalten/Memory-Workflow davon abhängt

3) Zusätzlich sichern, falls du Custom-Pfade nutzt

Nur nötig, wenn du von den Defaults abgewichen bist:

  • [ ] Custom Workspace-Pfad außerhalb ~/.openclaw
  • [ ] Custom QMD Store/SQLite-Pfad außerhalb ~/.openclaw
  • [ ] extra QMD source paths / zusätzliche indexierte Ordner außerhalb Workspace
  • [ ] sessions.exportDir falls außerhalb von Workspace/State-Dir
  • [ ] Secrets/Env-Dateien außerhalb von ~/.openclaw/.env
#
  • z. B. systemd EnvironmentFile
    • oder nur im Shell-Env gesetzte Keys

4) Wichtiger Stolperstein

Wenn du openclaw backup create mit

--no-include-workspace

verwendest, dann ist QMD SQLite im State-Dir zwar drin, aber Workspace-basiertes Dreaming / Diary / Daily Memory nicht.

Also bei Dreaming besser Workspace mitnehmen.

#

5) Nicht blind 1:1 übernehmen

  • [ ] nicht die alte globale Node-/npm/pnpm-Installation kopieren
  • [ ] nicht alte Service-Dateien blind übernehmen
  • [ ] nicht mehrere alte Workspace-Leichen mitschleppen, z. B. ~/openclaw, wenn das gar nicht mehr aktiv ist

6) Praktischer QMD-Migrations-Check

Vor dem Umzug würde ich genau das einmal prüfen:

openclaw status
openclaw gateway stop
openclaw backup create --dry-run --json

Damit siehst du gut, welche Pfade OpenClaw selbst einsammeln würde.

#

Wenn du ganz auf Nummer sicher gehen willst:

  • manueller Copy des State-Dirs
  • plus separater Check auf Custom-Pfade
  • optional zusätzlich:
    openclaw backup create --verify

7) Meine Faustregel für QMD

Default-Setup:

  • ~/.openclaw/ komplett sichern
  • fertig

Custom-Setup:

  • ~/.openclaw/ komplett sichern