AI raderade databasen: en återställningsplan på 7 minuter

Praktisk information om hur du arbetar med Ailoot finns i dokumentationen.

Vad du ska göra under den första minuten: STOPP, få inte panik#

När det här händer dig är det första du ska göra att stoppa agenten. Försök inte ångra dess åtgärder själv, be den inte att ”återställa allt” och kör inga nya promptar. Varje efterföljande åtgärd från agenten kan skriva över diskblock där dina data fortfarande kan finnas lagrade.

1. Stäng agentens terminal

   Avbryt det farliga kommandot omedelbart med Ctrl+C; vänta inte tills raderingen är klar. Agentstopp stoppar inte nödvändigtvis barnkommandon, fjärrjobb eller databasfrågor. Identifiera faktisk skrivare och stoppa eller avbryt operationen; eskalera avslutet om data fortsätter förstöras. Behåll orelaterade processer med potentiellt återställbara öppna filer.

2. Starta INTE om din bärbara dator

   Raderade data kan gå att återställa, men lagring, databasbeteende, SSD-discard/TRIM och senare skrivningar avgör det. Minimera skrivning till berörd volym; anta inte att byten finns kvar.

3. Stäng INTE öppna processer

   Bevara orelaterade processer som håller raderade filer öppna eftersom återställning kan vara möjlig via deras filbeskrivare. Det gäller inte den destruktiva skrivaren: stoppa den först. Låt inte radering fortsätta bara för att bevara ett öppet handtag.

4. Börja spela in skärmen

   Dokumentera exakt tid, berörda sökvägar och synlig kommandoutdata. Spara inspelning eller loggkopior på en separat verifierad enhet, inte skadad volym. Bevara där överlevande spårade, ospårade och ignorerade filer samt Git-metadata före återställningsförsök.

Därefter har du 6 minuter på dig att återställa. Nu kör vi.

Minut 2–3: dokumentera exakt vad som gick fel#

Öppna ett nytt terminalfönster. Inte det där agenten körs – ett annat. Kör de här tre kommandona i följd.

1. Registrera exakt vad som ändrades i git-databasen:

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

En raderad spårad fil kan finnas i index eller commit. Bevara aktuell arbetskopia, inklusive ospårade och ignorerade filer, före varje restore-operation; återställning på plats kan skriva över kvarvarande ändringar. Granska och återställ i en separat kopia.

2. Kontrollera vilka agentprocesser som körs:

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

Identifiera processen som fortfarande utför farliga skrivningar; ett matchande namn räcker inte. Stoppa skrivaren och verifiera stoppet. Bevara orelaterade processer med användbara öppna filer; om mjukt avslut misslyckas och förstörelsen fortsätter kan tvingat avslut behövas.

3. Spara agentens sessionslogg:

Claude Code lagrar JSONL-sessioner i ~/.claude/projects/. Cursor lagrar sina i ~/.cursor/. Gör en kopia genast:

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

Ersätt /external/incident-evidence/ med en befintlig beläggskatalog på en separat verifierad monterad enhet. Skriv inte kopian till berörd volym och skriv inte över befintliga belägg. Den här mappen innehåller ordagranna konversationer med agenten – vilka kommandon den körde, vad den svarade och i vilken ordning. Det är din huvudsakliga källa för att utreda incidenten och eventuellt återställa raderade filer från dess sammanhang (se steg 4).

Minut 4: git reflog – din bästa chans#

git reflog registrerar lokala referensförflyttningar så länge posterna behålls. Utgång och rensning varierar och oåtkomliga objekt kan tas bort; det är inget garanterat arkiv över varje tidigare commit. Kör återställningsstegen nedan från en bevarad kodförrådskopia på separat enhet.

Steg 1. Visa loggen:

git reflog --all

Du får en lista som denna:

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

Leta efter läget innan agenten orsakade skadan. Varje post är en ”ögonblicksbild” av repositoryts tillstånd vid det tillfället.

Steg 2. Återställ till en separat arbetskopia:

Kör från bevarad kodförrådskopia efter att kodförrådet och allt överlevande arbete kopierats till en separat enhet. Ersätt värdet med exakt commit-SHA som du kontrollerat i reflog och välj oanvänd gren och mål:

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

Granska återställda filer i ../recovery-check och jämför med bevarade oincheckade filer innan något kopieras tillbaka. Kommandot checkar ut vald commit separat; det återställer inte den skadade arbetskopian på plats. Länkade worktrees delar den kopierade Git-objektlagringen, så detta är en återställningsarbetsplats, inte en oberoende säkerhetskopia. Se officiell git-worktree-dokumentation.

Om reflog också har rensats (agenten hann köra git gc):

git fsck --lost-found

Kommandot hittar ”förlorade” commits och blobbar (filobjekt) som inte längre är kopplade till någon gren. De visas i .git/lost-found/commit/ och .git/lost-found/other/. Så här återställer du en fil därifrån:

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

När git reflog inte hjälper:

