AI slettet databasen: en gjenopprettingsplan på 7 minutter

Praktisk informasjon om hvordan du jobber med Ailoot, finner du i dokumentasjonen.

Hva du gjør det første minuttet: STOPP, ikke få panikk#

Hvis dette skjer med deg, er det første du må gjøre å stoppe agenten. Ikke prøv å angre handlingene selv, ikke be den om å «gjenopprette alt», og ikke kjør nye forespørsler. Hver etterfølgende handling fra agenten kan overskrive diskblokkene der dataene dine kanskje fortsatt ligger lagret.

1. Lukk agentens terminal

   Avbryt farlig kommando umiddelbart med Ctrl+C; ikke vent til sletting er ferdig. Agentstopp stanser ikke nødvendigvis barnekommandoer, eksterne jobber eller databasespørringer. Identifiser faktisk skriver og stopp eller avbryt operasjonen. Eskaler avslutning hvis den fortsetter å ødelegge data. Hold uvedkommende prosesser med mulig gjenopprettbare åpne filer i live.

2. IKKE start den bærbare PC-en på nytt

   Slettede data kan være gjenopprettbare, men lagring, databaseatferd, SSD-discard/TRIM og senere skriving avgjør. Minimer skriving til berørt volum; ikke anta at byte fortsatt finnes.

3. IKKE lukk åpne prosesser

   Bevar uvedkommende prosesser med slettede filer åpne, fordi gjenoppretting via filbeskrivere kan være mulig. Dette gjelder ikke den destruktive skriveren: Stopp den først. Ikke la sletting fortsette bare for å bevare et åpent filhåndtak.

4. Start skjermopptak

   Registrer eksakt tidspunkt, berørte baner og synlig kommandoutdata. Lagre opptak eller kopierte logger på en separat verifisert enhet fremfor skadd volum. Bevar overlevende sporede, usporede og ignorerte filer samt Git-metadata der før gjenoppretting.

Deretter har du 6 minutter på å gjenopprette dataene. Sett i gang.

Minutt 2–3: dokumenter nøyaktig hva som gikk galt#

Åpne et nytt terminalvindu. Ikke det agenten kjører i — et annet. Kjør disse tre kommandoene etter hverandre.

1. Registrer nøyaktig hva som ble endret i git-repositoriet:

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

En slettet sporet fil kan fortsatt finnes i indeks eller commit. Bevar arbeidsområdet, inkludert usporede og ignorerte filer, før restore-operasjon. Gjenoppretting på stedet kan overskrive overlevende endringer. Undersøk og gjenopprett i en separat kopi.

2. Sjekk hvilke agentprosesser som kjører:

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

Identifiser prosessen som fortsatt gjør farlig skriving. Navnetreff alene er utilstrekkelig. Stopp faktisk skriver og verifiser at den har stoppet. Bevar uvedkommende prosesser med nyttige åpne filer. Hvis grasiøs avslutning feiler og ødeleggelsen fortsetter, kan tvungen avslutning være nødvendig.

3. Lagre agentens sesjonslogg:

Claude Code lagrer JSONL-sesjoner i ~/.claude/projects/. Cursor lagrer dem i ~/.cursor/. Lag en kopi med en gang:

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

Erstatt /external/incident-evidence/ med en eksisterende beleggmappe på en separat verifisert montert enhet. Ikke skriv sikkerhetskopi på berørt volum eller overskriv eksisterende belegg. Denne mappen inneholder hele samtalen med agenten ordrett — hvilke kommandoer den kjørte, hva den svarte og i hvilken rekkefølge. Dette er hovedkilden din når du undersøker hendelsen og eventuelt gjenoppretter slettede filer fra agentens kontekst (se trinn 4).

Minutt 4: git reflog — den beste sjansen din#

git reflog registrerer lokale referansebevegelser mens oppføringene beholdes. Utløp og rydding varierer, og utilgjengelige objekter kan fjernes. Det er ikke et garantert arkiv over alle gamle commits. Kjør gjenoppretting fra en bevart repositorykopi på separat enhet.

Trinn 1. Vis loggen:

git reflog --all

