OpenClaw sichern und migrieren: Backup, Restore und Server-Umzug ohne Datenverlust

Die Nacht, die diesen Post hervorgebracht hat

Es war 2:00 Uhr morgens. Sams Heartbeat-Cron feuerte — keine Antwort. Atlas' Morgenreport erschien nicht. Ich öffnete den Hetzner-Dashboard: Server-Status "Failed".

Der Storage-Attach hatte einen Fehler. Das Root-Volume war nicht mehr beschreibbar. Alle Docker-Container: gestoppt. Das Gateway: offline.

Das wirklich schmerzhafte: Wir hatten kein ordentliches Backup. Die Hetzner-Snapshots waren drei Tage alt. Die SOUL.md-Dateien, MEMORY.md-Einträge, die Cron-Job-Konfigurationen, die feinjustierten Skills — alles potenziell verloren.

Wir haben die meisten Daten wiederhergestellt. Aber wir haben drei Stunden dafür gebraucht, was 20 Minuten hätte dauern sollen.

Dieser Post ist das, was wir danach gebaut haben. Du wirst hoffentlich nie in der Situation sein — aber wenn du es bist, wirst du froh sein, dass du das hier gelesen hast.

---

Was bei OpenClaw überhaupt gesichert werden muss

Bevor wir über Werkzeuge reden: Was verliert man eigentlich, wenn ein Server stirbt?

Tier 1: Kritisch — ohne das ist nichts wiederherstellbar

Tier 2: Wichtig — deutlicher Qualitätsverlust ohne das

Tier 3: Nützlich — kann rekonstruiert werden, aber kostet Zeit

Was du NICHT sichern musst:

---

Das Backup-System: Automatisch, täglich, zweifach

Wir sichern auf zwei Arten gleichzeitig:

Methode 1: Git-Repository für alle Workspace-Dateien

Das Elegante an OpenClaw-Workspaces: Sie sind überwiegend Textdateien. Markdown, JSON, Shell-Scripts. Das ist exakt das Format, für das Git gebaut wurde.

```bash

# Einmalig einrichten: Workspace als Git-Repository initialisieren

cd /opt/agents/workspaces

# Für jeden Agenten:

cd sam

git init

git remote add origin git@github.com:dein-org/openclaw-workspace-sam.git

# .gitignore anlegen — API-Keys DÜRFEN NICHT committed werden

cat > .gitignore << 'EOF'

.env

.env.local

*.env

memory/heartbeat-state.json

EOF

git add .

git commit -m "initial: sam workspace backup"

git push -u origin main

```

Täglicher Backup-Cron (läuft bei uns um 03:00 Uhr UTC):

```

Zeitplan: 0 3 * * *

Prompt:

Führe für alle Agent-Workspaces ein Git-Commit und Push durch:

(gleiche Befehle für peter, maya, alex, iris, atlas)

Melde kurz: wie viele Dateien geändert wurden (oder "no changes" wenn nichts neu ist).

```

Vorteil: Vollständige History. Du kannst zu jedem Tag zurückgehen und sehen, was MEMORY.md zu diesem Zeitpunkt enthielt. Oder du rollst auf den Stand von vor einer Woche zurück, wenn ein Agent anfängt, komisch zu agieren.

Methode 2: Verschlüsseltes Archiv der kompletten OpenClaw-Konfiguration

Der Git-Ansatz sichert Workspaces — aber nicht die OpenClaw-Konfiguration selbst und nicht die API-Keys (die nicht in Git gehören).

Für diese sichern wir täglich ein verschlüsseltes Archiv auf Hetzner Object Storage:

