AI ištrynė duomenų bazę: 7 minučių atkūrimo planas

Praktinės informacijos apie darbą su Ailoot rasite dokumentacijoje.

Ką daryti pirmąją minutę: SUSTOKITE, nepanikuokite#

Jei taip nutiktų jums, pirmiausia sustabdykite agentą. Nebandykite patys atšaukti jo veiksmų, neprašykite „atkurti visko“ ir nesiųskite naujų užklausų. Kiekvienas paskesnis agento veiksmas gali perrašyti disko blokus, kuriuose dar gali būti saugomi jūsų duomenys.

1. Uždarykite agento terminalą

   Pavojingą komandą nedelsdami pertraukite su Ctrl+C; nelaukite trynimo pabaigos. Agento sustabdymas nebūtinai sustabdo jo antrines komandas, nuotolines užduotis ar DB užklausas. Nustatykite tikrą rašytoją ir sustabdykite ar atšaukite operaciją; jei duomenų naikinimas tęsiasi, taikykite stipresnį nutraukimą. Nesusijusius procesus su galbūt atkuriamais atidarytais failais palikite veikti.

2. NEPALEISKITE nešiojamojo kompiuterio iš naujo

   Ištrinti duomenys gali likti atkuriami, bet tai lemia saugykla, DB elgsena, SSD discard/TRIM ir vėlesni rašymai. Mažinkite rašymus paveiktame tome; nemanykite, kad baitai vis dar išlikę.

3. NEUŽDARYKITE atidarytų procesų

   Išsaugokite nesusijusius procesus, laikančius ištrintus failus atidarytus, nes atkūrimas per jų failų deskriptorius gali būti įmanomas. Tai netaikoma destruktyviam rašytojui: jį sustabdykite pirmiausia. Nepalikite trynimo veikti vien dėl atidaryto deskriptoriaus.

4. Pradėkite įrašinėti ekraną

   Užrašykite tikslų laiką, paveiktus kelius ir matomą komandų išvestį. Įrašą ar žurnalų kopijas saugokite atskirame patikrintame įrenginyje, o ne pažeistame tome. Prieš atkūrimą ten išsaugokite išlikusius sekamus, nesekamus, ignoruojamus failus ir Git metaduomenis.

Toliau—6 minutės atkūrimui. Pradėkime.

2–3 minutės: tiksliai užfiksuokite, kas nutiko#

Atidarykite naują terminalo langą. Ne tą, kuriame veikia agentas—kitą. Iš eilės paleiskite šias tris komandas.

1. Tiksliai užfiksuokite, kas pasikeitė git saugykloje:

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

Ištrintas sekamas failas gali dar būti indekse ar įraše. Prieš bet kokį atkūrimą išsaugokite dabartinį darbo medį su nesekamais ir ignoruojamais failais; atkūrimas vietoje gali perrašyti išlikusius pakeitimus. Tikrinkite ir atkurkite atskiroje kopijoje.

2. Patikrinkite, kurie agento procesai veikia:

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

Nustatykite, kuris procesas dar atlieka pavojingus rašymus; vien pavadinimo atitikties nepakanka. Sustabdykite tą rašytoją ir patvirtinkite, kad jis sustojo. Išsaugokite nesusijusius procesus su naudingais atidarytais failais; jei tvarkingas nutraukimas nepavyksta ir naikinimas tęsiasi, gali reikėti priverstinio nutraukimo.

3. Išsaugokite agento sesijos žurnalą:

Claude Code saugo JSONL sesijas aplanke ~/.claude/projects/. Cursor jas saugo aplanke ~/.cursor/. Nedelsdami padarykite kopiją:

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

/external/incident-evidence/ pakeiskite esamu įrodymų katalogu atskirame patikrintame prijungtame įrenginyje. Nerašykite kopijos į paveiktą tomą ir neperrašykite esamų įrodymų. Šiame aplanke yra pažodinis pokalbis su agentu—kokias komandas jis vykdė, ką atsakė ir kokia tvarka. Tai pagrindinis jūsų šaltinis incidentui tirti ir galbūt ištrintiems failams atkurti iš jo konteksto (žr. 4 veiksmą).

4 minutė: git reflog—geriausia jūsų galimybė#

git reflog registruoja vietinių nuorodų judėjimą, kol įrašai išlaikomi. Galiojimas ir valymas skiriasi, o nepasiekiami objektai gali būti pašalinti; tai nėra garantuotas visų buvusių įrašų archyvas. Toliau atkūrimą vykdykite iš atskirame įrenginyje išsaugotos saugyklos kopijos.

1 veiksmas. Peržiūrėkite žurnalą:

git reflog --all

Matysite maždaug tokį sąrašą:

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

