Memory-Backup vor Update, damit Du nach einem Schema-Migrations-Bug nicht weinst

Updates sind selten das Problem. Updates wo etwas schiefgeht sind das Problem. Im April hatte ich eine Prisma-Migration die unsere agent_observations-Tabelle versehentlich auf eine neue Constraint gezwungen hat. Ungefähr 4.000 Observations waren tot. Wir hatten zum Glück ein pg_dump von zwei Tagen vorher, sonst wäre die ganze Memory-Schicht der Fleet weg gewesen. Seitdem ist Backup vor Update Pflicht, kein nice-to-have. Hier ist der Ablauf den ich seitdem fahre.

1. Klar machen was eigentlich gebackupt werden muss

Memory ist nicht nur die Datenbank. Es ist mehrere Sachen zusammen. Die Postgres-Datenbank mit allen agent_*-Tabellen ist der große Brocken. Dann die Configs, also ~/.claude/settings.json, ~/.claude/mcp.json oder .claude.json je nach Setup. Dann die Skills und Sub-Agents unter ~/.claude/skills/ und ~/.claude/agents/. Und falls Du MCP-Server selbst hostest, deren State (oft auch Postgres oder SQLite).

Wenn Du nur die DB sicherst und die .claude-Configs vergisst, restore-st Du im Notfall in eine Umgebung wo Claude nicht weiß welche MCP-Server existieren. Ich hab das einmal gemacht, danach zwei Stunden Tools nachkonfiguriert.

2. Welche DB ist eigentlich gemeint

Pruef wo Dein Memory wirklich liegt. Bei den meisten Setups die ich gesehen habe ist es Postgres lokal oder auf einem Server. Schau in der MCP-Config nach. Bei mir ist das postgres://localhost:5433/matthiasmeyer_db mit den nex_*- und agent_*-Tabellen drin.

Wenn Du eine Memory-as-a-Service-Lösung nutzt (also gehostete Variante), liegt die DB nicht bei Dir. Dann ist Dein Backup-Job ein Export-API-Call oder ein Hosting-Provider-Snapshot. Klaer das vorher, bevor Du das im Disaster-Fall lernst.

3. Das pg_dump-Command das wirklich funktioniert

Nimm nicht nur pg_dump dbname > file.sql. Das wird bei größeren Memory-DBs schnell unhandlich. Custom-Format mit Kompression ist besser.

pg_dump \
  --host=localhost \
  --port=5433 \
  --username=postgres \
  --dbname=matthiasmeyer_db \
  --format=custom \
  --compress=9 \
  --file=memory-backup-$(date +%Y-%m-%d-%H%M).dump

Das gibt Dir eine kompakte binaere Datei die mit pg_restore lesbar ist. Bei mir sind das für 107 MB DB ungefähr 18 MB Backup. Compress 9 ist langsam, aber bei einem Schritt pro Tag oder pro Update egal.

Optional kannst Du --exclude-table='pg_*' setzen wenn Du System-Stuff weglassen willst, aber custom-format ignoriert das eh weitgehend.

4. Die Configs separat sichern

Tar-ball über das ganze .claude-Verzeichnis. Klein, schnell, vollständig.

tar -czf claude-config-$(date +%Y-%m-%d).tar.gz \
  -C "$HOME" .claude

Wenn Du Secrets in den Configs hast (API-Keys in mcp.json), nimm das ernst und leg den Tarball nicht in einen oeffentlichen Bucket. Verschluesselt sichern oder lokal lassen. Klassischer Anti-Pattern: Backup-Skript pusht zu S3 ohne Bucket-Policy zu prüfen.

5. Ein Test-Restore in eine zweite DB

Backup ohne Restore-Test ist kein Backup. Das hab ich einmal hart gelernt. Mach das einmal jetzt und Du weißt dass es geht.

createdb -h localhost -p 5433 -U postgres memory_restore_test
pg_restore \
  --host=localhost --port=5433 --username=postgres \
  --dbname=memory_restore_test \
  --no-owner --no-privileges \
  memory-backup-2026-05-19-1430.dump

Dann mach einen SELECT count(*) FROM agent_observations; in der Test-DB und vergleich mit der echten. Wenn Zahlen passen, ist Dein Backup gut. Test-DB danach dropdb.

