AI je izbrisal podatkovno zbirko: 7-minutni načrt za obnovitev

Praktične informacije o delu z Ailoot so na voljo v dokumentaciji.

Kaj storiti v prvi minuti: USTAVITE SE, brez panike#

Ko se vam to zgodi, najprej ustavite agenta. Ne poskušajte sami razveljaviti njegovih dejanj, ne naročite mu, naj »obnovi vse«, in ne zaženite novih promptov. Vsako nadaljnje dejanje agenta lahko prepiše bloke na disku, kjer so vaši podatki morda še vedno shranjeni.

1. Zaprite agentov terminal

   Nevarni ukaz takoj prekinite s Ctrl+C; ne čakajte konca brisanja. Ustavitev agenta ne ustavi nujno njegovih podrejenih ukazov, oddaljenih opravil ali poizvedb baze. Prepoznajte dejanskega pisca in ustavite ali prekličite to operacijo; če nadaljuje uničevanje, zaustavitev stopnjujte. Nepovezane procese z morda obnovljivimi odprtimi datotekami ohranite.

2. NE zaženite prenosnika znova

   Izbrisani podatki so lahko še obnovljivi, vendar je to odvisno od shrambe, delovanja baze, SSD discard/TRIM in poznejših zapisov. Zmanjšajte pisanje na prizadeti nosilec; ne predpostavljajte, da bajti še obstajajo.

3. NE zapirajte odprtih procesov

   Nepovezane procese z odprtimi izbrisanimi datotekami ohranite, saj je obnova morda mogoča prek njihovih deskriptorjev. To ne velja za destruktivnega pisca: najprej ustavite njega. Brisanja ne pustite teči samo zaradi ohranitve odprte datoteke.

4. Začnite snemati zaslon

   Zabeležite točen čas, prizadete poti in vidni izpis ukaza. Posnetek ali kopije dnevnikov shranite na ločeno preverjeno napravo, ne na poškodovani nosilec. Tam pred obnovo ohranite preživele sledene, nesledene in prezrte datoteke ter metapodatke Git.

Nato imate 6 minut za obnovitev. Začnimo.

2.–3. minuta: natančno dokumentirajte, kaj je šlo narobe#

Odprite novo terminalsko okno. Ne tistega, v katerem deluje agent—odprite drugo. Zaporedoma zaženite te tri ukaze.

1. Natančno zabeležite, kaj se je spremenilo v repozitoriju git:

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

Izbrisana sledena datoteka je lahko še v indeksu ali commitu. Pred vsako obnovo ohranite trenutno delovno drevo, tudi nesledene in prezrte datoteke; obnova na mestu lahko prepiše preživele spremembe. Pregledujte in obnavljajte v ločeni kopiji.

2. Preverite, kateri agentovi procesi se izvajajo:

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

Ugotovite, kateri proces še izvaja nevarne zapise; samo ujemanje imena ne zadošča. Ustavite tega pisca in potrdite zaustavitev. Ohranite nepovezane procese s koristnimi odprtimi datotekami; če običajna zaustavitev ne uspe in se uničevanje nadaljuje, je lahko potrebna prisilna prekinitev.

3. Shranite dnevnik agentove seje:

Claude Code shranjuje seje JSONL v ~/.claude/projects/. Cursor jih shranjuje v ~/.cursor/. Naredite kopijo takoj zdaj:

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

/external/incident-evidence/ nadomestite z obstoječim imenikom dokazov na ločeni preverjeni priklopljeni napravi. Kopije ne pišite na prizadeti nosilec in ne prepisujte obstoječih dokazov. Ta mapa vsebuje dobesedni pogovor z agentom—katere ukaze je izvedel, kaj je odgovoril in v kakšnem vrstnem redu. Je glavni vir za preiskavo incidenta in lahko pomaga tudi pri obnovitvi izbrisanih datotek iz njegovega konteksta (glejte 4. korak).

4. minuta: git reflog—vaša najboljša možnost#

git reflog beleži lokalne premike referenc, dokler so vnosi ohranjeni. Potek in čiščenje se razlikujeta, nedosegljivi objekti se lahko odstranijo; ni zagotovljen arhiv vsakega preteklega commita. Spodnje korake izvajajte iz ohranjene kopije repozitorija na ločeni napravi.

