AI slettede databasen: en gendannelsesplan på 7 minutter

Praktisk information om at arbejde med Ailoot findes i dokumentationen.

Hvad du skal gøre i det første minut: STOP, gå ikke i panik#

Når det sker for dig, er det første, du skal gøre, at stoppe agenten. Forsøg ikke selv at fortryde dens handlinger, bed den ikke om at ”gendanne alt”, og kør ikke nye prompts. Hver efterfølgende handling fra agenten kan overskrive de diskblokke, hvor dine data muligvis stadig er lagret.

1. Luk agentens terminal

   Afbryd den farlige kommando straks med Ctrl+C; vent ikke på, at sletningen bliver færdig. Agentstop stopper ikke nødvendigvis underkommandoer, fjernjobs eller databaseforespørgsler. Identificér den faktiske skriver, og stop eller annullér handlingen; eskalér afslutning, hvis den fortsætter dataødelæggelsen. Bevar uvedkommende processer med muligvis gendannelige åbne filer.

2. Genstart IKKE din bærbare computer

   Slettede data kan være gendannelige, men lager, databaseadfærd, SSD-discard/TRIM og efterfølgende skrivninger afgør det. Minimér skrivning på berørt volumen; antag ikke, at bytene stadig findes.

3. Luk IKKE åbne processer

   Bevar uvedkommende processer, der holder slettede filer åbne, fordi gendannelse gennem deres filbeskrivelser kan være mulig. Det gælder ikke den destruktive skriver: Stop den først. Lad ikke sletning fortsætte for at bevare et åbent filhåndtag.

4. Start en skærmoptagelse

   Registrér præcist tidspunkt, berørte stier og synligt kommandooutput. Gem optagelse eller kopierede logs på en separat verificeret enhed frem for den beskadigede volumen. Bevar overlevende sporede, usporede og ignorerede filer samt Git-metadata dér før gendannelsesforsøg.

Dernæst har du 6 minutter til at gendanne dataene. Lad os komme i gang.

Minut 2–3: dokumentér præcis, hvad der gik galt#

Åbn et nyt terminalvindue. Ikke det, hvor agenten kører – et andet. Kør disse tre kommandoer i rækkefølge.

1. Registrér præcis, hvad der ændrede sig i git-repositoriet:

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

En slettet sporet fil kan stadig findes i indekset eller et commit. Bevar aktuelt arbejdstræ inklusive usporede og ignorerede filer før enhver gendannelse; gendannelse på stedet kan overskrive overlevende ændringer. Undersøg og gendan i en separat kopi.

2. Kontrollér, hvilke agentprocesser der kører:

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

Identificér, hvilken proces der stadig udfører farlige skrivninger; et navnematch alene er utilstrækkeligt. Stop skriveren, og verificér, at den er stoppet. Bevar uvedkommende processer med nyttige åbne filer; tvungen afslutning kan være nødvendig, hvis skånsom afslutning fejler, og ødelæggelsen fortsætter.

3. Gem agentens sessionslog:

Claude Code gemmer JSONL-sessioner i ~/.claude/projects/. Cursor gemmer dem i ~/.cursor/. Lav en kopi med det samme:

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

Erstat /external/incident-evidence/ med en eksisterende evidensmappe på en separat verificeret monteret enhed. Skriv ikke backup på berørt volumen, og overskriv ikke eksisterende evidens. Denne mappe indeholder den ordrette samtale med agenten – hvilke kommandoer den kørte, hvad den svarede, og i hvilken rækkefølge. Det er din vigtigste kilde til at undersøge hændelsen og eventuelt gendanne slettede filer fra dens kontekst (se trin 4).

Minut 4: git reflog – din bedste chance#

git reflog registrerer lokale referenceflytninger, mens posterne bevares. Udløb og oprydning varierer, og utilgængelige objekter kan fjernes; det er ikke et garanteret arkiv over ethvert tidligere commit. Kør gendannelsestrinene nedenfor fra en bevaret repositorykopi på den separate enhed.

Trin 1. Vis loggen:

git reflog --all

Du får en liste, der ligner denne:

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

Se efter tilstanden før agenten forårsagede skaden. Hver post er et ”snapshot” af repositoryts tilstand på det tidspunkt.

Trin 2. Gendan i et separat arbejdstræ:

Kør dette fra den bevarede repositorykopi efter kopiering af repository og alt overlevende arbejde til en separat enhed. Erstat værdien med præcis den commit-SHA, du kontrollerede i reflog, og vælg en ubrugt gren og destination:

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

Undersøg de gendannede filer i ../recovery-check, og sammenlign med bevarede ændringer uden commit, før noget kopieres tilbage. Kommandoen checker valgt commit ud separat; den nulstiller ikke det beskadigede arbejdstræ. Forbundne worktrees deler repositorykopiens Git-objektlager, så dette er et gendannelsesarbejdsområde, ikke en uafhængig backup. Se officiel git-worktree-dokumentation.

Hvis reflog også er blevet ryddet (agenten nåede at køre git gc):

git fsck --lost-found