Du får en liste som 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 etter tilstanden før agenten forårsaket skaden. Hver oppføring er et «øyeblikksbilde» av tilstanden til repositoriet på det tidspunktet.

Trinn 2. Gjenopprett i et separat arbeidsområde:

Etter kopiering av repository og alt overlevende arbeid til separat enhet kjører du dette fra bevart repositorykopi. Erstatt verdien med eksakt commit-SHA kontrollert i reflog, og velg ubrukt gren og mål:

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

Undersøk gjenopprettede filer i ../recovery-check og sammenlign med bevarte ucommittede filer før noe kopieres tilbake. Kommandoen sjekker valgt commit ut separat og tilbakestiller ikke skadd arbeidsområde. Lenkede worktrees deler den kopierte repositoryets Git-objektlager, så dette er et gjenopprettingsarbeidsområde, ikke uavhengig sikkerhetskopi. Se offisiell git-worktree-dokumentasjon.

Hvis reflog også er ryddet (agenten rakk å kjøre git gc):

git fsck --lost-found

Denne kommandoen finner «tapte» commits og blobs (filobjekter) som ikke lenger er knyttet til noen branch. De vises i .git/lost-found/commit/ og .git/lost-found/other/. Slik gjenoppretter du en fil derfra:

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

Når git reflog ikke hjelper:

• Filen lå bare i arbeidstreet, uten commit eller stash → reflog kan ikke finne den
• Det har gått mer enn 90 dager (standardinnstillingen for gc.reflogExpire) og git gc ble kjørt
• Hele repositoriet ble slettet (rm -rf .git) — da trenger du Time Machine eller et øyeblikksbilde

Minutt 5: gjenopprett databasen fra en sikkerhetskopi#

Databasen ble slettet med DROP DATABASE, DROP TABLE eller DELETE FROM ... WHERE ... (uten en WHERE-klausul). Hva bør du gjøre?

Trinn 1. Finn ut om leverandøren din tilbyr PITR:

Trinn 2. Gjenopprett til en ny instans, ikke den gamle:

Gjenopprett aldri oppå en database som er i drift. Opprett en ny instans fra sikkerhetskopien, og bytt deretter applikasjonen over til den. Hvis noe går galt, kan du endre DNS tilbake.

Trinn 3. Hvis PITR ikke var slått på, bruker du det nyeste øyeblikksbildet:

# AWS RDS, vis øyeblikksbilder:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Gjenopprett fra et øyeblikksbilde:
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 om Supabase, som overrasket mange i 2026: Når PITR er slått på, slutter daglige sikkerhetskopier å bli opprettet. Dette er kontraintuitivt; du kan ende opp uten sikkerhetskopier i det hele tatt. Sjekk Dashboard → Database → Backups for å sikre at PITR er aktivt OG at du har et øyeblikksbilde å gjenopprette fra.

Minutt 6: Time Machine, lsof og øyeblikksbilder av disken#

macOS — Time Machine:

# Vis øyeblikksbilder:
tmutil listbackups

# Gjenopprett en fil fra den nyeste sikkerhetskopien:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine lager øyeblikksbilder hver time, beholder timebaserte øyeblikksbilder i ett døgn, daglige øyeblikksbilder i én uke og ukentlige øyeblikksbilder på ubestemt tid. Hvis den bærbare PC-en er koblet til en Time Capsule eller en ekstern disk, finnes prosjektet ditt der med timebasert oppløsning.

Linux — filen er slettet, men en prosess har den fortsatt åpen:

# Finn alle «slettede» filer som en prosess fortsatt har åpne:
sudo lsof | grep deleted

# Du får linjer som dette:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Kopier filen direkte fra /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Sannsynligheten for å lykkes er ~95 % hvis prosessen ikke ble lukket. Fungerer på ext4, xfs og btrfs.

macOS — tilsvarende med lsof:

lsof | grep deleted

Det er vanskeligere å kopiere filen (det finnes ingen /proc/), men du kan gjøre det med lldb:

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

Øyeblikksbilde av hele disken (Linux, siste utvei):

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

