AI maʼlumotlar bazasini oʻchirib yubordi: 7 daqiqalik tiklash rejasi

Ailoot bilan ishlashga oid amaliy maʼlumotlar hujjatlarda mavjud.

Birinchi daqiqada nima qilish kerak: TOʻXTANG, vahimaga tushmang#

Bu siz bilan sodir boʻlsa, birinchi navbatda agentni toʻxtating. Uning harakatlarini oʻzingiz bekor qilishga urinmang, unga “hammasini tikla” demang va yangi soʻrovlar yubormang. Agentning keyingi har bir harakati maʼlumotlaringiz hali saqlanib turgan disk bloklari ustiga yozishi mumkin.

1. Agent terminalini yoping

Ctrl+C bilan xavfli buyruqni darhol uzing, o‘chirish tugashini kutmang. Agentni to‘xtatish child, remote job yoki baza query’sini to‘xtatmasligi mumkin. Haqiqiy yozuvchini topib, ayni amalni to‘xtating/bekor qiling; buzish davom etsa kuchliroq tugatish kerak bo‘lishi mumkin. Foydali ochiq faylli aloqasiz jarayonlarni saqlang.

2. Noutbukni qayta yuklamang

O‘chgan ma’lumot tiklanishi mumkin, lekin storage, baza xulqi, SSD discard/TRIM va keyingi yozuv hal qiladi. Zararlangan volume’ga yozishni kamaytiring; baytlar hanuz bor deb olmang.

3. Ochiq jarayonlarni yopmang

O‘chgan faylni ochiq tutgan aloqasiz jarayonni saqlang: deskriptor orqali tiklash mumkin bo‘lishi mumkin. Bu buzuvchi yozuvchiga tegishli emas; avval uni to‘xtating. Ochiq handle uchun o‘chirishni ishlatib turmang.

4. Ekran yozuvini boshlang

Aniq vaqt, zararlangan yo‘l va ko‘ringan buyruq chiqishini yozing. Yozuv/log nusxasini zararlangan volume emas, tekshirilgan alohida qurilmaga saqlang. Tiklashdan oldin qolgan tracked, untracked, ignored fayl va Git metama’lumotini o‘sha yerda asrang.

Keyin tiklash uchun 6 daqiqa bor. Boshlaymiz.

2–3-daqiqalar: aynan nima notoʻgʻri boʻlganini hujjatlashtiring#

Yangi terminal oynasini oching. Agent ishlayotgan oynani emas — boshqa oynani. Quyidagi uchta buyruqni ketma-ket bajaring.

1. Git omborida aynan nima oʻzgarganini qayd eting:

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

O‘chgan tracked fayl indeks yoki commit’da bo‘lishi mumkin. Restore’dan oldin joriy daraxtni, untracked va ignored faylni ham saqlang. Joyida tiklash qolgan tahrirni bosishi mumkin. Alohida nusxada tekshirib tiklang.

2. Qaysi agent jarayonlari ishlayotganini tekshiring:

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

Qaysi jarayon xavfli yozishni davom ettirayotganini aniqlang; nom mosligi yetmaydi. Shu yozuvchini to‘xtatib, to‘xtaganini tekshiring. Foydali faylli aloqasiz jarayonni saqlang. Yumshoq tugatish ishlamay, buzish davom etsa, majburiy tugatish kerak bo‘lishi mumkin.

3. Agent sessiyasi jurnalini saqlang:

Claude Code JSONL sessiyalarini ~/.claude/projects/ ichida saqlaydi. Cursor esa ~/.cursor/ ichida saqlaydi. Hoziroq nusxa oling:

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

