AI дерекқорды жойды: қалпына келтірудің 7 минуттық жоспары

Ailoot-пен жұмыс істеу туралы практикалық ақпарат құжаттамада берілген.

Алғашқы минутта не істеу керек: ТОҚТАҢЫЗ, дүрлікпеңіз#

Бұл сіздің басыңызға түскенде, ең алдымен агентті тоқтатыңыз. Оның әрекеттерін өзіңіз кері қайтаруға тырыспаңыз, «бәрін қалпына келтір» деп айтпаңыз және жаңа сұраулар жібермеңіз. Агенттің әрбір келесі әрекеті деректеріңіз әлі сақталуы мүмкін диск блоктарын басып кетуі ықтимал.

1. Агенттің терминалын жабыңыз

   Қауіпті пәрменді Ctrl+C арқылы дереу үзіңіз; жою біткенін күтпеңіз. Агентті тоқтату бала пәрменін, қашықтағы job не дерекқор сұрауын міндетті тоқтатпайды. Нақты жазушыны тауып, сол әрекетті тоқтатыңыз не болдырмаңыз; деректі құрта берсе, күштірек аяқтау қажет болуы мүмкін. Қалпына келетін ашық файлдары бар қатысы жоқ процестерді сақтаңыз.

2. Ноутбукты ҚАЙТА ЖҮКТЕМЕҢІЗ

   Жойылған дерек қалпына келуі мүмкін, бірақ сақтау жүйесі, дерекқор әрекеті, SSD discard/TRIM және кейінгі жазулар анықтайды. Зақымданған томға жазуды азайтыңыз; байттар әлі бар деп санамаңыз.

3. Ашық процестерді ЖАППАҢЫЗ

   Жойылған файлды ашық ұстайтын қатысы жоқ процестерді сақтаңыз: дескриптор арқылы қалпына келтіру мүмкін болуы ықтимал. Бұл зиянды жазушыға қатысты емес: оны алдымен тоқтатыңыз. Ашық handle сақтау үшін жоюды жалғастырмаңыз.

4. Экран жазбасын бастаңыз

   Нақты уақытты, әсер еткен жолдарды және көрінетін пәрмен шығысын тіркеңіз. Жазба не журнал көшірмесін зақымданған томға емес, бөлек тексерілген құрылғыға сақтаңыз. Қалпына келтіруден бұрын аман бақыланатын, бақыланбайтын, еленбейтін файлдар мен Git метадеректерін сонда көшіріңіз.

Енді қалпына келтіруге 6 минут бар. Бастайық.

2–3-минуттар: нақты не болғанын құжаттаңыз#

Жаңа терминал терезесін ашыңыз. Агент жұмыс істеп тұрған терезе емес — басқа терезе. Мына үш команданы ретімен орындаңыз.

1. Git репозиторийінде нақты не өзгергенін тіркеңіз:

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

Жойылған бақыланатын файл индексте не коммитте қалуы мүмкін. Restore-дан бұрын бақыланбайтын және еленбейтін файлдарды қоса қазіргі ағашты сақтаңыз; орнында қалпына келтіру аман түзетулердің үстінен жаза алады. Бөлек көшірмеде қарап, қалпына келтіріңіз.

2. Қай агент процестері жұмыс істеп тұрғанын тексеріңіз:

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

Қай процесс қауіпті жазуды жалғастырып жатқанын анықтаңыз; атаудың сәйкестігі жеткіліксіз. Сол жазушыны тоқтатып, тоқтағанын тексеріңіз. Пайдалы ашық файлы бар қатысы жоқ процестерді сақтаңыз; қалыпты аяқтау өтпей, жою жалғасса, мәжбүрлеп тоқтату қажет болуы мүмкін.

3. Агент сеансының журналын сақтаңыз:

Claude Code JSONL сеанстарын ~/.claude/projects/ ішінде сақтайды. Cursor оларды ~/.cursor/ ішінде сақтайды. Дәл қазір көшірмесін жасаңыз:

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