• Filen fanns bara i arbetskatalogen, utan en commit eller stash → reflog kan inte hitta den
• Mer än 90 dagar har gått (standardvärdet för gc.reflogExpire) och git gc har körts
• Hela repositoryt raderades (rm -rf .git) – då behöver du Time Machine eller en ögonblicksbild

Minut 5: återställ databasen från en säkerhetskopia#

Databasen raderades med DROP DATABASE, DROP TABLE eller DELETE FROM ... WHERE ... (utan en WHERE-klausul). Vad ska du göra?

Steg 1. Ta reda på om din leverantör erbjuder PITR:

Steg 2. Återställ till en ny instans, inte den gamla:

Återställ aldrig ovanpå en aktiv databas. Skapa en ny instans från säkerhetskopian och byt sedan till den i applikationen. Om något går fel kan du ändra DNS tillbaka.

Steg 3. Om PITR inte var aktiverat använder du den senaste ögonblicksbilden:

# 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

Varning för Supabase, som överraskade många 2026: när PITR är aktiverat slutar dagliga säkerhetskopior att skapas. Ett kontraintuitivt beteende; du kan stå helt utan säkerhetskopior. Kontrollera Dashboard → Database → Backups för att säkerställa att PITR är aktivt OCH att du har en ögonblicksbild att återställa från.

Minut 6: Time Machine, lsof och diskögonblicksbilder#

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 skapar ögonblicksbilder varje timme, behåller ögonblicksbilder per timme i en dag, per dag i en vecka och per vecka på obestämd tid. Om din bärbara dator är ansluten till en Time Capsule eller extern disk finns projektet där med upplösning per timme.

Linux – filen raderades, men en process har den fortfarande öppen:

# 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

Chansen att lyckas är ~95 % om processen inte stängdes. Fungerar på ext4, xfs, btrfs.

macOS – motsvarande med lsof:

lsof | grep deleted

Det är svårare att kopiera filen (det finns ingen /proc/), men det går att göra med lldb:

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

Ögonblicksbild av hela disken (Linux, sista utvägen):

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

Det sparar hela partitionen som en avbild. Återställ sedan med extundelete eller photorec. Chansen att återställa beror på hur mycket som har skrivits till disken sedan raderingen. Om inget har skrivits är den 80–90 %. Om systemet redan har körts i en timme är den 20–30 %.

Minut 7: vad gör du om det inte finns någon säkerhetskopia#

Alternativ 1 – leverantörens support:

AWS, Yandex Cloud, Google Cloud och DigitalOcean återställer periodvis data från sin interna lagring, även efter en kundkatastrof, särskilt för betalplaner. Öppna ett supportärende, ange den exakta tidpunkten för incidenten och bifoga skärmbilder av läget. Det fungerar oftast hos stora leverantörer som behåller automatiska säkerhetskopior på sin sida. Chansen är 40–60 %; svarstiden är 24–72 timmar.

Alternativ 2 – S3-versionering:

Om filerna låg i S3 (eller Yandex Object Storage) och versionering var aktiverad finns alla versioner fysiskt kvar; de är bara markerade som ”raderade”.

# 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

Viktig varning: Claude Code sparar inte sessioner för alltid – gamla JSONL-filer raderas automatiskt efter flera veckor. För att säkerställa att du har en månads JSONL-historik vid en katastrof kopierar du ~/.claude/projects/ till en extern disk en gång i veckan med ett enkelt cronjobb:

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

Det är gratis och räddar dig när ”allt är borta, det finns ingen säkerhetskopia och reflog är tom”.

7 regler för att säkerställa att detta aldrig händer igen#

1. Plan Mode före alla destruktiva åtgärder. I Claude Code:

claude --plan

Agenten skapar en plan innan den agerar. Du läser den, ser DROP TABLE users och avbryter. Utan Plan Mode bestämmer agenten själv och kör kommandon på några millisekunder. Läs mer i guiden till Plan Mode i Claude Code.

2. Hooks som extra varningssnubbeltråd. Använd en testad PreToolUse-hook som läser händelsens JSON från stdin och ger avslutskod 2 för identifierad högriskåtgärd. Det fullständiga exemplet nedan täcker Bash, Write och Edit; det är ingen säkerhetsgräns och kan missa indirekta operationer. Behåll begränsade databasrättigheter och sandbox.

Viktig varning: Hooks med exit code 1 blockerar INTE körningen. Du behöver exakt exit 2 eller JSON med permissionDecision: "deny". Detta dokumenteras i den officiella dokumentationen för hooks, men 90 % av exemplen på nätet använder exit 1 och fungerar inte.

Läs mer om konfiguration i guiden Hooks i Claude Code 2026.

3. Skrivskyddad DB-användare för agenten. Skapa en separat användare för agenten som inte har behörighet för DROP, TRUNCATE eller DELETE:

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;

När agenten verkligen behöver skriva byter du manuellt till en annan användare. En skrivskyddad användare räcker för vardagliga uppgifter (dataanalys, rapporter, instrumentpaneler).