1. korak. Oglejte si dnevnik:

git reflog --all

Dobili boste seznam, podoben temu:

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

Poiščite stanje preden je agent povzročil škodo. Vsak vnos je »posnetek« stanja repozitorija v tistem trenutku.

2. korak. Obnova v ločeno delovno drevo:

Po kopiranju repozitorija in vsega preživelega dela na ločeno napravo to zaženite iz ohranjene kopije repozitorija. Vrednost nadomestite s točnim commit SHA, preverjenim v reflogu, ter izberite neuporabljena vejo in cilj:

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

Preglejte obnovljene datoteke v ../recovery-check in jih pred vračanjem primerjajte z ohranjenimi nepotrjenimi datotekami. Ukaz izbrani commit odpre ločeno; poškodovanega delovnega drevesa ne ponastavi. Povezana delovna drevesa delijo shrambo objektov Git kopiranega repozitorija, zato je to obnovitveno okolje, ne neodvisna varnostna kopija. Glejte uradno dokumentacijo git-worktree.

Če je bil počistjen tudi reflog (agentu je uspelo zagnati git gc):

git fsck --lost-found

Ta ukaz poišče »izgubljene« commite in blobe (objekte datotek), ki niso več povezani z nobeno vejo. Pojavili se bodo v .git/lost-found/commit/ in .git/lost-found/other/. Datoteko od tam obnovite tako:

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

Kdaj git reflog NE pomaga:

• Datoteka je bila samo v delovnem drevesu, brez commita ali stash-a → reflog je ne more zaznati
• Minilo je več kot 90 dni (standardni gc.reflogExpire) in zagnan je bil git gc
• Izbrisan je bil celoten repozitorij (rm -rf .git)—takrat potrebujete Time Machine ali posnetek

5. minuta: obnovite podatkovno zbirko iz varnostne kopije#

Podatkovna zbirka je bila izbrisana z ukazom DROP DATABASE, DROP TABLE ali DELETE FROM ... WHERE ... (brez klavzule WHERE). Kaj storiti?

1. korak. Preverite, ali vaš ponudnik omogoča PITR:

2. korak. Obnovite v nov primerek, ne v starega:

Nikoli ne obnavljajte prek žive podatkovne zbirke. Iz varnostne kopije ustvarite nov primerek, nato pa nanj preusmerite aplikacijo. Če gre kaj narobe, lahko DNS preusmerite nazaj.

3. korak. Če PITR ni bil omogočen, uporabite zadnji posnetek:

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

# Obnovitev iz posnetka:
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

Opozorilo glede Supabase, ki je leta 2026 presenetilo veliko ljudi: ko je omogočen PITR, se dnevne varnostne kopije prenehajo ustvarjati. To je protislovno; na koncu lahko ostanete povsem brez varnostnih kopij. V razdelku Dashboard → Database → Backups preverite, ali je PITR aktiven IN ali imate posnetek za obnovitev.

6. minuta: Time Machine, lsof in posnetki diska#

macOS—Time Machine:

# Seznam posnetkov:
tmutil listbackups

# Obnovitev datoteke iz zadnje varnostne kopije:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine ustvarja posnetke vsako uro, urne posnetke hrani en dan, dnevne en teden, tedenske pa za nedoločen čas. Če je vaš prenosnik povezan s Time Capsule ali zunanjim diskom, je projekt na voljo z urno natančnostjo.

Linux—datoteka je bila izbrisana, vendar jo proces še vedno drži odprto:

# Poiščite vse »izbrisane« datoteke, ki jih proces še vedno drži odprte:
sudo lsof | grep deleted

# Dobili boste vrstice, podobne tej:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Datoteko kopirajte neposredno iz /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Če procesa niste zaprli, je možnost uspeha ~95 %. Deluje v sistemih ext4, xfs in btrfs.

macOS—enakovredno z ukazom lsof:

lsof | grep deleted

Kopiranje datoteke je težje (ni /proc/), vendar ga lahko opravite z lldb:

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

Posnetek celotnega diska (Linux, zadnja možnost):

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

Tako shranite celotno particijo kot sliko. Nato podatke obnovite z extundelete ali photorec. Možnost obnovitve je odvisna od količine podatkov, zapisanih na disk po izbrisu. Če od takrat ni bilo zapisano nič, je možnost 80–90 %. Če sistem deluje že eno uro, je možnost 20–30 %.

