AI ลบฐานข้อมูล: แผนกู้คืนภายใน 7 นาที

ดูข้อมูลเชิงปฏิบัติเกี่ยวกับการใช้งาน Ailoot ได้ในเอกสารประกอบ.

สิ่งที่ควรทำในนาทีแรก: หยุด อย่าตื่นตระหนก#

เมื่อเกิดเหตุการณ์เช่นนี้กับคุณ สิ่งแรกที่ต้องทำคือหยุดเอเจนต์ อย่าพยายามย้อนการกระทำของเอเจนต์ด้วยตัวเอง อย่าสั่งให้เอเจนต์ “กู้คืนทุกอย่าง” และอย่าป้อนพรอมป์ต์ใหม่ การกระทำแต่ละครั้งที่เอเจนต์ทำต่อจากนี้อาจเขียนทับบล็อกบนดิสก์ที่ยังเก็บข้อมูลของคุณอยู่

1. ปิดเทอร์มินัลของเอเจนต์

   กด Ctrl+C หยุดคำสั่งอันตรายทันที อย่ารอการลบจบ การหยุดเอเจนต์อาจไม่หยุดคำสั่งลูก งาน remote หรือคิวรีฐานข้อมูล ต้องระบุผู้เขียนจริงแล้วหยุดหรือยกเลิก หากยังทำลายให้ยกระดับการ terminate แต่คงโปรเซสไม่เกี่ยวที่ถือไฟล์เปิดซึ่งอาจกู้ได้

2. อย่ารีบูตแล็ปท็อป

   ข้อมูลลบอาจกู้ได้ แต่ขึ้นกับ storage พฤติกรรมฐานข้อมูล SSD discard/TRIM และการเขียนภายหลัง ลดการเขียน volume ที่กระทบ อย่าสมมติว่า bytes ยังอยู่

3. อย่าปิดโปรเซสที่เปิดอยู่

   คงโปรเซสไม่เกี่ยวข้องที่เปิดไฟล์ลบ เพราะอาจกู้ผ่าน file descriptor ได้ แต่ไม่ใช้กับผู้เขียนที่ทำลาย ต้องหยุดผู้นั้นก่อน ห้ามปล่อยการลบต่อเพียงเพื่อรักษา open handle

4. เริ่มบันทึกหน้าจอ

   บันทึกเวลาตรง path ที่กระทบ และผลคำสั่งที่เห็น หากอัดภาพหรือคัด logs ให้เก็บอุปกรณ์แยกที่ตรวจแล้ว ไม่ใช่ volume เสีย เก็บไฟล์ tracked, untracked, ignored ที่รอดกับ Git metadata ที่นั่นก่อนกู้

จากนี้มีเวลาอีก 6 นาทีสำหรับการกู้คืน มาเริ่มกันเลย

นาทีที่ 2–3: บันทึกให้ชัดเจนว่าเกิดอะไรขึ้น#

เปิดหน้าต่างเทอร์มินัลใหม่ ไม่ใช่หน้าต่างที่เอเจนต์กำลังทำงานอยู่—ให้เปิดอีกหน้าต่างหนึ่ง รันคำสั่งสามรายการนี้ตามลำดับ

1. บันทึกสิ่งที่เปลี่ยนแปลงในรีโพซิทอรี git ให้ชัดเจน:

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

ไฟล์ tracked ที่ถูกลบอาจยังอยู่ index หรือ commit ก่อน restore ใด ๆ ต้องเก็บ working tree ปัจจุบันรวม untracked กับ ignored การ restore ที่เดิมอาจทับการแก้ที่รอด ให้ตรวจและกู้ในสำเนาแยก

2. ตรวจสอบว่าโปรเซสของเอเจนต์ใดกำลังทำงานอยู่:

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

ระบุโปรเซสที่ยังเขียนอันตรายจริง การตรงชื่ออย่างเดียวไม่พอ หยุดแล้วตรวจว่าหยุด คงโปรเซสไม่เกี่ยวข้องที่มีไฟล์เปิดมีประโยชน์ หากหยุดปกติไม่ได้และยังทำลาย อาจจำเป็นต้องบังคับ terminate