Denne kommando finder ”mistede” commits og blobs (filobjekter), som ikke længere er knyttet til en gren. De vises i .git/lost-found/commit/ og .git/lost-found/other/. Sådan gendanner du en fil derfra:

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

Når git reflog ikke hjælper:

• Filen fandtes kun i arbejdstræet uden et commit eller stash → reflog kan ikke finde den
• Der er gået mere end 90 dage (standardværdien for gc.reflogExpire), og git gc er blevet kørt
• Hele repositoryt blev slettet (rm -rf .git) – så skal du bruge Time Machine eller et snapshot

Minut 5: gendan databasen fra en sikkerhedskopi#

Databasen blev slettet med DROP DATABASE, DROP TABLE eller DELETE FROM ... WHERE ... (uden en WHERE-klausul). Hvad skal du gøre?

Trin 1. Find ud af, om din udbyder tilbyder PITR:

Trin 2. Gendan til en ny instans, ikke den gamle:

Gendan aldrig oven på en aktiv database. Opret en ny instans fra sikkerhedskopien, og skift derefter applikationen til den. Hvis noget går galt, kan du ændre DNS tilbage.

Trin 3. Hvis PITR ikke var aktiveret, skal du bruge det seneste 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

Forbehold ved Supabase, som overraskede mange i 2026: Når PITR er aktiveret, oprettes der ikke længere daglige sikkerhedskopier. Det er kontraintuitivt; du kan ende helt uden sikkerhedskopier. Kontrollér Dashboard → Database → Backups for at sikre, at PITR er aktivt, OG at du har et snapshot at gendanne fra.

Minut 6: Time Machine, lsof og disksnapshots#

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 opretter snapshots hver time, beholder timebaserede snapshots i en dag, daglige snapshots i en uge og ugentlige snapshots på ubestemt tid. Hvis din bærbare computer er tilsluttet en Time Capsule eller en ekstern disk, ligger dit projekt der med en opløsning på én time.

Linux – filen blev slettet, men en proces har den stadig åben:

# 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

Chancen for succes er ~95 %, hvis processen ikke blev lukket. Fungerer på ext4, xfs, btrfs.

macOS – tilsvarende med lsof:

lsof | grep deleted

Det er sværere at kopiere filen (der findes ingen /proc/), men det kan gøres med lldb:

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

Snapshot af hele disken (Linux, sidste udvej):

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

Dette gemmer hele partitionen som et image. Gendan derefter med extundelete eller photorec. Chancen for gendannelse afhænger af, hvor meget der er blevet skrevet til disken siden sletningen. Hvis der ikke er blevet skrevet noget, er den 80–90 %. Hvis systemet allerede har kørt i en time, er den 20–30 %.

Minut 7: hvad hvis der ikke findes nogen sikkerhedskopi#

Mulighed 1 – udbydersupport:

AWS, Yandex Cloud, Google Cloud og DigitalOcean gendanner med mellemrum data fra deres interne lagring, selv efter en kundekatastrofe, især på betalte abonnementer. Opret en supportsag, angiv det præcise tidspunkt for hændelsen, og vedlæg skærmbilleder af tilstanden. Dette virker oftest hos store udbydere, der opbevarer automatiske sikkerhedskopier hos sig selv. Chancen er 40–60 %; svartiden er 24–72 timer.

Mulighed 2 – S3-versionering:

Hvis filerne lå i S3 (eller Yandex Object Storage), og versionering var aktiveret, findes alle versioner fysisk stadig; de er blot markeret som ”slettet”.

# 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

Vigtigt forbehold: Claude Code gemmer ikke sessioner for evigt – gamle JSONL-filer slettes automatisk efter flere uger. For at sikre, at du har en måneds JSONL-historik i tilfælde af en katastrofe, skal du kopiere ~/.claude/projects/ til en ekstern disk én gang om ugen med et simpelt cronjob:

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

Det er gratis og redder dig, når ”alt er væk, der er ingen sikkerhedskopi, og reflog er tom”.

7 regler, der sikrer, at dette aldrig sker igen#

1. Plan Mode før enhver destruktiv handling. I Claude Code:

claude --plan

Agenten udarbejder en plan før den handler. Du læser den, ser DROP TABLE users og annullerer. Uden Plan Mode bestemmer agenten selv og udfører handlingen på få millisekunder. Læs mere i guiden til Plan Mode i Claude Code.

2. Hooks som en ekstra kontrol. Brug en testet PreToolUse-hook, der læser hændelsens JSON fra stdin og afslutter med 2 ved en fundet højrisikohandling. Det komplette eksempel nedenfor dækker Bash, Write og Edit; det er ikke en sikkerhedsgrænse og kan overse indirekte handlinger. Behold begrænsede databaserettigheder og sandbox.

3. Skrivebeskyttet DB-bruger til agenten. Opret en separat bruger til agenten, der ikke har tilladelserne 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 virkelig har brug for at skrive, skifter du manuelt til en anden bruger. En skrivebeskyttet bruger er tilstrækkelig til daglige opgaver (dataanalyse, rapporter, dashboards).