/external/incident-evidence/ ni alohida tekshirilgan mounted qurilmadagi mavjud dalil papkasiga almashtiring. Zararlangan volume’ga yozmang yoki eski dalil ustiga yozmang. Bu papkada agent bilan boʻlgan suhbatning aynan oʻzi — qaysi buyruqlarni bajargani, nima deb javob bergani va qanday tartibda qilgani — saqlanadi. Bu hodisani tekshirish va ehtimol uning kontekstidan oʻchirilgan fayllarni tiklash uchun asosiy manbangiz (4-qadamga qarang).

4-daqiqa: git reflog — eng yaxshi imkoniyatingiz#

git reflog yozuvlar saqlanguncha local reference harakatini qayd qiladi. Muddat va pruning farq qiladi, yetilmaydigan obyekt o‘chishi mumkin. Har eski commit’ning kafolatli arxivi emas. Keyingi tiklashni alohida qurilmadagi asralgan repo nusxasidan bajaring.

1-qadam. Jurnalni koʻring:

git reflog --all

Taxminan shunday roʻyxat chiqadi:

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

Agent zarar yetkazishidan oldingi holatni toping. Har bir yozuv omborning oʻsha paytdagi “snapshot”idir.

2-qadam. Alohida ishchi daraxtga tiklang:

Repo va saqlanib qolgan barcha ishni alohida qurilmaga nusxalagach, shu saqlangan nusxadan bajaring. Qiymatga reflog’da tekshirilgan aniq SHA, ishlatilmagan branch va manzilni tanlang:

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

../recovery-check fayllarini tekshirib, qaytarishdan oldin saqlangan commit qilinmagan ish bilan solishtiring. Buyruq tanlangan commit’ni alohida ochadi, zararlangan daraxtni reset qilmaydi. Worktree’lar nusxa repo obyektlarini bo‘lishadi: bu tiklash workspace’i, mustaqil zaxira emas. Rasmiy git-worktree hujjatini ko‘ring.

Agar reflog ham tozalangan boʻlsa (agent git gc ni ishga tushirgan boʻlsa):

git fsck --lost-found

Bu buyruq endi hech bir branchga biriktirilmagan “yoʻqolgan” commit va bloblarni (fayl obyektlarini) topadi. Ular .git/lost-found/commit/ va .git/lost-found/other/ ichida paydo boʻladi. U yerdan faylni tiklash uchun:

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

git reflog yordam bermaydigan holatlar:

• Fayl faqat ishchi daraxtda boʻlgan, commit yoki stash qilinmagan → reflog uni koʻra olmaydi
• Standart gc.reflogExpire muddati boʻyicha 90 kundan ortiq vaqt oʻtgan va git gc ishga tushirilgan
• Butun ombor oʻchirilgan (rm -rf .git) — unda Time Machine yoki snapshot kerak boʻladi

5-daqiqa: maʼlumotlar bazasini zaxira nusxasidan tiklang#

Maʼlumotlar bazasi DROP DATABASE, DROP TABLE yoki DELETE FROM ... WHERE ... (WHERE shartisiz) bilan oʻchirildi. Nima qilish kerak?

1-qadam. Provayderingiz PITR taklif qiladimi, aniqlang:

2-qadam. Eski instansiyaga emas, yangisiga tiklang:

Faol maʼlumotlar bazasi ustiga hech qachon tiklamang. Zaxira nusxasidan yangi instansiya yarating, keyin ilovani unga oʻtkazing. Biror narsa notoʻgʻri ketsa, DNS’ni qayta oʻzgartirishingiz mumkin.

3-qadam. Agar PITR yoqilmagan boʻlsa, eng soʻnggi snapshotdan foydalaning:

# AWS RDS, snapshotlarni roʻyxatlash:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Snapshotdan tiklash:
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 bilan bogʻliq muhim jihat, 2026-yilda koʻpchilikni hayratda qoldirgan: PITR yoqilganda, kunlik zaxira nusxalari yaratilmay qoladi. Bu kutilmagan xatti-harakat; natijada umuman zaxira nusxasiz qolishingiz mumkin. PITR faol ekanini VA tiklash uchun snapshot borligini tekshirish uchun Dashboard → Database → Backups boʻlimiga qarang.