Ieškokite būsenos prieš agentui padarant žalą. Kiekvienas įrašas yra tos akimirkos saugyklos būsenos „momentinė kopija“.

2 veiksmas. Atkurkite atskirame darbo medyje:

Nukopijavę saugyklą ir visą išlikusį darbą į atskirą įrenginį, tai vykdykite iš tos išsaugotos saugyklos kopijos. Reikšmę pakeiskite tiksliu reflog patikrintu įrašo SHA ir pasirinkite nenaudotą šaką bei paskirtį:

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

Apžiūrėkite ../recovery-check atkurtus failus ir prieš ką nors kopijuodami atgal palyginkite su išsaugotais neįrašytais failais. Komanda pasirinktą įrašą išskleidžia atskirai; ji neatstato pažeisto darbo medžio. Susieti worktree dalijasi nukopijuotos saugyklos Git objektų saugykla, todėl tai atkūrimo darbo vieta, o ne nepriklausoma atsarginė kopija. Žr. oficialią git-worktree dokumentaciją.

Jei reflog taip pat išvalytas (agentas spėjo paleisti git gc):

git fsck --lost-found

Ši komanda randa „prarastus“ commit ir blob (failų objektus), kurie nebėra susieti su jokia šaka. Jie bus pateikti .git/lost-found/commit/ ir .git/lost-found/other/ aplankuose. Norėdami iš ten atkurti failą:

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

Kada git reflog nepadės:

• Failas buvo tik darbiniame medyje, be commit ar stash → reflog jo nemato
• Praėjo daugiau nei 90 dienų (standartinė gc.reflogExpire trukmė) ir buvo paleista git gc
• Ištrinta visa saugykla (rm -rf .git)—tada reikės Time Machine arba momentinės kopijos

5 minutė: atkurkite duomenų bazę iš atsarginės kopijos#

Duomenų bazė buvo ištrinta naudojant DROP DATABASE, DROP TABLE arba DELETE FROM ... WHERE ... (be WHERE sąlygos). Ką daryti?

1 veiksmas. Išsiaiškinkite, ar jūsų teikėjas siūlo PITR:

2 veiksmas. Atkurkite į naują egzempliorių, ne į senąjį:

Niekada neatkurkite duomenų ant veikiančios duomenų bazės. Sukurkite naują egzempliorių iš atsarginės kopijos, tada perjunkite programą į jį. Jei kas nors nepavyks, galėsite grąžinti DNS pakeitimus.

3 veiksmas. Jei PITR nebuvo įjungtas, naudokite naujausią momentinę kopiją:

# AWS RDS, momentinių kopijų sąrašas:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Atkurti iš momentinės kopijos:
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

Pastaba apie Supabase, kuri 2026 m. nustebino daugelį: įjungus PITR, kasdienės atsarginės kopijos nebekuriamos. Tai nelogiška elgsena; galite likti visai be atsarginių kopijų. Patikrinkite Dashboard → Database → Backups ir įsitikinkite, kad PITR aktyvus IR turite momentinę kopiją, iš kurios galėtumėte atkurti duomenis.

6 minutė: Time Machine, lsof ir disko momentinės kopijos#

macOS—Time Machine:

# Momentinių kopijų sąrašas:
tmutil listbackups

# Atkurti failą iš naujausios atsarginės kopijos:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine kuria momentines kopijas kas valandą, valandines kopijas saugo vieną dieną, dienos kopijas—vieną savaitę, o savaitines—neribotai. Jei nešiojamasis kompiuteris prijungtas prie Time Capsule arba išorinio disko, projektas ten išsaugotas valandos tikslumu.

Linux—failas ištrintas, bet procesas vis dar jį turi atidaręs:

# Rasti visus „ištrintus“ failus, kuriuos procesas vis dar turi atidaręs:
sudo lsof | grep deleted

# Matysite panašias eilutes:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Nukopijuoti failą tiesiai iš /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Jei procesas nebuvo uždarytas, sėkmės tikimybė yra ~95 %. Veikia su ext4, xfs, btrfs.

macOS—analogiškas būdas su lsof:

lsof | grep deleted

Nukopijuoti failą sudėtingiau (nėra /proc/), tačiau tai galima padaryti naudojant lldb:

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

Viso disko momentinė kopija (Linux, kraštutinė priemonė):

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

Taip visas skaidinys išsaugomas kaip atvaizdas. Tada atkurkite duomenis naudodami extundelete arba photorec. Atkūrimo tikimybė priklauso nuo to, kiek duomenų į diską įrašyta po ištrynimo. Jei nieko neįrašyta, tikimybė yra 80–90 %. Jei sistema jau veikė valandą, ji siekia 20–30 %.