4. Gem gennemgåede ændringer i Git. En PostToolUse-hook i .claude/settings.json kan vise en påmindelse efter Write og Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Gennemgå diff, og commit kun de aftalte filer manuelt.' >&2"
          }
        ]
      }
    ]
  }
}

Eksemplet viser kun en påmindelse; det tilføjer ikke filer til staging og opretter ikke commits. Gennemgå diff, og commit kun de aftalte filer manuelt. Reflog gemmer ikke ændringer, der ikke er committet.

5. Sandkasseprojekt til eksperimenter. Lad aldrig agenten arbejde i et projekt, der indeholder rigtige kundedata. Opret en separat mappe ~/sandbox-projects/ med en kopi af projektet og syntetiske data. Brug den til at afprøve en ny prompt, agent eller MCP-server. Hvis noget går galt, sker der ingen skade.

6. Disksnapshots med restic hver time.

# 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

Syv dages sikkerhedskopier hver time, fire ugers daglige sikkerhedskopier – og du kan altid rulle tilbage til et hvilket som helst tidspunkt i fortiden. Det er gratis og tager 10 minutter at sætte op.

7. Arkivér Claude Code JSONL-sessioner. Det er allerede nævnt ovenfor, men gentages som en separat regel: planlæg en ugentlig rsync af ~/.claude/projects/ til en ekstern disk. Det er gratis og kræver én linje i crontab.

Færdige hooks til at blokere farlige kommandoer#

Flet denne post ind i .claude/settings.json uden at erstatte eksisterende hooks:

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

Opret .claude/hooks/check-risk.py med følgende Python 3-script:

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 den dokumenterede JSON-hændelse fra stdin, undersøger tool_input.command eller tool_input.file_path og afslutter med 2 ved et match. Den undersøger både Write og Edit. Test en harmløs tilladt fixture og en blokeret fixture før brug, og verificér, at Python og det konfigurerede script faktisk starter.

Det er en leksikalsk kontrol: Den kan overse omordnede flag, scripts, aliaser, slørede kommandoer, andre værktøjer og indirekte skrivninger; den kan også afvise harmløse citerede eksempler. Den giver eller fjerner ikke OS-/databaserettigheder. Hold produktionshemmeligheder uden for agentmiljøet, brug en skrivebeskyttet databaserolle og en håndhævet sandbox, og beskyt hookkonfigurationen mod ændringer. Se officiel reference om hook-input og afslutningskoder.

Gennemgå en tilsigtet undtagelseshandling, og kør den uden for agenten med en passende begrænset konto. En shellmiljøvariabel er ikke en dokumenteret grænseflade til at slå hooks fra, og hooks styrer ikke almindelige terminalkommandoer.

Hvornår du skal give AI tilladelser (og hvornår ikke)#

Anthropic dokumenterer flaget --dangerously-skip-permissions (også kendt som YOLO-tilstand) som en mulighed for ”betroede miljøer”. I virkeligheden i 2026 er det en direkte vej til en katastrofe. Når agenten ikke behøver at spørge, gør den følgende:

• Kører enhver Bash-kommando uden bekræftelse
• Skriver filer uden at spørge
• Kan starte en underagent, som arver YOLO uden mulighed for at ophæve det

Det tredje punkt er det mest lumske. Hvis du starter hovedagenten med YOLO, er dens underagenter også YOLO, og du kan ikke tilsidesætte det. Én prompt – og en kaskade af 10 parallelle agenter kan gøre hvad som helst ved dit system.

Regel:

Alternativ – præcise tilladelser. 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 kan se, hvad der er tilladt og forbudt. Du behøver ikke klikke ”ja” eller ”nej” hver gang – agenten arbejder hurtigt, og du styrer grænserne.

Næste: en 7-minutters tjekliste, du kan bogmærke#

Tjekliste: ”AI slettede det – hvad gør jeg?”

1. Stop straks den faktiske destruktive skriver; verificér, at under- og fjernhandlinger er stoppet
2. Genstart ikke; bevar uvedkommende processer med slettede filer åbne
3. Registrér hændelsestid og kommandoevidens på en separat verificeret enhed
4. Kopiér overlevende filer, Git-metadata og relevante sessionslogs til den separate enhed
5. Undersøg git reflog --all i den bevarede repositorykopi, og gendan et verificeret commit i et separat worktree
6. Hvis git ikke hjalp – git fsck --lost-found
7. Database: PITR (AWS/Yandex/Supabase) eller seneste snapshot
8. Filer: Time Machine på Mac, lsof på Linux
9. Sidste udvej: udbydersupport + S3-versionering
10. Efter gendannelse skal du konfigurere guidens 7 forebyggende regler

Næste – systematisk beskyttelse:

• Plan Mode i Claude Code – så agenten laver en plan før en destruktiv handling
• Hooks i Claude Code – færdige skabeloner til at blokere farlige kommandoer
• Sådan ruller du ændringer tilbage i Claude Code – en detaljeret guide til /rewind, git og 5 standardmetoder til tilbagerulning
• Sikkerhedsgennemgang i Claude Code – regelmæssige sikkerhedskontroller af kode

Åbn Ailoot.