6-daqiqa: Time Machine, lsof va disk snapshotlari#

macOS — Time Machine:

# Snapshotlarni roʻyxatlash:
tmutil listbackups

# Eng soʻnggi zaxira nusxasidan faylni tiklash:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine har soatda snapshot oladi, soatlik snapshotlarni bir kun, kunliklarini bir hafta, haftaliklarini esa muddatsiz saqlaydi. Noutbukingiz Time Capsule yoki tashqi diskka ulangan boʻlsa, loyihangiz soatlik aniqlikda saqlangan boʻladi.

Linux — fayl oʻchirilgan, lekin jarayon uni hali ochiq tutib turibdi:

# Jarayon hali ochiq tutgan barcha “oʻchirilgan” fayllarni topish:
sudo lsof | grep deleted

# Shunga oʻxshash satrlar chiqadi:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Faylni bevosita /proc/PID/fd/N dan nusxalash:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Jarayon yopilmagan boʻlsa, muvaffaqiyat ehtimoli ~95%. ext4, xfs, btrfs’da ishlaydi.

macOS — lsof yordamida shunga oʻxshash usul:

lsof | grep deleted

Faylni nusxalash qiyinroq (/proc/ mavjud emas), ammo buni lldb bilan bajarish mumkin:

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

Butun disk snapshoti (Linux, oxirgi chora):

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

Bu butun boʻlimni tasvir fayli sifatida saqlaydi. Keyin extundelete yoki photorec yordamida tiklang. Tiklash ehtimoli oʻchirilgandan beri diskka qancha maʼlumot yozilganiga bogʻliq. Hech narsa yozilmagan boʻlsa, ehtimol 80–90%. Bir soat ishlatilgan boʻlsa, 20–30%.

7-daqiqa: zaxira nusxasi boʻlmasa nima qilish kerak#

1-variant — provayder yordami:

AWS, Yandex Cloud, Google Cloud va DigitalOcean mijoz boshiga falokat tushganidan keyin ham, ayniqsa pulli tariflarda, vaqti-vaqti bilan oʻz ichki xotirasidan maʼlumotlarni tiklaydi. Yordam xizmatiga murojaat oching, hodisaning aniq vaqtini bering va holat skrinshotlarini qoʻshing. Bu koʻpincha oʻz tomonida avtomatik zaxira nusxalarini saqlaydigan yirik provayderlarda ish beradi. Muvaffaqiyat ehtimoli 40–60%; javob muddati 24–72 soat.

2-variant — S3 versiyalash:

Fayllar S3’da (yoki Yandex Object Storage’da) boʻlgan va versiyalash yoqilgan boʻlsa, barcha versiyalar jismonan mavjud; ular shunchaki “oʻchirilgan” deb belgilangan.

# AWS — versiyalarni roʻyxatlash:
aws s3api list-object-versions --bucket my-bucket --prefix files/

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

Muhim ogohlantirish: Claude Code sessiyalarni abadiy saqlamaydi — eski JSONL fayllari bir necha haftadan keyin avtomatik oʻchiriladi. Falokat yuz berganda bir oylik JSONL tarixi borligiga ishonch hosil qilish uchun haftasiga bir marta oddiy cron vazifasi yordamida ~/.claude/projects/ papkasini tashqi diskka nusxalang:

# Crontab’da, har yakshanba 03:00 da:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Bu bepul va “hammasi yoʻqoldi, zaxira nusxasi yoʻq, reflog boʻsh” boʻlganida yordam beradi.

Bunday holat boshqa takrorlanmasligi uchun 7 qoida#

1. Har qanday buzuvchi amaldan oldin Plan Mode. Claude Code’da:

claude --plan