7 minutė: ką daryti, jei nėra atsarginės kopijos#

1 galimybė—teikėjo palaikymo tarnyba:

AWS, Yandex Cloud, Google Cloud ir DigitalOcean periodiškai atkuria duomenis iš savo vidinės saugyklos net ir po kliento patirtos nelaimės, ypač naudojant mokamus planus. Sukurkite palaikymo užklausą, nurodykite tikslų incidento laiką ir pridėkite būsenos ekrano kopijas. Dažniausiai tai pavyksta su dideliais teikėjais, kurie savo pusėje saugo automatines atsargines kopijas. Tikimybė—40–60 %; atsakymo laikas—24–72 valandos.

2 galimybė—S3 versijų valdymas:

Jei failai buvo S3 (arba Yandex Object Storage) ir versijų valdymas buvo įjungtas, visos versijos fiziškai egzistuoja; jos tik pažymėtos kaip „ištrintos“.

# AWS—versijų sąrašas:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Atkurti versiją:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Svarbus įspėjimas: Claude Code sesijų nesaugo amžinai—seni JSONL failai po kelių savaičių automatiškai ištrinami. Kad nelaimės atveju turėtumėte mėnesio JSONL istoriją, kartą per savaitę nukopijuokite ~/.claude/projects/ į išorinį diską naudodami paprastą cron užduotį:

# Crontab faile, kiekvieną sekmadienį 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Tai nemokama ir išgelbės jus, kai „viskas dingo, nėra atsarginės kopijos, o reflog tuščias“.

7 taisyklės, padėsiančios užtikrinti, kad tai nepasikartotų#

1. Plan Mode prieš bet kokią destruktyvią operaciją. Claude Code aplinkoje:

claude --plan

Agentas sudaro planą prieš imdamasis veiksmų. Jūs jį perskaitote, pamatote DROP TABLE users ir atšaukiate. Be Plan Mode agentas pats nusprendžia ir įvykdo komandą per milisekundes. Daugiau sužinosite Claude Code Plan Mode vadove.

2. Hook kaip papildomas signalizatorius. Naudokite išbandytą PreToolUse hook, kuris iš stdin skaito įvykio JSON ir aptikęs didelės rizikos veiksmą grąžina 2. Toliau pateiktas visas pavyzdys apima Bash, Write ir Edit; jis nėra saugumo riba ir gali praleisti netiesiogines operacijas. DB teises ir smėlio dėžę laikykite ribotas.

3. Tik skaitoma agento DB naudotojo paskyra. Sukurkite agentui atskirą naudotoją, kuris neturi DROP, TRUNCATE ar DELETE teisių:

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;

Kai agentui iš tiesų reikia rašymo teisių, rankiniu būdu perjunkite kitą naudotoją. Kasdienėms užduotims (duomenų analizei, ataskaitoms, skydeliams) pakanka tik skaitymo teisių.

4. Patikrintus pakeitimus išsaugokite Git. Faile .claude/settings.json esantis PostToolUse hook gali parodyti priminimą po Write ir Edit operacijų:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Peržiūrėkite diff ir rankiniu būdu sukurkite commit tik sutartiems failams.' >&2"
          }
        ]
      }
    ]
  }
}

Šis pavyzdys tik parodo priminimą; jis neįtraukia failų į indeksą ir nekuria commit. Peržiūrėkite diff ir rankiniu būdu sukurkite commit tik sutartiems failams. Reflog neišsaugo pakeitimų, kurie neįtraukti į commit.

5. Sandbox projektas eksperimentams. Niekada neleiskite agentui dirbti projekte, kuriame yra tikrų klientų duomenų. Sukurkite atskirą ~/sandbox-projects/ aplanką su projekto kopija ir sintetiniais duomenimis. Jame išbandykite naują prompt, agentą arba MCP serverį. Jei kas nors suges, žalos nebus.

6. Disko momentinės kopijos su restic kas valandą.

# Įdiegimas:
brew install restic  # macOS
sudo apt install restic  # Linux

# Saugyklos sukūrimas:
restic init --repo /external/backups

# Dabartinio projekto atsarginė kopija:
restic --repo /external/backups backup ~/projects

# Cron užduoties planavimas kas valandą:
crontab -e
# Pridėkite:
0 * * * * restic --repo /external/backups backup ~/projects

Septynios dienos valandinių kopijų, keturios savaitės dieninių kopijų—ir visada galėsite grįžti į bet kurį ankstesnį laiką. Tai nemokama, o nustatymas užtrunka 10 minučių.

7. Archyvuokite Claude Code JSONL sesijas. Apie tai jau kalbėjome, bet pakartokime kaip atskirą taisyklę: suplanuokite savaitinį rsync iš ~/.claude/projects/ į išorinį diską. Tai nemokama, o crontab užtenka vienos eilutės.