/external/incident-evidence/ орнына бөлек тексерілген жалғанған құрылғыдағы бар дәлел қалтасын қойыңыз. Көшірмені зақымданған томға жазбаңыз және бар дәлелдің үстінен жазбаңыз. Бұл қалтада агентпен болған әңгіме сөзбе-сөз сақталады: ол қандай командаларды орындады, не деп жауап берді және қандай ретпен. Бұл оқиғаны зерттеудің және агент контекстінен жойылған файлдарды қалпына келтірудің негізгі көзі (4-қадамды қараңыз).

4-минут: git reflog — ең жақсы мүмкіндігіңіз#

git reflog жазбалар сақталғанша жергілікті reference қозғалысын тіркейді. Мерзім мен pruning өзгереді, қолжетімсіз объектілер жойылуы мүмкін; ол әр бұрынғы коммиттің кепілді архиві емес. Төмендегі қалпына келтіруді бөлек құрылғыдағы сақталған репозиторий көшірмесінен орындаңыз.

1-қадам. Журналды қараңыз:

git reflog --all

Мынаған ұқсас тізім аласыз:

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

Агент зиян келтіргенге дейінгі нүктені іздеңіз. Әр жазба — сол сәттегі репозиторий күйінің «снапшоты».

2-қадам. Бөлек жұмыс ағашына қалпына келтіріңіз:

Репозиторий мен аман қалған барлық жұмысты бөлек құрылғыға көшіргеннен кейін сол сақталған репозиторий көшірмесінде орындаңыз. Мәнді reflog-та тексерген нақты commit SHA-мен ауыстырып, бос тармақ пен нысана таңдаңыз:

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

../recovery-check файлдарын қарап, бірдеңені кері көшірмес бұрын сақталған коммиттелмеген файлдармен салыстырыңыз. Пәрмен таңдалған коммитті бөлек ашады, зақымданған ағашты reset етпейді. Байланысқан worktree-лер көшірілген репозиторийдің Git object store-ын бөліседі, сондықтан бұл — тәуелсіз резерв емес, қалпына келтіру workspace-і. Ресми git-worktree құжаттамасын қараңыз.

Егер reflog та тазаланса (агент git gc орындап үлгерсе):

git fsck --lost-found

Бұл команда ешбір тармаққа тіркелмеген «жоғалған» коммиттер мен blob-тарды (файл нысандарын) табады. Олар .git/lost-found/commit/ және .git/lost-found/other/ ішінде пайда болады. Файлды сол жерден қалпына келтіру үшін:

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

git reflog көмектеспейтін жағдайлар:

• Файл тек жұмыс ағашында болып, коммитке не stash-ке кірмеген → reflog оны көре алмайды
• 90 күннен көп уақыт өтіп, git gc орындалған (gc.reflogExpire әдепкі мәні)
• Бүкіл репозиторий жойылған (rm -rf .git) — онда Time Machine немесе снапшот қажет

5-минут: дерекқорды сақтық көшірмеден қалпына келтіріңіз#

Дерекқор DROP DATABASE, DROP TABLE немесе DELETE FROM ... WHERE ... (WHERE шартынсыз) арқылы жойылды. Не істеу керек?

1-қадам. Провайдеріңіз PITR ұсынатынын анықтаңыз:

2-қадам. Ескі инстансқа емес, жаңасына қалпына келтіріңіз:

Жұмыс істеп тұрған дерекқордың үстінен ешқашан қалпына келтірмеңіз. Сақтық көшірмеден жаңа инстанс жасаңыз да, қолданбаны соған ауыстырыңыз. Бірдеңе дұрыс болмаса, DNS-ті кері ауыстыра аласыз.

3-қадам. PITR қосылмаған болса, ең соңғы снапшотты қолданыңыз:

# AWS RDS, снапшоттарды тізімдеу:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Снапшоттан қалпына келтіру:
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

