KI hat die Datenbank gelöscht: ein 7-Minuten-Plan

Praktische Informationen zur Arbeit mit Ailoot finden Sie in der Dokumentation.

Was Sie in der ersten Minute tun sollten: STOPP, keine Panik#

Wenn Ihnen das passiert, müssen Sie als Erstes den Agenten stoppen. Versuchen Sie nicht, seine Aktionen selbst rückgängig zu machen, fordern Sie ihn nicht auf, „alles wiederherzustellen“, und geben Sie keine neuen Prompts ein. Jede weitere Aktion des Agenten könnte die Datenträgerblöcke überschreiben, in denen Ihre Daten möglicherweise noch gespeichert sind.

1. Schließen Sie das Terminal des Agenten

   Unterbrechen Sie den gefährlichen Befehl sofort mit Ctrl+C. Warten Sie nicht auf das Ende der Löschung. Ein Agentenstopp beendet nicht zwingend Kindbefehle, Remotejobs oder Datenbankabfragen. Identifizieren und stoppen oder stornieren Sie die tatsächliche Schreiboperation. Eskalieren Sie die Beendigung bei weiterer Zerstörung. Lassen Sie unabhängige Prozesse mit nützlichen offenen Dateien weiterlaufen.

2. Starten Sie Ihren Laptop NICHT neu

   Gelöschte Daten können wiederherstellbar bleiben. Speicher- und Datenbankverhalten, SSD-Discard/TRIM und spätere Schreibvorgänge entscheiden darüber. Minimieren Sie Schreibzugriffe auf das betroffene Volume; setzen Sie keine noch vorhandenen Bytes voraus.

3. Schließen Sie KEINE offenen Prozesse

   Bewahren Sie unabhängige Prozesse mit geöffneten gelöschten Dateien, weil Wiederherstellung über Dateideskriptoren möglich sein kann. Das gilt nicht für den destruktiven Schreiber: Stoppen Sie ihn zuerst. Lassen Sie keine Löschung zur Bewahrung eines Handles weiterlaufen.

4. Dokumentieren Sie Vorfallzeit und sichtbare Belege

   Erfassen Sie genaue Zeit, betroffene Pfade und sichtbare Befehlsausgabe. Speichern Sie Aufnahmen oder Logs auf einem separaten geprüften Gerät statt dem beschädigten Volume. Sichern Sie dort überlebende erfasste, nicht erfasste und ignorierte Dateien samt Git-Metadaten vor Wiederherstellung.

Als Nächstes bleiben 6 Minuten zur Wiederherstellung. Los geht's.

Minuten 2–3: Dokumentieren Sie genau, was schiefgelaufen ist#

Öffnen Sie ein neues Terminalfenster. Nicht das, in dem der Agent läuft – ein anderes. Führen Sie diese drei Befehle der Reihe nach aus.

1. Halten Sie genau fest, was sich im Git-Repository geändert hat:

git status
git log --since="30 minutes ago" --all --oneline

Eine gelöschte erfasste Datei kann noch im Index oder Commit liegen. Sichern Sie vor jedem Restore den aktuellen Arbeitsbaum einschließlich nicht erfasster und ignorierter Dateien. Wiederherstellung am selben Ort kann überlebende Änderungen überschreiben. Prüfen und retten Sie in einer separaten Kopie.

2. Prüfen Sie, welche Agentenprozesse laufen:

ps aux | grep -i claude
ps aux | grep -i cursor

Bestimmen Sie den weiterhin gefährlich schreibenden Prozess. Ein Namensmatch allein genügt nicht. Stoppen Sie ihn und bestätigen Sie den Stopp. Bewahren Sie unabhängige Prozesse mit nützlichen offenen Dateien. Scheitert sanftes Beenden bei weiterer Zerstörung, kann erzwungene Beendigung nötig sein.

3. Speichern Sie das Sitzungsprotokoll des Agenten:

Claude Code speichert JSONL-Sitzungen unter ~/.claude/projects/. Cursor speichert sie unter ~/.cursor/. Erstellen Sie sofort eine Kopie:

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Ersetzen Sie /external/incident-evidence/ durch ein vorhandenes Belegverzeichnis auf einem separaten geprüften eingebundenen Gerät. Schreiben Sie weder auf das betroffene Volume noch über vorhandene Belege. Dieser Ordner enthält das wörtliche Gespräch mit dem Agenten – welche Befehle er ausgeführt hat, was er geantwortet hat und in welcher Reihenfolge. Er ist Ihre wichtigste Quelle zur Untersuchung des Vorfalls und möglicherweise zur Wiederherstellung gelöschter Dateien aus seinem Kontext (siehe Schritt 4).

Minute 4: git reflog – Ihre beste Chance#

git reflog zeichnet lokale Referenzbewegungen auf, solange Einträge aufbewahrt werden. Verfall und Bereinigung unterscheiden sich; unerreichbare Objekte können verschwinden. Es ist kein garantiertes Archiv aller früheren Commits. Führen Sie die folgenden Schritte in einer gesicherten Repositorykopie auf dem separaten Gerät aus.

Schritt 1. Zeigen Sie das Protokoll an:

git reflog --all

Sie erhalten eine Liste wie diese:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Suchen Sie den Stand vor dem Schaden durch den Agenten. Jeder Eintrag ist ein „Snapshot“ des Repository-Zustands zu diesem Zeitpunkt.

Schritt 2. In einen separaten Arbeitsbaum wiederherstellen:

Führen Sie dies erst aus einer auf ein separates geprüftes Gerät kopierten Repositorysicherung samt überlebender Arbeit aus. Verwenden Sie den genau in reflog geprüften Commit-SHA und einen unbenutzten Branch sowie Zielpfad:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Prüfen Sie Dateien unter ../recovery-check und vergleichen Sie sie vor einem Rückkopieren mit gesicherten nicht committeten Dateien. Der Befehl checkt den gewählten Commit separat aus und setzt nicht den beschädigten Arbeitsbaum zurück. Verknüpfte Worktrees teilen den Git-Objektspeicher der Repositorykopie: Das ist ein Wiederherstellungsarbeitsbereich, kein unabhängiges Backup. Siehe offizielle git-worktree-Dokumentation.

Falls reflog ebenfalls bereinigt wurde (der Agent konnte git gc ausführen):

git fsck --lost-found

Dieser Befehl findet „verlorene“ Commits und Blobs (Dateiobjekte), die keinem Branch mehr zugeordnet sind. Sie erscheinen unter .git/lost-found/commit/ und .git/lost-found/other/. So stellen Sie eine Datei von dort wieder her:

git cat-file -p <SHA1-blob> > recovered-file.ext

Wann git reflog nicht hilft:

• Die Datei befand sich nur im Arbeitsverzeichnis, ohne Commit oder Stash → reflog kann sie nicht finden
• Mehr als 90 Tage sind vergangen (die standardmäßige Einstellung gc.reflogExpire), und git gc wurde ausgeführt
• Das gesamte Repository wurde gelöscht (rm -rf .git) – dann benötigen Sie Time Machine oder einen Snapshot

Minute 5: Stellen Sie die Datenbank aus einem Backup wieder her#

Die Datenbank wurde mit DROP DATABASE, DROP TABLE oder DELETE FROM ... WHERE ... (ohne WHERE-Klausel) gelöscht. Was sollten Sie tun?

Schritt 1. Prüfen Sie, ob Ihr Anbieter PITR anbietet:

Schritt 2. Stellen Sie eine neue Instanz wieder her, nicht die alte:

Stellen Sie niemals eine aktive Datenbank wieder her. Erstellen Sie aus dem Backup eine neue Instanz und schalten Sie dann die Anwendung auf diese um. Falls etwas schiefgeht, können Sie den DNS-Eintrag zurücksetzen.