Dette lagrer hele partisjonen som en avbildning. Gjenopprett deretter med extundelete eller photorec. Sannsynligheten for å lykkes avhenger av hvor mye som er skrevet til disken siden slettingen. Hvis ingenting er skrevet, er den 80–90 %. Hvis disken allerede har vært i bruk i en time, er den 20–30 %.

Minutt 7: hva om det ikke finnes noen sikkerhetskopi#

Alternativ 1 — brukerstøtte hos leverandøren:

AWS, Yandex Cloud, Google Cloud og DigitalOcean gjenoppretter med jevne mellomrom data fra sin interne lagring, også etter en kundekatastrofe, særlig på betalte abonnementer. Opprett en supportsak, oppgi det nøyaktige tidspunktet for hendelsen og legg ved skjermbilder av situasjonen. Dette lykkes oftest hos store leverandører som har automatiske sikkerhetskopier på sin side. Sjansen er 40–60 %; responstiden er 24–72 timer.

Alternativ 2 — S3-versjonering:

Hvis filene lå i S3 (eller Yandex Object Storage) og versjonering var slått på, finnes alle versjonene fysisk; de er bare merket som «slettet».

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

# Gjenopprett en versjon:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Viktig forbehold: Claude Code beholder ikke sesjoner for alltid — gamle JSONL-filer slettes automatisk etter flere uker. For å sikre at du har én måneds JSONL-historikk i tilfelle en katastrofe, kopierer du ~/.claude/projects/ til en ekstern disk én gang i uken med en enkel cron-jobb:

# I crontab, hver søndag kl. 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Det er gratis og redder deg når «alt er borte, det finnes ingen sikkerhetskopi, og reflog er tom».

7 regler for å sørge for at dette aldri skjer igjen#

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

claude --plan

Agenten lager en plan før den handler. Du leser den, ser DROP TABLE users og avbryter. Uten Plan Mode bestemmer agenten selv og utfører handlingen på millisekunder. Les mer i veiledningen om Plan Mode i Claude Code.

2. Hooks som ekstra snubletråd. Bruk en testet PreToolUse-hook som leser hendelses-JSON fra stdin og avslutter med 2 ved oppdaget høyrisikohandling. Det komplette eksemplet nedenfor dekker Bash, Write og Edit. Det er ingen sikkerhetsgrense og kan overse indirekte operasjoner. Behold restriktive databasetillatelser og sandbox.

3. Skrivebeskyttet DB-bruker for agenten. Opprett en separat bruker for agenten som ikke har rettighetene 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;

Bytt manuelt til en annen bruker når agenten faktisk trenger å skrive. En skrivebeskyttet bruker er tilstrekkelig for daglige oppgaver som dataanalyse, rapporter og dashbord.

4. Lagre gjennomgåtte endringer i Git. En PostToolUse-hook i .claude/settings.json kan skrive en påminnelse etter Write og Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Se gjennom diffen og commit bare de avtalte filene manuelt.' >&2"
          }
        ]
      }
    ]
  }
}

Eksemplet skriver bare en påminnelse; det legger ikke filer i staging og oppretter ikke commits. Se gjennom diffen og commit bare de avtalte filene manuelt. Reflog lagrer ikke endringer som ikke er committet.

5. Sandbox-prosjekt for eksperimenter. La aldri agenten arbeide i et prosjekt som inneholder ekte kundedata. Opprett en separat mappe ~/sandbox-projects/ med en kopi av prosjektet og syntetiske data. Bruk den til å prøve en ny prompt, agent eller MCP-server. Hvis noe går galt, er det ingen skade skjedd.

6. Disk-snapshots med restic hver time.

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

# Opprett et repositorium:
restic init --repo /external/backups

# Ta sikkerhetskopi av det gjeldende prosjektet:
restic --repo /external/backups backup ~/projects

# Planlegg cron hver time:
crontab -e
# Legg til:
0 * * * * restic --repo /external/backups backup ~/projects

Sju dager med timebaserte sikkerhetskopier, fire uker med daglige sikkerhetskopier — og du kan alltid gå tilbake til et hvilket som helst punkt i fortiden. Det er gratis og tar 10 minutter å sette opp.