7. minuta: kaj če ni varnostne kopije#

1. možnost—podpora ponudnika:

AWS, Yandex Cloud, Google Cloud in DigitalOcean občasno obnovijo podatke iz svojega notranjega pomnilnika, tudi po nesreči pri stranki, zlasti pri plačljivih paketih. Odprite zahtevek za podporo, navedite točen čas incidenta in priložite posnetke zaslona stanja. To najpogosteje uspe pri večjih ponudnikih, ki pri sebi hranijo samodejne varnostne kopije. Možnost je 40–60 %; odzivni čas je 24–72 ur.

2. možnost—različice S3:

Če so bile datoteke v S3 (ali Yandex Object Storage) in je bilo omogočeno različičenje, vse različice fizično obstajajo; označene so le kot »izbrisane«.

# AWS—seznam različic:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Obnovitev različice:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Kritično opozorilo: Claude Code sej ne hrani za vedno—stare datoteke JSONL se samodejno izbrišejo po nekaj tednih. Če želite v primeru nesreče zagotoviti enomesečno zgodovino JSONL, enkrat tedensko s preprostim opravilom cron kopirajte ~/.claude/projects/ na zunanji disk:

# V crontabu, vsako nedeljo ob 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Je brezplačno in vas reši, ko »je vse izgubljeno, ni varnostne kopije, reflog pa je prazen«.

7 pravil, da se to ne bi nikoli več zgodilo#

1. Plan Mode pred vsako destruktivno operacijo. V Claude Code:

claude --plan

Agent pripravi načrt preden ukrepa. Preberete ga, opazite DROP TABLE users in prekličete. Brez načina Plan Mode se agent odloči sam in ukaz izvede v milisekundah. Več preberite v vodniku Plan Mode v Claude Code.

2. Kavlji kot dodatno opozorilno varovalo. Uporabite preizkušen kavelj PreToolUse, ki dogodek JSON bere s standardnega vhoda in ob zaznanem tveganem dejanju vrne 2. Celotni spodnji primer pokriva Bash, Write in Edit; ni varnostna meja in lahko spregleda posredne operacije. Dovoljenja baze in peskovnik ohranite omejena.

Več o konfiguraciji preberite v vodniku Hooks v Claude Code 2026.

3. Uporabnik DB samo za branje za agenta. Ustvarite ločenega uporabnika za agenta, ki nima pravic DROP, TRUNCATE ali 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;

Ko mora agent res pisati, ročno preklopite na drugega uporabnika. Uporabnik samo za branje zadostuje za vsakodnevna opravila (analizo podatkov, poročila, nadzorne plošče).

4. Pregledane spremembe shranite v Git. Hook PostToolUse v .claude/settings.json lahko po operacijah Write in Edit izpiše opomnik:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Preglejte diff in ročno ustvarite commit samo z dogovorjenimi datotekami.' >&2"
          }
        ]
      }
    ]
  }
}

Ta primer samo izpiše opomnik; datotek ne dodaja v indeks in ne ustvarja commitov. Preglejte diff in ročno ustvarite commit samo z dogovorjenimi datotekami. Reflog ne shranjuje sprememb, ki niso bile vključene v commit.

5. Projekt sandbox za poskuse. Agenta nikoli ne pustite delati v projektu, ki vsebuje resnične podatke strank. Ustvarite ločeno mapo ~/sandbox-projects/ s kopijo projekta in sintetičnimi podatki. V njej preizkusite nov prompt, agenta ali strežnik MCP. Če gre kaj narobe, ni škode.

6. Urni posnetki diska z restic.

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

# Ustvarite repozitorij:
restic init --repo /external/backups

# Varnostno kopirajte trenutni projekt:
restic --repo /external/backups backup ~/projects

# Načrtujte opravilo cron vsako uro:
crontab -e
# Dodajte:
0 * * * * restic --repo /external/backups backup ~/projects

Sedem dni urnih varnostnih kopij, štiri tedne dnevnih kopij—in vedno se lahko vrnete na katerokoli točko v preteklosti. Brezplačno je in za nastavitev potrebuje 10 minut.