Schritt 3. Wenn PITR nicht aktiviert war, verwenden Sie den neuesten Snapshot:

# AWS RDS, list snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restore from a snapshot:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Hinweis zu Supabase, der 2026 viele überrascht hat: Wenn PITR aktiviert ist, werden keine täglichen Backups mehr erstellt. Ein kontraintuitives Verhalten; dadurch könnten Sie am Ende überhaupt keine Backups haben. Prüfen Sie unter Dashboard → Database → Backups, ob PITR aktiv ist UND ob ein Snapshot zur Wiederherstellung vorhanden ist.

Minute 6: Time Machine, lsof und Datenträger-Snapshots#

macOS – Time Machine:

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine erstellt jede Stunde Snapshots, behält stündliche Snapshots einen Tag lang und tägliche Snapshots eine Woche lang; wöchentliche Snapshots bleiben unbegrenzt erhalten. Wenn Ihr Laptop mit einer Time Capsule oder einem externen Laufwerk verbunden ist, ist Ihr Projekt dort mit stündlicher Granularität gesichert.

Linux – die Datei wurde gelöscht, ist aber noch von einem Prozess geöffnet:

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Die Erfolgschance liegt bei etwa 95 %, sofern der Prozess nicht geschlossen wurde. Funktioniert mit ext4, xfs und btrfs.

macOS – das Äquivalent mit lsof:

lsof | grep deleted

Das Kopieren der Datei ist schwieriger (es gibt kein /proc/), aber mit lldb ist es möglich:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Snapshot des gesamten Datenträgers (Linux, letzter Ausweg):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Damit wird die gesamte Partition als Image gespeichert. Stellen Sie die Daten anschließend mit extundelete oder photorec wieder her. Die Wiederherstellungschance hängt davon ab, wie viel seit der Löschung auf den Datenträger geschrieben wurde. Wenn nichts geschrieben wurde, liegt sie bei 80–90 %. Wenn der Datenträger bereits seit einer Stunde genutzt wird, beträgt sie 20–30 %.

Minute 7: Was tun, wenn es kein Backup gibt#

Option 1 – Support des Anbieters:

AWS, Yandex Cloud, Google Cloud und DigitalOcean stellen gelegentlich Daten aus ihrem internen Speicher wieder her, selbst nach einem Vorfall beim Kunden, besonders bei kostenpflichtigen Tarifen. Eröffnen Sie ein Support-Ticket, nennen Sie den genauen Zeitpunkt des Vorfalls und fügen Sie Screenshots des Zustands bei. Dies funktioniert am ehesten bei großen Anbietern, die auf ihrer Seite automatische Backups aufbewahren. Die Erfolgschance liegt bei 40–60 %; die Antwortzeit beträgt 24–72 Stunden.

Option 2 – S3-Versionierung:

Wenn Dateien in S3 (oder Yandex Object Storage) lagen und die Versionierung aktiviert war, sind alle Versionen physisch vorhanden; sie sind lediglich als „gelöscht“ markiert.

# AWS—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Wichtiger Hinweis: Claude Code speichert Sitzungen nicht unbegrenzt – alte JSONL-Dateien werden nach mehreren Wochen automatisch gelöscht. Um im Katastrophenfall einen Monat JSONL-Verlauf zu haben, kopieren Sie ~/.claude/projects/ einmal pro Woche mit einem einfachen Cronjob auf ein externes Laufwerk:

# In crontab, every Sunday at 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Das ist kostenlos und rettet Sie, wenn „alles weg ist, es kein Backup gibt und das Reflog leer ist“.

7 Regeln, damit das nie wieder passiert#

1. Plan Mode vor jeder destruktiven Aktion. In Claude Code:

claude --plan