```bash

#!/bin/bash

# /opt/backup/openclaw-backup.sh

# Täglich ausgeführt, sollte NICHT in Git sein (enthält Encryption-Key)

BACKUP_DATE=$(date +%Y-%m-%d)

BACKUP_DIR="/tmp/openclaw-backup-$BACKUP_DATE"

BACKUP_FILE="/tmp/openclaw-backup-$BACKUP_DATE.tar.gz.gpg"

# Zu sichernde Verzeichnisse

mkdir -p "$BACKUP_DIR"

cp -r ~/.openclaw/ "$BACKUP_DIR/openclaw-config"

cp -r /opt/agents/workspaces/ "$BACKUP_DIR/workspaces"

# Archivieren

tar czf - "$BACKUP_DIR" | gpg --symmetric --cipher-algo AES256 --passphrase "$BACKUP_ENCRYPTION_KEY" --batch > "$BACKUP_FILE"

# Zu Hetzner S3-kompatiblem Object Storage hochladen

aws s3 cp "$BACKUP_FILE" "s3://dein-backup-bucket/openclaw/$BACKUP_DATE.tar.gz.gpg" --endpoint-url https://fsn1.your-objectstorage.com

# Aufräumen

rm -rf "$BACKUP_DIR" "$BACKUP_FILE"

echo "Backup $BACKUP_DATE abgeschlossen."

```

Der `BACKUP_ENCRYPTION_KEY` liegt nur in der `.env` auf dem Server — nicht im Skript, nicht in Git.

Aufbewahrung: Wir behalten die letzten 30 täglichen Backups. Ältere werden automatisch gelöscht:

```bash

# Backups älter als 30 Tage löschen

aws s3 ls "s3://dein-backup-bucket/openclaw/" --endpoint-url https://fsn1.your-objectstorage.com | awk '{print $4}' | sort | head -n -30 | xargs -I{} aws s3 rm "s3://dein-backup-bucket/openclaw/{}" --endpoint-url https://fsn1.your-objectstorage.com

```

---

Restore: Von null zu vollem Betrieb in unter 20 Minuten

Das ist der Test, der zeigt, ob ein Backup-System wirklich funktioniert. Wir haben unsere eigene Wiederherstellung einmal "trocken" durchgespielt — hier ist die Anleitung.

Schritt 1: Neuen Server bereitstellen (0-5 Minuten)

Hetzner CX32 erstellen, SSH-Key eintragen, IP notieren. Das geht in unter 3 Minuten.

Schritt 2: Basis-Setup (5-8 Minuten)

```bash

# Verbinden

ssh root@<NEUE-IP>

# System aktualisieren

apt update && apt upgrade -y

# Essentials

apt install -y curl git ufw

# Firewall

ufw default deny incoming && ufw default allow outgoing

ufw allow ssh && ufw enable

# Tailscale

curl -fsSL https://tailscale.com/install.sh | sh

tailscale up

# → Im Browser authorisieren

# Docker

curl -fsSL https://get.docker.com | sh

# Node.js 22

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -

apt install nodejs -y

# OpenClaw

npm install -g openclaw@latest

```

Schritt 3: Backup herunterladen und entschlüsseln (8-12 Minuten)

```bash

# AWS CLI installieren (für Object Storage)

apt install awscli -y

# Neuestes Backup herunterladen

BACKUP_DATE=$(date +%Y-%m-%d)

aws s3 cp "s3://dein-backup-bucket/openclaw/$BACKUP_DATE.tar.gz.gpg" /tmp/restore.tar.gz.gpg --endpoint-url https://fsn1.your-objectstorage.com

# Entschlüsseln und entpacken

# Encryption-Key aus sicherem Passwort-Manager holen (1Password, Bitwarden, etc.)

gpg --decrypt --passphrase "$BACKUP_ENCRYPTION_KEY" --batch /tmp/restore.tar.gz.gpg | tar xz -C /tmp/

# Dateien an die richtigen Stellen

cp -r /tmp/openclaw-backup-*/openclaw-config ~/.openclaw/

mkdir -p /opt/agents

cp -r /tmp/openclaw-backup-*/workspaces /opt/agents/workspaces

```

Schritt 4: API-Keys aus Passwort-Manager wiederherstellen

Das ist der einzige Schritt, der manuell bleibt — und der so sein soll. API-Keys in Backups zu speichern ist ein Sicherheitsrisiko.

Wir speichern alle OpenClaw API-Keys in 1Password als "Secure Note". Bei einer Wiederherstellung: 1Password öffnen, alle Keys in die neue `.env` kopieren.