Agent ish boshlashidan oldin reja tuzadi. Siz uni oʻqib, DROP TABLE users ni koʻrib, bekor qilasiz. Plan Mode boʻlmasa, agent oʻzi qaror qiladi va millisekundlarda bajaradi. Claude Code’dagi Plan Mode qoʻllanmasidan batafsil maʼlumot oling.

2. Hook qo‘shimcha ogohlantiruvchi chegara sifatida. Stdin JSON’ni o‘qib, topilgan yuqori xatarga exit 2 beradigan sinalgan PreToolUse qo‘llang. Quyidagi to‘liq misol Bash, Write va Edit’ni qamraydi; xavfsizlik chegarasi emas, bilvosita amalni o‘tkazishi mumkin. Baza vakolati va sandbox tor bo‘lsin.

3. Agent uchun faqat oʻqish huquqiga ega DB foydalanuvchisi. Agent uchun DROP, TRUNCATE yoki DELETE ruxsatlariga ega boʻlmagan alohida foydalanuvchi yarating:

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;

Agentga haqiqatan yozish kerak boʻlganda, boshqa foydalanuvchiga qoʻlda oʻting. Maʼlumotlarni tahlil qilish, hisobotlar va boshqaruv panellari kabi kundalik vazifalar uchun faqat oʻqish huquqi yetarli.

4. Tekshirilgan oʻzgarishlarni Git’da saqlang. .claude/settings.json ichidagi PostToolUse hooki Write va Edit amallaridan keyin eslatma chiqarishi mumkin:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Diffni tekshiring va faqat kelishilgan fayllarni qoʻlda commit qiling.' >&2"
          }
        ]
      }
    ]
  }
}

Bu misol faqat eslatma chiqaradi; fayllarni indeksga qoʻshmaydi va commit yaratmaydi. Diffni tekshiring va faqat kelishilgan fayllarni qoʻlda commit qiling. Reflog commit qilinmagan oʻzgarishlarni saqlamaydi.

5. Tajribalar uchun sandbox loyiha. Agentga haqiqiy mijozlar maʼlumotlari bor loyihada ishlashga hech qachon ruxsat bermang. Loyiha nusxasi va sunʼiy maʼlumotlar bilan alohida ~/sandbox-projects/ papkasini yarating. Unda yangi soʻrov, agent yoki MCP serverni sinab koʻring. Biror narsa buzilsa, zarar boʻlmaydi.

6. Har soatda restic bilan disk snapshotlari.

# Oʻrnatish:
brew install restic  # macOS
sudo apt install restic  # Linux

# Ombor yaratish:
restic init --repo /external/backups

# Joriy loyihani zaxiralash:
restic --repo /external/backups backup ~/projects

# Har soatlik cron jadvalini sozlash:
crontab -e
# Qoʻshing:
0 * * * * restic --repo /external/backups backup ~/projects

Yetti kunlik soatlik zaxira nusxalari, toʻrt haftalik kunlik nusxalar — oʻtmishdagi istalgan nuqtaga qaytishingiz mumkin. Bu bepul va sozlashga 10 daqiqa ketadi.

7. Claude Code JSONL sessiyalarini arxivlang. Yuqorida aytib oʻtilgan, ammo alohida qoida sifatida takrorlaymiz: haftalik rsync vazifasi orqali ~/.claude/projects/ papkasini tashqi diskka nusxalang. Bu bepul va crontab’ga bir qator qoʻshish kifoya.

Xavfli buyruqlarni toʻsish uchun tayyor hooklar#

Mavjud hook’larni almashtirmay, .claude/settings.json ga birlashtiring:

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

.claude/hooks/check-risk.py ni quyidagi Python 3 skripti bilan yarating:

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 hujjatdagi JSON’ni stdin dan o‘qib, tool_input.command yoki tool_input.file_path ni tekshiradi, match’da exit 2 beradi. Write ham, Edit ham tekshiriladi. Zararsiz ruxsatli va bloklangan fixture’da sinang; Python va skript haqiqatan boshlanishini tasdiqlang.