Der Agent erstellt vorher einen Plan. Sie lesen ihn, sehen DROP TABLE users und brechen ab. Ohne Plan Mode entscheidet der Agent selbst und führt den Befehl innerhalb von Millisekunden aus. Mehr dazu im Leitfaden zum Plan Mode in Claude Code.

2. Hooks als zusätzliche Warnschranke. Nutze einen getesteten PreToolUse-Hook, der Ereignis-JSON aus stdin liest und bei erkannter Hochrisikoaktion Exit 2 liefert. Das vollständige Beispiel unten deckt Bash, Write und Edit ab. Es ist keine Sicherheitsgrenze und kann indirekte Aktionen übersehen. Datenbankrechte und Sandbox bleiben eng begrenzt.

3. Ein schreibgeschützter DB-Benutzer für den Agenten. Erstellen Sie einen separaten Benutzer für den Agenten, der keine Berechtigungen für DROP, TRUNCATE oder DELETE hat:

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Wenn der Agent wirklich schreiben muss, wechseln Sie manuell zu einem anderen Benutzer. Ein schreibgeschützter Benutzer reicht für alltägliche Aufgaben aus (Datenanalyse, Berichte, Dashboards).

4. Geprüfte Änderungen in Git sichern. Ein PostToolUse-Hook in .claude/settings.json kann nach Write und Edit eine Erinnerung ausgeben:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Prüfen Sie den Diff und committen Sie nur die vereinbarten Dateien manuell.' >&2"
          }
        ]
      }
    ]
  }
}

Dieses Beispiel gibt nur eine Erinnerung aus; es fügt keine Dateien zum Index hinzu und erstellt keine Commits. Prüfen Sie den Diff und committen Sie nur die vereinbarten Dateien manuell. Das Reflog speichert keine Änderungen, die nicht committet wurden.

5. Sandbox-Projekt für Experimente. Lassen Sie den Agenten niemals in einem Projekt arbeiten, das echte Kundendaten enthält. Erstellen Sie einen separaten Ordner ~/sandbox-projects/ mit einer Projektkopie und synthetischen Daten. Verwenden Sie ihn, um einen neuen Prompt, Agenten oder MCP-Server auszuprobieren. Wenn etwas kaputtgeht, entsteht kein Schaden.

6. Datenträger-Snapshots mit restic jede Stunde.

# Install:
brew install restic  # macOS
sudo apt install restic  # Linux

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

Sieben Tage mit stündlichen Backups und vier Wochen mit täglichen Backups – und Sie können jederzeit zu jedem vergangenen Zeitpunkt zurückkehren. Das ist kostenlos und in 10 Minuten eingerichtet.

7. Claude-Code-JSONL-Sitzungen archivieren. Wie oben erwähnt, aber hier als eigene Regel: Planen Sie einmal wöchentlich ein rsync von ~/.claude/projects/ auf ein externes Laufwerk. Das ist kostenlos und erfordert eine Zeile in crontab.

Fertige Hooks zum Blockieren gefährlicher Befehle#

Dieses PreToolUse-Beispiel prüft ausgewählte Bashtexte und sensible Write-/Edit-Pfade. Es liest JSON aus stdin und liefert bei Treffern Exit 2. Indirekte oder verschleierte Aktionen können fehlen. Es ergänzt Sandbox und begrenzte Zugangsdaten statt sie zu ersetzen. Füge es in bestehende Konfiguration ein und teste vor Verwendung.

Übernimm diesen Eintrag in .claude/settings.json, ohne vorhandene Hooks zu ersetzen:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Erstelle .claude/hooks/check-risk.py mit diesem Python-3-Skript:

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Der Hook liest das dokumentierte Ereignis aus stdin, prüft tool_input.command oder tool_input.file_path und endet bei einem Treffer mit Exit 2. Er prüft Write und Edit. Teste eine harmlose erlaubte und eine blockierte Eingabe und prüfe, dass Python sowie das konfigurierte Skript wirklich starten.