7. Arhivirajte seje Claude Code JSONL. To smo že omenili, a ponavljamo kot ločeno pravilo: nastavite tedenski rsync mape ~/.claude/projects/ na zunanji disk. Je brezplačno in zahteva eno vrstico v crontabu.

Pripravljeni hooks za blokiranje nevarnih ukazov#

Ta vnos združite z .claude/settings.json, ne da bi zamenjali obstoječe kavlje:

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

Ustvarite .claude/hooks/check-risk.py s tem skriptom Python 3:

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)

Kavelj dokumentirani dogodek JSON bere s standardnega vhoda, preveri tool_input.command ali tool_input.file_path in ob ujemanju vrne izhodno kodo 2. Preverja Write in Edit. Pred zanašanjem nanj preizkusite neškodljiv dovoljeni in blokirani primer ter potrdite dejanski zagon Pythona in nastavljenega skripta.

To je besedilno opozorilno varovalo: lahko spregleda drugačen vrstni red zastavic, skripte, vzdevke, prikrite ukaze, druga orodja in posredne zapise; zavrne lahko tudi neškodljive citirane primere. Ne dodeljuje ali odvzema dovoljenj operacijskega sistema ali baze. Produkcijske poverilnice hranite zunaj agentovega okolja, uporabite podatkovno vlogo samo za branje in uveljavljen peskovnik ter konfiguracijo kavlja zaščitite pred spreminjanjem. Glejte uradni opis vhoda in izhodnih kod kavljev.

Namerno izjemno operacijo preglejte in jo izvedite zunaj agenta z ustreznim omejenim računom. Okoljska spremenljivka lupine ni dokumentiran vmesnik za izklop kavljev, kavlji pa ne upravljajo običajnih terminalskih ukazov.

Kdaj AI podeliti dovoljenja (in kdaj ne)#

Anthropic zastavico --dangerously-skip-permissions (znano tudi kot način YOLO) dokumentira kot možnost za »zaupanja vredna okolja«. V resničnosti leta 2026 je to neposredna pot do katastrofe. Ko agentu ni treba prositi za dovoljenje, lahko:

• Izvede poljuben ukaz Bash brez potrditve
• Zapiše datoteke brez vprašanja
• Zažene podagenta, ki podeduje način YOLO in ga ni mogoče izklopiti

Tretja točka je najbolj zahrbtna. Če glavnega agenta zaženete v načinu YOLO, so tudi njegovi podagenti v tem načinu in tega ne morete preglasiti. En prompt—in veriga 10 vzporednih agentov lahko vašemu sistemu naredi karkoli.

Pravilo:

Alternativa—natančna dovoljenja. V .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/*)"
    ]
  }
}

Agent vidi, kaj je dovoljeno in kaj ne. Ni vam treba vsakič klikniti »da« ali »ne«—agent deluje hitro, vi pa nadzorujete meje.

Naprej: shranite si 7-minutni kontrolni seznam#

Kontrolni seznam: »AI je to izbrisal—kaj naj storim?«

1. Takoj ustavite dejanskega destruktivnega pisca; preverite ustavitev podrejenih ali oddaljenih operacij
2. Ne zaženite sistema znova; ohranite nepovezane procese z odprtimi izbrisanimi datotekami
3. Čas incidenta in dokaze ukazov zabeležite na ločeno preverjeno napravo
4. Preživele datoteke, metapodatke Git in ustrezne dnevnike sej kopirajte na to ločeno napravo
5. V ohranjeni kopiji preglejte git reflog --all in preverjeni commit obnovite v ločeno delovno drevo
6. Če git ni pomagal—git fsck --lost-found
7. Podatkovna zbirka: PITR (AWS/Yandex/Supabase) ali zadnji posnetek
8. Datoteke: Time Machine v Macu, lsof v Linuxu
9. Zadnja možnost: podpora ponudnika + različice S3
10. Po obnovitvi nastavite 7 preventivnih pravil iz tega vodnika

Naslednje—sistematična zaščita:

• Plan Mode v Claude Code—da agent pripravi načrt pred destruktivnim dejanjem
• Hooks v Claude Code—pripravljene predloge za blokiranje nevarnih ukazov
• Kako razveljaviti spremembe v Claude Code—podroben vodnik za /rewind, git in 5 običajnih načinov povrnitve
• Varnostni pregled v Claude Code—redna preverjanja varnosti kode

Odprite Ailoot.