3. บันทึกบันทึกเซสชันของเอเจนต์:

Claude Code เก็บเซสชัน JSONL ไว้ใน ~/.claude/projects/ ส่วน Cursor เก็บไว้ใน `~/.cursor/ คัดลอกไว้ เดี๋ยวนี้:

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

แทน /external/incident-evidence/ ด้วยโฟลเดอร์หลักฐานที่มีอยู่บนอุปกรณ์ mounted แยกซึ่งตรวจแล้ว ห้ามสำรองบน volume กระทบหรือทับหลักฐานเดิม โฟลเดอร์นี้มีบทสนทนากับเอเจนต์ตามจริง—คำสั่งที่รัน คำตอบที่ให้ และลำดับเหตุการณ์ นี่คือแหล่งข้อมูลหลักสำหรับตรวจสอบเหตุการณ์ และอาจใช้กู้คืนไฟล์ที่ถูกลบจากบริบทที่เอเจนต์เห็นได้ (ดูขั้นตอนที่ 4)

นาทีที่ 4: git reflog—โอกาสที่ดีที่สุดของคุณ#

git reflog บันทึกการเคลื่อน local references ระหว่างที่รายการยังถูกเก็บ อายุและการ prune ต่างกัน และ unreachable objects ถูกลบได้ จึงไม่ใช่ archive รับประกันทุก commit ในอดีต ทำขั้นกู้ด้านล่างจาก repository copy ที่เก็บบนอุปกรณ์แยก

ขั้นตอนที่ 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. กู้ใน working tree แยก:

หลังคัด repository และงานที่เหลือทั้งหมดไปอุปกรณ์แยก ให้รันจาก repository copy ที่เก็บแล้ว แทนค่าด้วย commit SHA ตรงที่ตรวจใน reflog และเลือก branch กับปลายทางที่ยังไม่ใช้:

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

ตรวจไฟล์ใน ../recovery-check เทียบไฟล์ยังไม่ commit ที่เก็บไว้ก่อนคัดอะไรกลับ คำสั่ง checkout commit ที่เลือกแยก ไม่ reset working tree เสีย Linked worktrees แชร์ Git object store ของ repository ที่คัด จึงเป็นที่กู้ทำงาน ไม่ใช่สำรองอิสระ ดูเอกสาร git-worktree ทางการ

หาก reflog ถูกล้างไปด้วย (เอเจนต์รัน git gc ไปแล้ว):

git fsck --lost-found

คำสั่งนี้ค้นหา commits และ blobs (ออบเจ็กต์ไฟล์) ที่ “หายไป” และไม่ได้ผูกกับ branch ใดแล้ว โดยจะปรากฏใน .git/lost-found/commit/ และ .git/lost-found/other/ หากต้องการกู้คืนไฟล์จากที่นั่น:

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

กรณีที่ git reflog ช่วยไม่ได้:

• ไฟล์อยู่ใน working tree เท่านั้น โดยไม่มี commit หรือ stash → reflog หาไม่เจอ
• ผ่านไปเกิน 90 วัน (ค่า gc.reflogExpire มาตรฐาน) และมีการรัน git gc แล้ว
• รีโพซิทอรีทั้งหมดถูกลบ (rm -rf .git)—กรณีนี้ต้องใช้ Time Machine หรือสแนปช็อต

นาทีที่ 5: กู้คืนฐานข้อมูลจากแบ็กอัป#

ฐานข้อมูลถูกลบด้วย DROP DATABASE, DROP TABLE หรือ DELETE FROM ... WHERE ... (โดยไม่มีเงื่อนไข WHERE) ควรทำอย่างไร?

ขั้นตอนที่ 1. ตรวจสอบว่าผู้ให้บริการของคุณมี PITR หรือไม่:

ขั้นตอนที่ 2. กู้คืนไปยังอินสแตนซ์ใหม่ ไม่ใช่อินสแตนซ์เดิม:

อย่ากู้คืนทับฐานข้อมูลที่กำลังใช้งาน สร้างอินสแตนซ์ใหม่จากแบ็กอัป แล้วเปลี่ยนแอปพลิเคชันให้ใช้ฐานข้อมูลนั้น หากเกิดปัญหา คุณสามารถเปลี่ยน DNS กลับได้

ขั้นตอนที่ 3. หากไม่ได้เปิดใช้ PITR ให้ใช้สแนปช็อตล่าสุด:

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

# Restore from a snapshot:
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 แล้ว แบ็กอัปรายวันจะ หยุดถูกสร้าง พฤติกรรมนี้ขัดกับความคาดหมาย คุณอาจไม่มีแบ็กอัปเหลือเลย ตรวจสอบ Dashboard → Database → Backups เพื่อให้แน่ใจว่า PITR ทำงานอยู่และมีสแนปช็อตให้กู้คืนด้วย

นาทีที่ 6: Time Machine, lsof และสแนปช็อตดิสก์#

macOS—Time Machine:

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine สร้างสแนปช็อตทุกชั่วโมง เก็บสแนปช็อตรายชั่วโมงไว้หนึ่งวัน รายวันไว้หนึ่งสัปดาห์ และรายสัปดาห์ไว้โดยไม่มีกำหนด หากแล็ปท็อปเชื่อมต่อกับ Time Capsule หรือไดรฟ์ภายนอก โปรเจกต์ของคุณจะอยู่ในนั้นโดยมีความละเอียดเป็นรายชั่วโมง

Linux—ไฟล์ถูกลบ แต่โปรเซสยังเปิดไฟล์อยู่:

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /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—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
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 แบบง่าย:

# In crontab, every Sunday at 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 เอเจนต์จะตัดสินใจเองและทำงานภายในเสี้ยวมิลลิวินาที ดูเพิ่มเติมในคู่มือ Plan Mode ใน Claude Code

2. Hooks เป็นตัวเตือนเสริม ใช้ PreToolUse ที่ทดสอบซึ่งอ่าน event JSON จาก stdin และคืน exit 2 เมื่อพบการกระทำเสี่ยงสูง ตัวอย่างครบด้านล่างครอบคลุม Bash, Write และ Edit แต่ไม่ใช่ขอบเขตปลอดภัยและพลาดการกระทำอ้อมได้ ต้องจำกัดสิทธิ์ฐานข้อมูลกับ sandbox ดูเอกสาร hook ทางการ และคู่มือ Hooks ใน Claude Code 2026

3. สร้างผู้ใช้ DB แบบอ่านอย่างเดียวให้เอเจนต์ สร้างผู้ใช้แยกสำหรับเอเจนต์ โดย ไม่มี สิทธิ์ 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 hook PostToolUse ใน .claude/settings.json สามารถแสดงข้อความเตือนหลังการใช้ Write และ Edit ได้:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'ตรวจสอบ diff แล้ว commit ด้วยตนเองเฉพาะไฟล์ที่ตกลงกันไว้' >&2"
          }
        ]
      }
    ]
  }
}

ตัวอย่างนี้แสดงข้อความเตือนเท่านั้น ไม่เพิ่มไฟล์เข้า staging และไม่สร้าง commit ตรวจสอบ diff แล้ว commit ด้วยตนเองเฉพาะไฟล์ที่ตกลงกันไว้ reflog ไม่บันทึกการเปลี่ยนแปลงที่ยังไม่ได้ commit

5. ใช้โปรเจกต์ sandbox สำหรับการทดลอง อย่าให้เอเจนต์ทำงานในโปรเจกต์ที่มีข้อมูลลูกค้าจริง สร้างโฟลเดอร์ ~/sandbox-projects/ แยกต่างหาก พร้อมสำเนาโปรเจกต์และข้อมูลสังเคราะห์ ใช้โฟลเดอร์นี้ลองพรอมป์ต์ เอเจนต์ หรือเซิร์ฟเวอร์ MCP ใหม่ หากเกิดปัญหาก็ไม่เป็นไร

6. สร้างสแนปช็อตดิสก์ด้วย restic ทุกชั่วโมง

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

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

คุณจะได้แบ็กอัปรายชั่วโมงย้อนหลังเจ็ดวัน แบ็กอัปรายวันย้อนหลังสี่สัปดาห์ และย้อนกลับไปยังจุดใดก็ได้ในอดีต ทำได้ฟรีและใช้เวลาตั้งค่า 10 นาที

7. เก็บเซสชัน JSONL ของ Claude Code เป็นคลังถาวร กล่าวถึงไปแล้วข้างต้น แต่ขอย้ำเป็นกฎแยกต่างหาก: ตั้งเวลา rsync รายสัปดาห์เพื่อคัดลอก ~/.claude/projects/ ไปยังไดรฟ์ภายนอก ทำได้ฟรีและเพิ่มเพียงบรรทัดเดียวใน crontab

Hooks พร้อมใช้สำหรับบล็อกคำสั่งอันตราย#

รวมรายการนี้ใน .claude/settings.json โดยไม่ทับ hooks เดิม:

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

สร้าง .claude/hooks/check-risk.py ด้วย 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)

hook อ่าน event JSON ตามเอกสารจาก stdin ตรวจ tool_input.command หรือ tool_input.file_path และคืน exit 2 เมื่อ matched ตรวจทั้ง Write กับ Edit ทดสอบ fixture ปลอดภัยที่ผ่านกับที่ต้องบล็อกก่อนพึ่งใช้ และตรวจว่า Python กับสคริปต์ที่ตั้งเปิดจริง

นี่เป็นตัวตรวจข้อความที่อาจพลาด flags สลับลำดับ scripts, aliases คำสั่งพราง เครื่องมืออื่น หรือการเขียนอ้อม และอาจปฏิเสธตัวอย่างในเครื่องหมายคำพูดที่ไม่อันตราย ไม่เพิ่มหรือลดสิทธิ์ OS/ฐานข้อมูล เก็บ credentials production นอก environment เอเจนต์ ใช้ role ฐานข้อมูลอ่านอย่างเดียวกับ sandbox บังคับ และป้องกัน config hook จากการแก้ ดูอ้างอิง input กับ exit code ของ hook ทางการ

การกระทำพิเศษที่ตั้งใจต้องรีวิวแล้วรันนอกเอเจนต์ด้วยบัญชีจำกัดที่เหมาะสม ตัวแปร shell ไม่ใช่อินเทอร์เฟซปิด hook ตามเอกสาร และ hooks ไม่ควบคุมคำสั่งเทอร์มินัลธรรมดา

ควรให้ 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. หยุดผู้เขียนทำลายจริงทันที ตรวจว่า child, remote หรือ database operation หยุดแล้ว
2. อย่ารีบูต คงโปรเซสไม่เกี่ยวข้องที่เปิดไฟล์ลบอยู่
3. บันทึกเวลาเหตุการณ์กับหลักฐานคำสั่งบนอุปกรณ์แยกที่ตรวจแล้ว
4. คัดไฟล์ที่รอด Git metadata และ session logs ที่เกี่ยวไปอุปกรณ์แยกนั้น
5. ใน repository copy ที่เก็บแล้ว ตรวจ git reflog --all และกู้ commit ที่ยืนยันใน worktree แยก
6. หาก git ช่วยไม่ได้—git fsck --lost-found
7. ฐานข้อมูล: PITR (AWS/Yandex/Supabase) หรือสแนปช็อตล่าสุด
8. ไฟล์: Time Machine บน Mac, lsof บน Linux
9. ทางเลือกสุดท้าย: ฝ่ายสนับสนุนผู้ให้บริการ + การทำเวอร์ชันของ S3
10. หลังการกู้คืน ตั้งค่ากฎป้องกันทั้ง 7 ข้อในคู่มือนี้

ถัดไป—การป้องกันอย่างเป็นระบบ:

• Plan Mode ใน Claude Code—เพื่อให้เอเจนต์วางแผน ก่อน การกระทำที่ทำลายข้อมูล
• Hooks ใน Claude Code—เทมเพลตพร้อมใช้สำหรับบล็อกคำสั่งอันตราย
• วิธีย้อนการเปลี่ยนแปลงใน Claude Code—คู่มือโดยละเอียดเกี่ยวกับ /rewind, git และ 5 วิธีมาตรฐานในการย้อนกลับ
• การตรวจสอบความปลอดภัยใน Claude Code—ตรวจสอบความปลอดภัยของโค้ดเป็นประจำ

ไปที่ Ailoot.