Diese lexikalische Zusatzkontrolle kann umgeordnete Flags, Skripte, Aliase, Verschleierung, andere Tools und indirekte Schreibaktionen übersehen oder harmlose zitierte Beispiele ablehnen. Sie verändert keine Betriebssystem- oder Datenbankrechte. Halte Produktionszugangsdaten außerhalb der Agentenumgebung, nutze Nur-Lese-Datenbankrolle und durchgesetzte Sandbox und schütze Hookkonfiguration vor Änderungen. Siehe offizielle Hook-Eingabe und Exitcodes.

Prüfe absichtliche Ausnahmen und führe sie außerhalb des Agenten mit dem passenden begrenzten Konto aus. Eine Shell-Umgebungsvariable ist keine dokumentierte Hook-Abschaltung. Hooks kontrollieren keine gewöhnlichen Terminalbefehle.

Wann Sie der KI Berechtigungen geben sollten (und wann nicht)#

Anthropic dokumentiert das Flag --dangerously-skip-permissions (auch als YOLO-Modus bekannt) als Option für „vertrauenswürdige Umgebungen“. In der Realität von 2026 ist es ein direkter Weg zu einer Katastrophe. Wenn ein Agent nicht um Erlaubnis bitten muss, kann er:

• beliebige Bash-Befehle ohne Bestätigung ausführen
• Dateien schreiben, ohne zu fragen
• einen Subagenten aufrufen, der YOLO übernimmt, ohne dass sich das rückgängig machen lässt

Der dritte Punkt ist am heimtückischsten. Wenn Sie den Hauptagenten mit YOLO starten, arbeiten auch seine Subagenten mit YOLO, und Sie können das nicht überschreiben. Ein Prompt – und eine Kaskade aus 10 parallelen Agenten kann alles auf Ihrem System tun.

Regel:

Alternative – präzise Berechtigungen. In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

Der Agent sieht, was erlaubt ist und was nicht. Sie müssen nicht jedes Mal auf „Ja“ oder „Nein“ klicken – der Agent arbeitet schnell, und Sie behalten die Kontrolle über den Rahmen.

Als Nächstes: Eine 7-Minuten-Checkliste zum Abspeichern#

Checkliste: „Die KI hat es gelöscht – was soll ich tun?“

1. Stoppen Sie den tatsächlichen destruktiven Schreiber sofort und prüfen Sie den Stopp von Kind- und Remoteoperationen
2. Starten Sie nicht neu; bewahren Sie unabhängige Prozesse mit geöffneten gelöschten Dateien
3. Sichern Sie Vorfallzeit und Befehlsbelege auf einem separaten geprüften Gerät
4. Kopieren Sie überlebende Dateien, Git-Metadaten und relevante Sitzungslogs auf dasselbe separate Gerät
5. Prüfen Sie git reflog --all in der gesicherten Repositorykopie und retten Sie einen verifizierten Commit in einen separaten Worktree
6. Wenn Git nicht geholfen hat: git fsck --lost-found
7. Datenbank: PITR (AWS/Yandex/Supabase) oder neuester Snapshot
8. Dateien: Time Machine auf dem Mac, lsof unter Linux
9. Letzter Ausweg: Support des Anbieters + S3-Versionierung
10. Richten Sie nach der Wiederherstellung die 7 Präventionsregeln in diesem Leitfaden ein

Als Nächstes – systematischer Schutz:

• Plan Mode in Claude Code – damit der Agent vor einer destruktiven Aktion einen Plan erstellt
• Hooks in Claude Code – fertige Vorlagen zum Blockieren gefährlicher Befehle
• Änderungen in Claude Code rückgängig machen – ein ausführlicher Leitfaden zu /rewind, Git und 5 Standardmethoden für den Rollback
• Sicherheitsprüfung in Claude Code – regelmäßige Sicherheitsprüfungen des Codes

Ailoot öffnen.