Paruošti hooks pavojingoms komandoms blokuoti#

Šį įrašą sujunkite su .claude/settings.json, nepakeisdami esamų hook:

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

Sukurkite .claude/hooks/check-risk.py su šiuo Python 3 skriptu:

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)

Hook skaito dokumentuotą JSON įvykį iš stdin, tikrina tool_input.command ar tool_input.file_path ir atitikčiai grąžina 2. Jis tikrina ir Write, ir Edit. Prieš pasikliaudami išbandykite nepavojingą leidžiamą bei blokuojamą fikstūrą ir patikrinkite, kad Python bei sukonfigūruotas skriptas iš tikrųjų paleidžiami.

Tai leksinis signalizatorius: jis gali praleisti perrikiuotas parinktis, scenarijus, pseudonimus, užmaskuotas komandas, kitus įrankius ir netiesioginius rašymus; taip pat gali atmesti nepavojingus cituotus pavyzdžius. Jis nesuteikia ir neatima OS ar duomenų bazės teisių. Produkcinius prisijungimo duomenis laikykite už agento aplinkos ribų, naudokite tik skaitymo DB vaidmenį ir užtikrintą smėlio dėžę, o hook konfigūraciją apsaugokite nuo keitimo. Žr. oficialią hook įvesties ir išėjimo kodų nuorodą.

Sąmoningai išimtinei operacijai ją peržiūrėkite ir vykdykite už agento ribų su tinkamai apribota paskyra. Shell aplinkos kintamasis nėra dokumentuota hook išjungimo sąsaja, o hook nevaldo įprastų terminalo komandų.

Kada suteikti AI teises (o kada ne)#

Anthropic dokumentuoja --dangerously-skip-permissions vėliavėlę (dar vadinamą YOLO režimu) kaip parinktį „patikimoms aplinkoms“. 2026 m. realybėje tai tiesus kelias į nelaimę. Kai agentui nereikia klausti, jis:

• Vykdo bet kurią Bash komandą be patvirtinimo
• Rašo failus neatsiklausęs
• Gali iškviesti poagentą, kuris paveldi YOLO režimą ir kurio neįmanoma iš jo išjungti

Trečiasis punktas klastingiausias. Jei pagrindinį agentą paleidžiate YOLO režimu, visi jo poagentai taip pat veikia YOLO režimu ir jūs negalite to pakeisti. Vienas prompt—ir 10 lygiagrečių agentų kaskada gali padaryti bet ką jūsų sistemoje.

Taisyklė:

Alternatyva—tikslios teisės. Faile .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/*)"
    ]
  }
}

Agentas mato, kas leidžiama ir kas draudžiama. Nereikia kaskart spausti „taip“ arba „ne“—agentas dirba greitai, o jūs kontroliuojate ribas.

Toliau: 7 minučių kontrolinis sąrašas, kurį verta išsisaugoti#

Kontrolinis sąrašas: „AI ištrynė—ką daryti?“

1. Nedelsdami sustabdykite tikrą destruktyvų rašytoją; patvirtinkite antrinių ar nuotolinių operacijų sustabdymą
2. Nepaleiskite sistemos iš naujo; išsaugokite nesusijusius procesus su atidarytais ištrintais failais
3. Incidento laiką ir komandų įrodymus įrašykite atskirame patikrintame įrenginyje
4. Išlikusius failus, Git metaduomenis ir svarbius sesijų žurnalus nukopijuokite į tą atskirą įrenginį
5. Išsaugotoje saugyklos kopijoje peržiūrėkite git reflog --all ir patikrintą įrašą atkurkite atskirame worktree
6. Jei git nepadėjo—git fsck --lost-found
7. Duomenų bazė: PITR (AWS/Yandex/Supabase) arba naujausia momentinė kopija
8. Failai: Time Machine Mac kompiuteryje, lsof Linux sistemoje
9. Kraštutinė priemonė: teikėjo palaikymo tarnyba + S3 versijų valdymas
10. Atkūrę duomenis, nustatykite 7 šiame vadove nurodytas prevencines taisykles

Toliau—sisteminė apsauga:

• Plan Mode Claude Code aplinkoje—kad agentas parengtų planą prieš destruktyvią operaciją
• Hooks Claude Code aplinkoje—paruošti šablonai pavojingoms komandoms blokuoti
• Kaip atšaukti pakeitimus Claude Code aplinkoje—išsamus /rewind, git ir 5 įprastų pakeitimų atšaukimo metodų vadovas
• Saugumo peržiūra Claude Code aplinkoje—reguliarūs kodo saugumo patikrinimai

Atidarykite Ailoot.