Supabase туралы маңызды жайт 2026 жылы көп адамның басына қиындық әкелді: PITR қосылғанда, күнделікті сақтық көшірмелер жасалмай қалады. Бұл күтпеген жағдай; нәтижесінде мүлде сақтық көшірмесіз қалуыңыз мүмкін. PITR белсенді екенін ЖӘНЕ қалпына келтіруге арналған снапшот барын тексеру үшін Dashboard → Database → Backups бөліміне өтіңіз.

6-минут: Time Machine, lsof және диск снапшоттары#

macOS—Time Machine:

# Снапшоттарды тізімдеу:
tmutil listbackups

# Ең соңғы сақтық көшірмеден файлды қалпына келтіру:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine сағат сайын снапшот жасайды, сағаттық снапшоттарды бір күн, күнделіктерін бір апта сақтайды, ал апталықтарын мерзімсіз сақтайды. Ноутбук Time Capsule-ға не сыртқы дискіге қосылған болса, жобаңыздың сағат сайынғы көшірмесі сонда болады.

Linux—файл жойылған, бірақ процесс оны әлі ашық ұстап тұр:

# Процестер ашық ұстап тұрған барлық «жойылған» файлдарды табу:
sudo lsof | grep deleted

# Мынаған ұқсас жолдар шығады:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Файлды /proc/PID/fd/N ішінен тікелей көшіру:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Процесс жабылмаған болса, сәттілік ықтималдығы шамамен 95%. ext4, xfs, btrfs жүйелерінде жұмыс істейді.

macOS—lsof арқылы баламасы:

lsof | grep deleted

Файлды көшіру қиынырақ (/proc/ жоқ), бірақ мұны lldb арқылы жасауға болады:

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

Бүкіл дискінің снапшоты (Linux, соңғы амал):

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

Бұл бүкіл бөлімді кескін файлы ретінде сақтайды. Содан соң extundelete немесе photorec арқылы қалпына келтіріңіз. Қалпына келтіру мүмкіндігі жойылғаннан бері дискіге қанша дерек жазылғанына байланысты. Ештеңе жазылмаған болса, мүмкіндік 80–90%. Диск бір сағат бойы жұмыс істеп тұрса, мүмкіндік 20–30%.

7-минут: сақтық көшірме болмаса не істеу керек#

1-нұсқа—провайдердің қолдау қызметі:

AWS, Yandex Cloud, Google Cloud және DigitalOcean тұтынушы деректеріне қатысты апаттан кейін де ішкі сақтау жүйесінен деректерді мезгіл-мезгіл қалпына келтіреді, әсіресе ақылы жоспарларда. Қолдау қызметіне өтінім жіберіп, оқиғаның нақты уақытын көрсетіп, жағдайдың скриншоттарын тіркеңіз. Бұл көбіне өз жағында автоматты сақтық көшірмелерін сақтайтын ірі провайдерлерде жұмыс істейді. Мүмкіндігі — 40–60%; жауап беру мерзімі — 24–72 сағат.

2-нұсқа—S3 нұсқалары:

Файлдар S3 (немесе Yandex Object Storage) ішінде болып, нұсқалау қосулы болса, барлық нұсқа физикалық түрде бар; олар тек «жойылған» деп белгіленген.

# AWS—нұсқаларды тізімдеу:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Нұсқаны қалпына келтіру:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Маңызды ескерту: Claude Code сеанстарды мәңгі сақтамайды — ескі JSONL файлдары бірнеше аптадан соң автоматты түрде жойылады. Апат болғанда қолыңызда бір айлық JSONL тарихы болуы үшін ~/.claude/projects/ қалтасын қарапайым cron тапсырмасымен аптасына бір рет сыртқы дискіге көшіріңіз:

# Crontab ішінде, әр жексенбі 03:00-де:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Бұл тегін және «бәрі жоғалды, сақтық көшірме жоқ, reflog бос» деген кезде құтқарады.

Мұның қайталанбауына арналған 7 ереже#

1. Жоюға әкелетін кез келген операция алдында Plan Mode қосыңыз. Claude Code ішінде:

claude --plan