Diesen Test machst Du einmal beim Aufsetzen und dann nach jedem größeren Schema-Update nochmal. Nicht täglich. Sonst wird es lästig.

6. Backup-Lifecycle, wie viele behalten

Drei Stufen die sich bei mir bewaehrt haben. Letzte 7 Tage jeden Tag. Dann letzte 4 Wochen pro Woche eines. Dann letzte 12 Monate pro Monat eines.

Mit Compress 9 sind das bei meiner DB-Groesse ungefähr 1 GB Backup-Volume insgesamt. Auf einem 500 GB Server irrelevant. Auf einem Hetzner Storage-Box guenstig.

Konkretes Cleanup-Script-Pattern (nicht copy-paste, an Deine Struktur anpassen):

# Behalt die letzten 7 daily, loesch den Rest
find ./backups/daily -name "memory-backup-*.dump" -mtime +7 -delete

7. Automatisieren über Cron, aber mit Heads-up-Mail

Backups die niemand checkt sind keine Backups. Cron-Eintrag der täglich um 3 Uhr nachts den Dump macht und das Ergebnis per Mail schickt.

0 3 * * * /usr/local/bin/memory-backup.sh 2>&1 | mail -s "Memory Backup $(hostname)" [email protected]

Wenn Du eine Woche keine Mail bekommst, weißt Du dass etwas kaputt ist. Wenn die Mail aber jeden Tag "OK" sagt, blendest Du sie nach drei Wochen aus und merkst es trotzdem nicht. Besser: Mail nur bei Fehler. Oder ein Healthcheck-Service der pingt wenn das Skript läuft, und alarmiert wenn er 30 Stunden nichts hört.

8. Vor jedem Update einen frischen Pre-Update-Dump

Das ist der eigentliche Punkt vom Playbook. Vor jedem Migrations-Run, vor jedem Prisma db push, vor jedem migrate deploy, mach einen Dump und benenn ihn deutlich.

pg_dump ... --file=memory-pre-update-$(date +%Y-%m-%d-%H%M)-VOR-PRISMA-MIGRATE.dump

Klingt nach Overkill, ist aber Disziplin. Wenn die Migration danach klappt, loescht Du den Dump in einer Woche. Wenn sie nicht klappt, hast Du den richtigen State von vor 10 Minuten und nicht den von gestern Nacht.

Bei mir läuft das per Pre-Commit-Hook auf den Prisma-Migrations-Ordner. Wenn ein Schema-File geaendert wird, fragt das Git ob ich vorher Backup machen will. 80 Prozent ja, 20 Prozent nein (Dev-DB, egal).

9. Memory-as-a-Service Spezialfall

Wenn Du eine Hosted-Memory-Lösung nutzt (z.B. über einen Cloud-MCP-Provider), ist das Backup-Verhalten anders. Pruef drei Sachen.

Hat der Anbieter automatische Snapshots, und wenn ja wie oft. Bei vielen ist das alle 6 oder 24 Stunden, was vor einem Schema-Bug zu wenig sein kann.

Gibt es eine Export-API. Du willst nicht abhängig sein. Pruef ob es eine /export-Route gibt die Dir Deine Daten als JSON oder SQL gibt.

Was passiert bei Provider-Insolvenz. Klingt paranoid, ist aber bei kleineren MCP-Anbietern echt. Mindestens einmal die Woche Export ziehen und lokal lagern.

10. Restore-Drill ein Mal pro Quartal

Letzter Schritt, langfristig. Einmal pro Quartal ziehst Du Dir Dein neuestes Backup, restore-st in eine Test-DB, faehrst Claude Code dagegen mit einer Test-Config, und schaust ob er Memory liest. Das macht keinen Spass, aber wenn das Drittel Stunde dauert und Du es einmal pro Quartal machst, bist Du immun gegen die Klassiker.

Was Du dabei testen willst. Geht der Restore durch. Sieht Claude die Observations und Decisions. Kommen die Cross-Agent-Recalls noch durch (Permissions, Indexes). Funktioniert eine Search auf einem alten Tag.

Wenn etwas davon nicht klappt, weißt Du das jetzt und nicht im Notfall.

Wenn Du danach Memory langfristig sauber halten willst, schau Dir Memory-Drift reparieren und Memory portabel nutzen an. Backup ist der Notfall-Layer, Hygiene und Portabilität sind die täglichen Sachen.