```bash

# .env pro Agent neu anlegen

cat > /opt/agents/workspaces/sam/.env << 'EOF'

ANTHROPIC_API_KEY=<aus 1Password>

TELEGRAM_TOKEN=<aus 1Password>

DISCORD_TOKEN=<aus 1Password>

CLICKUP_API_TOKEN=<aus 1Password>

EOF

chmod 600 /opt/agents/workspaces/sam/.env

# Gleich für alle anderen Agenten

```

Schritt 5: Docker Compose und Gateway starten (12-20 Minuten)

```bash

# Docker Compose starten

cd /opt/agents

docker compose up -d

# Gateway als systemd-Service einrichten (wie im VPS-Setup-Post beschrieben)

systemctl enable openclaw

systemctl start openclaw

# Test

openclaw gateway status

openclaw channels list

```

Wenn alles grün ist: Agenten sind online. MEMORY.md, SOUL.md, Skills, Cron-Jobs — alles wiederhergestellt.

Unsere Zeit beim echten Restore nach dem Server-Ausfall: 23 Minuten. Mit diesem Playbook wären es unter 20 Minuten gewesen.

---

Server-Migration: Wenn du den Anbieter wechselst

Migration ist technisch dasselbe wie Restore — aber mit dem alten Server noch laufend, was es einfacher macht.

```bash

# Auf dem alten Server: finales Backup erzwingen

cd /opt/backup && bash openclaw-backup.sh

# Auf dem neuen Server: normaler Restore-Prozess (Schritte 1-5 oben)

# Testen ob alles funktioniert, bevor der alte Server abgeschaltet wird

# Tailscale: alten Server aus dem Netzwerk entfernen

# → admin.tailscale.com → Devices → alter Server → Remove

```

Die Falle: Wenn zwei Server gleichzeitig laufen und beide dieselben Telegram/Discord-Bots verbunden haben, kriegt der Agent doppelte Nachrichten — und antwortet doppelt. Vor dem Starten der neuen Instanz: Gateway auf dem alten Server stoppen.

```bash

# Auf dem alten Server, bevor der neue gestartet wird:

systemctl stop openclaw

docker compose stop

```

---

Backup-Verifizierung: Vertrauen ist gut, testen ist besser

Ein Backup, das nie getestet wurde, ist kein Backup. Es ist die Illusion eines Backups.

Wir führen jeden Monat eine "Restore-Probe" durch — nicht auf einem echten Server, sondern lokal in einer VM:

```bash

# Lokal: temporäre VM oder Docker-Container als Testumgebung

docker run -it --rm ubuntu:24.04 /bin/bash

# Darin: kompletten Restore-Prozess durchspielen

# Ziel: Wie lange dauert es? Was fehlt? Was funktioniert nicht?

```

Das klingt aufwändig. In der Praxis dauert die Probe 30-40 Minuten einmal im Monat. Der Nutzen: du weißt, dass du im Ernstfall nicht überrascht wirst.

---

Was wir gelernt haben

Nach dem Server-Ausfall und danach:

1. Zwei Backup-Methoden sind besser als eine. Git für Workspace-Dateien, verschlüsseltes Archiv für alles andere.

2. API-Keys niemals im Backup. Im Passwort-Manager, separat verwaltet.

3. Backups täglich, nicht wöchentlich. MEMORY.md ändert sich täglich — ein wöchentliches Backup bedeutet bis zu 7 Tage Datenverlust.

4. Restore einmal proben. Ein ungetestetes Backup ist ein Risiko, kein Sicherheitsnetz.

5. Hetzner-Snapshots sind kein Ersatz. Sie decken nicht alle Szenarien ab und sind langsam zum Wiederherstellen.

Drei Stunden Downtime und verlorene Arbeit haben uns gelehrt, was 3 Stunden Backup-Setup-Zeit verhindert hätten.

---

Das vollständige Backup-System — inklusive der vollständigen Shell-Scripts, der 1Password-Struktur für API-Keys und der monatlichen Restore-Probe-Checkliste — ist im OpenClaw Setup Playbook dokumentiert.

18 Kapitel, basierend auf echter Produktionserfahrung. Inklusive der Fehler, die wir gemacht haben.

Komplett auf Deutsch verfügbar. 🇩🇪