Агент әрекет етпес бұрын жоспар құрады. Сіз оны оқып, DROP TABLE users жолын көріп, тоқтата аласыз. Plan Mode болмаса, агент өз бетімен шешім қабылдап, миллисекундтар ішінде орындайды. Толығырақ Claude Code ішіндегі Plan Mode нұсқаулығынан оқыңыз.

2. Hook-тар қосымша дабыл ретінде. Оқиға JSON-ын stdin арқылы оқып, танылған жоғары тәуекелге exit 2 беретін сыналған PreToolUse hook қолданыңыз. Төмендегі толық мысал Bash, Write және Edit-ті қамтиды; ол қауіпсіздік шекарасы емес және жанама әрекеттерді өткізуі мүмкін. Дерекқор рұқсаттары мен құмсалғышты шектеңіз.

3. Агентке тек оқуға арналған дерекқор пайдаланушысын беріңіз. Агентке арналған жеке пайдаланушы жасаңыз, оған DROP, TRUNCATE немесе 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;

Агентке жазу шынымен қажет болғанда, басқа пайдаланушыға қолмен ауысыңыз. Күнделікті тапсырмаларға (деректерді талдау, есептер, дашбордтар) тек оқуға арналған пайдаланушы жеткілікті.

4. Тексерілген өзгерістерді Git-те сақтаңыз. .claude/settings.json ішіндегі PostToolUse hook-ы Write және Edit әрекеттерінен кейін еске салу хабарын шығара алады:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Diff-ті тексеріп, тек келісілген файлдарға қолмен коммит жасаңыз.' >&2"
          }
        ]
      }
    ]
  }
}

Бұл мысал тек еске салу хабарын шығарады; файлдарды индекске қоспайды және коммит жасамайды. Diff-ті тексеріп, тек келісілген файлдарға қолмен коммит жасаңыз. Reflog коммитке енгізілмеген өзгерістерді сақтамайды.

5. Тәжірибелерге арналған sandbox жоба. Агенттің нақты тұтынушы деректері бар жобада жұмыс істеуіне ешқашан жол бермеңіз. Жобаның көшірмесі мен жасанды деректері бар бөлек ~/sandbox-projects/ қалтасын жасаңыз. Онда жаңа сұрауды, агентті немесе MCP серверін сынап көріңіз. Бірдеңе бұзылса, зияны жоқ.

6. restic арқылы сағат сайын диск снапшоттарын жасаңыз.

# Орнату:
brew install restic  # macOS
sudo apt install restic  # Linux

# Репозиторий жасау:
restic init --repo /external/backups

# Ағымдағы жобаның сақтық көшірмесін жасау:
restic --repo /external/backups backup ~/projects

# Сағат сайынғы cron кестесін орнату:
crontab -e
# Мынаны қосыңыз:
0 * * * * restic --repo /external/backups backup ~/projects

Сағат сайынғы сақтық көшірмені жеті күн, күнделікті сақтық көшірмені төрт апта сақтайды — өткеннің кез келген сәтіне қайтара аласыз. Бұл тегін және баптауға 10 минут кетеді.

7. Claude Code JSONL сеанстарын архивтеңіз. Жоғарыда айтылды, бірақ жеке ереже ретінде қайталаймыз: ~/.claude/projects/ қалтасын сыртқы дискіге аптасына бір рет rsync арқылы көшіріңіз. Бұл тегін әрі crontab ішіне бір жол жазуды қажет етеді.

Қауіпті командаларды бұғаттайтын дайын hooks#

Бұл жазбаны бар hook-тарды алмастырмай, .claude/settings.json ішіне біріктіріңіз:

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

Мына Python 3 скриптін .claude/hooks/check-risk.py ретінде жасаңыз:

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 құжатталған JSON оқиғасын stdin арқылы оқып, tool_input.command не tool_input.file_path тексереді және сәйкестікке exit 2 береді. Write пен Edit екеуін де тексереді. Сенбес бұрын зиянсыз рұқсат етілетін және бұғатталатын fixture-ді сынап, Python мен скрипттің шынымен басталатынын растаңыз.