Bu leksik signal: qayta tartiblangan bayroq, skript, alias, yashirilgan buyruq, boshqa vosita va bilvosita yozishni o‘tkazishi, zararsiz iqtibosni rad etishi mumkin. OS/baza ruxsatini bermaydi yoki olmaydi. Production credential’ini agentdan tashqarida, bazani read-only rolda, sandbox’ni majburiy tuting; hook konfiguratsiyasini tahrirdan himoyalang. Rasmiy kirish va exit-code manbasini ko‘ring.

Ataylab istisno amalni ko‘rib chiqib, agentdan tashqarida mos tor hisobda bajaring. Shell o‘zgaruvchisi hujjatli hook-disable interfeysi emas; hook oddiy terminalni boshqarmaydi.

AI’ga qachon ruxsat berish kerak (va qachon bermaslik kerak)#

Anthropic --dangerously-skip-permissions bayrogʻini (YOLO rejimi nomi bilan ham tanilgan) “ishonchli muhitlar” uchun imkoniyat sifatida hujjatlashtiradi. 2026-yil voqeligida esa bu falokatga eltuvchi toʻgʻri yoʻl. Agent tasdiq soʻramasa, u:

• Istalgan Bash buyrugʻini tasdiqsiz bajaradi
• Fayllarni soʻramasdan yozadi
• Subagentni ishga tushirishi mumkin, u esa YOLO rejimini meros qilib oladi va uni bekor qilib boʻlmaydi

Uchinchi jihat eng makkoridir. Asosiy agentni YOLO bilan ishga tushirsangiz, subagentlari ham YOLO boʻladi va siz buni oʻzgartira olmaysiz. Bitta soʻrov va 10 ta parallel agent tizimingizda istalgan ishni qilishi mumkin.

Qoida:

Muqobil — nozik ruxsatlar. .claude/settings.json da:

{
  "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 nimalarga ruxsat borligini va yoʻqligini koʻradi. Har safar “ha” yoki “yoʻq” tugmasini bosishingiz shart emas — agent tez ishlaydi, chegaralarni esa siz nazorat qilasiz.

Keyingi qadam: xatchoʻp qilib qoʻyish uchun 7 daqiqalik tekshiruv roʻyxati#

Tekshiruv roʻyxati: “AI oʻchirib yubordi — nima qilaman?”

1. Haqiqiy buzuvchi yozuvchini darhol to‘xtating; child va remote amal ham to‘xtaganini tekshiring
2. Qayta yuklamang; o‘chgan faylni ochiq tutgan aloqasiz jarayonni saqlang
3. Vaqt va buyruq dalilini tekshirilgan alohida qurilmaga yozing
4. Qolgan fayl, Git metama’lumoti va tegishli seans logini shu qurilmaga nusxalang
5. Saqlangan nusxada git reflog --all ko‘rib, tekshirilgan commit’ni alohida worktree’ga oching
6. Git yordam bermasa — saqlangan nusxada git fsck --lost-found
7. Baza: PITR (AWS/Yandex/Supabase) yoki so‘nggi snapshot
8. Fayl: Mac’da Time Machine, Linux’da lsof
9. Oxirgi chora: provayder yordami va S3 versiyalash
10. Tiklagach, oldini olish qoidalarini sozlang

Keyingi qadam — tizimli himoya:

• Claude Code’da Plan Mode — agent buzuvchi amaldan oldin reja tuzishi uchun
• Claude Code’da Hooks — xavfli buyruqlarni toʻsish uchun tayyor shablonlar
• Claude Code’dagi oʻzgarishlarni qanday qaytarish kerak — /rewind, git va qaytarishning 5 ta standart usuli boʻyicha batafsil qoʻllanma
• Claude Code’da xavfsizlik tekshiruvi — kod xavfsizligini muntazam tekshirish

Ailoot’ni oching.