4. Spara granskade ändringar i Git. En PostToolUse-hook i .claude/settings.json kan visa en påminnelse efter Write och Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Granska diffen och committa bara de överenskomna filerna manuellt.' >&2"
          }
        ]
      }
    ]
  }
}

Exemplet visar bara en påminnelse; det lägger inte till filer i staging och skapar inga commits. Granska diffen och committa bara de överenskomna filerna manuellt. Reflog sparar inte ändringar som inte har committats.

5. Sandlådeprojekt för experiment. Låt aldrig agenten arbeta i ett projekt som innehåller riktiga kunddata. Skapa en separat mapp ~/sandbox-projects/ med en kopia av projektet och syntetiska data. Använd den för att prova en ny prompt, agent eller MCP-server. Om något går sönder skadas inget.

6. Diskögonblicksbilder med restic varje timme.

# 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

Sju dagars säkerhetskopior per timme, fyra veckors dagliga säkerhetskopior – och du kan alltid återgå till vilken tidpunkt som helst i det förflutna. Det är gratis och tar 10 minuter att konfigurera.

7. Arkivera Claude Code JSONL-sessioner. Detta nämndes redan ovan, men upprepas som en separat regel: schemalägg en veckovis rsync av ~/.claude/projects/ till en extern disk. Det är gratis och kräver en rad i crontab.

Färdiga hooks för att blockera farliga kommandon#

Slå samman denna post med .claude/settings.json utan att ersätta befintliga hooks:

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

Skapa .claude/hooks/check-risk.py med följande 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)

Hooken läser dokumenterad JSON-händelse från stdin, kontrollerar tool_input.command eller tool_input.file_path och ger avslutskod 2 vid träff. Den kontrollerar både Write och Edit. Testa en ofarlig tillåten fixtur och en blockerad fixtur före användning och verifiera att Python och konfigurerat skript faktiskt startar.

Det är en lexikal snubbeltråd: den kan missa omordnade flaggor, skript, alias, förvrängda kommandon, andra verktyg och indirekta skrivningar; den kan även avvisa ofarliga citerade exempel. Den ger eller tar inte bort OS-/databasbehörigheter. Håll produktionsuppgifter utanför agentmiljön, använd skrivskyddad databasroll och upprätthållen sandbox och skydda hookkonfigurationen från ändring. Se officiell referens för hook-indata och returkoder.

Granska avsiktliga undantagsoperationer och kör dem utanför agenten med lämpligt begränsat konto. En skalmiljövariabel är inget dokumenterat gränssnitt för att stänga av hooks och hooks styr inte vanliga terminalkommandon.

När du ska ge AI behörigheter (och när inte)#

Anthropic dokumenterar flaggan --dangerously-skip-permissions (även kallad YOLO-läge) som ett alternativ för ”betrodda miljöer”. I verkligheten 2026 är den en direkt väg till en katastrof. När agenten inte behöver fråga:

• Kör den alla Bash-kommandon utan bekräftelse
• Skriver den filer utan att fråga
• Kan den anropa en underagent, som ärver YOLO utan möjlighet att ta bort det

Den tredje punkten är mest förrädisk. Om du startar huvudagenten med YOLO använder även dess underagenter YOLO, och du kan inte åsidosätta det. En prompt – och en kedja av 10 parallella agenter kan göra vad som helst med ditt system.

Regel:

Alternativ – precisa behörigheter. I .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/*)"
    ]
  }
}

Agenten ser vad som är tillåtet och inte. Du behöver inte klicka på ”ja” eller ”nej” varje gång – agenten arbetar snabbt, och du styr gränsen.

Nästa steg: en 7-minuterschecklista att spara som bokmärke#

Checklista: ”AI raderade det – vad gör jag?”

1. Stoppa faktisk destruktiv skrivare omedelbart; verifiera att barn- eller fjärroperationer stoppats
2. Starta inte om; bevara orelaterade processer som håller raderade filer öppna
3. Dokumentera incidenttid och kommandobelägg på separat verifierad enhet
4. Kopiera överlevande filer, Git-metadata och relevanta sessionsloggar till den separata enheten
5. Granska git reflog --all i bevarad kodförrådskopia och återställ verifierad commit till separat worktree
6. Om git inte hjälpte – git fsck --lost-found
7. Databas: PITR (AWS/Yandex/Supabase) eller senaste ögonblicksbild
8. Filer: Time Machine på Mac, lsof på Linux
9. Sista utvägen: leverantörssupport + S3-versionering
10. Efter återställningen konfigurerar du de 7 förebyggande reglerna i den här guiden

Nästa steg – systematiskt skydd:

• Plan Mode i Claude Code – så att agenten skapar en plan före en destruktiv åtgärd
• Hooks i Claude Code – färdiga mallar för att blockera farliga kommandon
• Så återställer du ändringar i Claude Code – en detaljerad guide till /rewind, git och 5 vanliga metoder för återställning
• Säkerhetsgranskning i Claude Code – regelbundna säkerhetskontroller av kod

Öppna Ailoot.