Бұл — лексикалық дабыл: реті ауысқан жалауша, скрипт, alias, жасырылған пәрмен, басқа құрал не жанама жазуды өткізіп, қауіпсіз дәйексөзді де қабылдамауы мүмкін. OS/дерекқор рұқсаттарын бермейді не алмайды. Production credentials агент ортасынан тыс болсын, тек оқитын дерекқор рөлі мен міндеттелген құмсалғышты қолданыңыз, hook конфигурациясын өзгертуден қорғаңыз. Ресми hook кірісі мен аяқталу кодтарын қараңыз.

Әдейі ерекше әрекетті қарап, лайық шектелген аккаунтпен агенттен тыс орындаңыз. Shell орта айнымалысы құжатталған hook өшіру интерфейсі емес, hook-тар кәдімгі терминал пәрмендерін басқармайды.

AI-ға қашан рұқсат беру керек (және қашан бермеу керек)#

Anthropic --dangerously-skip-permissions жалаушасын (YOLO режимі деп те аталады) «сенімді орталарға» арналған мүмкіндік ретінде құжаттайды. 2026 жылғы шынайы жағдайда бұл — апатқа апаратын төте жол. Агент рұқсат сұрамайтын болса, ол:

• Кез келген Bash командасын растаусыз орындайды
• Файлдарды сұрамай жазады
• YOLO режимін мұра ететін қосалқы агентті іске қоса алады, әрі бұл режимді кері қайтару мүмкін емес

Үшінші жайт — ең қауіптісі. Негізгі агентті YOLO режимінде іске қоссаңыз, оның қосалқы агенттері де YOLO режимінде болады, әрі оны өзгерте алмайсыз. Бір сұрау — жүйеңізге кез келген әрекетті жасай алатын 10 параллель агенттің тізбекті іске қосылуына жеткілікті.

Ереже:

Балама—дәл рұқсаттар. .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/*)"
    ]
  }
}

Агентке не нәрсеге рұқсат етілгені және тыйым салынғаны көрінеді. Әр жолы «иә» не «жоқ» түймесін басудың қажеті жоқ — агент жылдам жұмыс істейді, ал шекараны сіз басқарасыз.

Келесі қадам: бетбелгіге сақтайтын 7 минуттық тізім#

Тізім: «AI оны жойды — енді не істеймін?»

1. Нақты зиянды жазушыны дереу тоқтатып, бала не қашықтағы әрекеттер тоқтағанын растаңыз
2. Қайта жүктемеңіз; жойылған файлды ашық ұстайтын қатысы жоқ процестерді сақтаңыз
3. Оқиға уақыты мен пәрмен дәлелдерін бөлек тексерілген құрылғыда тіркеңіз
4. Аман файлдарды, Git метадеректерін және тиісті сеанс журналдарын сол бөлек құрылғыға көшіріңіз
5. Сақталған репозиторий көшірмесінде git reflog --all қарап, тексерілген коммитті бөлек worktree-ге қалпына келтіріңіз
6. Git көмектеспесе — git fsck --lost-found
7. Дерекқор: PITR (AWS/Yandex/Supabase) немесе ең соңғы снапшот
8. Файлдар: Mac жүйесінде Time Machine, Linux жүйесінде lsof
9. Соңғы амал: провайдердің қолдау қызметі + S3 нұсқалары
10. Қалпына келтірген соң, осы нұсқаулықтағы 7 алдын алу ережесін баптаңыз

Келесі қадам—жүйелі қорғаныс:

• Claude Code ішіндегі Plan Mode—агент жоюға әкелетін операция алдында жоспар құруы үшін
• Claude Code ішіндегі Hooks—қауіпті командаларды бұғаттайтын дайын үлгілер
• Claude Code өзгерістерін қалай кері қайтаруға болады—/rewind, git және кері қайтарудың 5 стандартты әдісі туралы егжей-тегжейлі нұсқаулық
• Claude Code қауіпсіздігін шолу—код қауіпсіздігін жүйелі тексеру

Ailoot-ты ашыңыз.