7. Arkiver Claude Code JSONL-sesjoner. Dette er allerede nevnt ovenfor, men gjentas som en egen regel: Planlegg en ukentlig rsync av ~/.claude/projects/ til en ekstern disk. Det er gratis og krever én linje i crontab.

Ferdige hooks for å blokkere farlige kommandoer#

Slå denne oppføringen sammen med .claude/settings.json uten å erstatte eksisterende hooks:

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

Opprett .claude/hooks/check-risk.py med dette Python 3-skriptet:

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 leser dokumentert JSON-hendelse fra stdin, kontrollerer tool_input.command eller tool_input.file_path og avslutter med 2 ved treff. Den sjekker både Write og Edit. Test en ufarlig tillatt og en blokkert testhendelse før du stoler på den, og verifiser at Python og konfigurert skript faktisk starter.

Dette er en leksikalsk snubletråd. Den kan overse omordnede flagg, skript, aliaser, tilslørte kommandoer, andre verktøy og indirekte skriving, og kan avvise ufarlige siterte eksempler. Den gir eller fjerner ikke OS-/databasetillatelser. Hold produksjonstilganger utenfor agentmiljøet, bruk skrivebeskyttet databaserolle og håndhevet sandbox, og beskytt hook-konfigurasjonen mot endring. Se offisiell referanse for hook-inndata og avslutningskoder.

For en bevisst unntaksoperasjon gjennomgår du den og kjører utenfor agenten med riktig begrenset konto. En shell-miljøvariabel er ingen dokumentert hook-avkobling, og hooks styrer ikke vanlige terminalkommandoer.

Når du bør gi AI tillatelser (og når du ikke bør det)#

Anthropic dokumenterer flagget --dangerously-skip-permissions (også kjent som YOLO-modus) som et alternativ for «betrodde miljøer». I 2026 er det en direkte vei til en katastrofe. Når agenten ikke må spørre, kan den:

• Kjøre enhver Bash-kommando uten bekreftelse
• Skrive filer uten å spørre
• Kalle opp en underagent, som arver YOLO uten mulighet til å oppheve det

Det tredje punktet er det mest lumske. Hvis du starter hovedagenten med YOLO, kjører også underagentene dens YOLO, og du kan ikke overstyre det. Én prompt — og en kjede av 10 parallelle agenter kan gjøre hva som helst med systemet ditt.

Regel:

Alternativ — presise tillatelser. 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 hva som er tillatt og ikke. Du trenger ikke klikke «ja» eller «nei» hver gang — agenten arbeider raskt, og du kontrollerer grensene.

Neste: en 7-minutters sjekkliste du kan bokmerke#

Sjekkliste: «AI slettet det — hva gjør jeg?»

1. Stopp faktisk destruktiv skriver umiddelbart; verifiser stopp av barn og eksterne operasjoner
2. Ikke start på nytt; bevar uvedkommende prosesser som holder slettede filer åpne
3. Registrer hendelsestid og kommandobelegg på separat verifisert enhet
4. Kopier overlevende filer, Git-metadata og relevante øktlogger til den separate enheten
5. Undersøk git reflog --all i bevart repositorykopi og gjenopprett verifisert commit i separat worktree
6. Hvis git ikke hjalp — git fsck --lost-found
7. Database: PITR (AWS/Yandex/Supabase) eller nyeste øyeblikksbilde
8. Filer: Time Machine på Mac, lsof på Linux
9. Siste utvei: leverandørstøtte + S3-versjonering
10. Etter gjenoppretting konfigurerer du de 7 forebyggende reglene i denne veiledningen

Neste steg — systematisk beskyttelse:

• Plan Mode i Claude Code — slik at agenten lager en plan før en destruktiv handling
• Hooks i Claude Code — ferdige maler som blokkerer farlige kommandoer
• Slik ruller du tilbake endringer i Claude Code — en detaljert veiledning til /rewind, git og 5 vanlige metoder for tilbakestilling
• Sikkerhetsgjennomgang i Claude Code — regelmessige sikkerhetskontroller av kode

Åpne Ailoot.