# AI ลบฐานข้อมูล: แผนกู้คืนภายใน 7 นาที > ควรทำอย่างไรหลังข้อมูลถูกลบ: หยุดเอเจนต์ บันทึกรายละเอียดเหตุการณ์ ใช้ git reflog, PITR, สแนปช็อต และการกู้คืนไฟล์ พร้อมตัวอย่างและมาตรการป้องกัน Source: https://ailoot.ai/blog/th/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/th/ai-deleted-database-recovery/ Language: th Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-a0a99e91d0b0be5db7680a5f2ceda1c9b2e5b6db38960f4cb046354b256eebc3
ประเด็นสำคัญ เอเจนต์ AI เพิ่งลบฐานข้อมูล ไฟล์ หรือสภาพแวดล้อมโปรดักชันทั้งหมดของคุณ 7 นาทีแรกจะเป็นตัวกำหนดว่าคุณจะกู้คืนข้อมูลได้หรือสูญเสียข้อมูลไปตลอดกาล คู่มือนี้มีคำสั่งเฉพาะสำหรับแต่ละนาที ให้หยุดเอเจนต์ก่อน จากนั้นบันทึกรายละเอียดเหตุการณ์ แล้วจึงกู้คืน อย่าตื่นตระหนก—ทำตามรายการตรวจสอบ
[ดูข้อมูลเชิงปฏิบัติเกี่ยวกับการใช้งาน Ailoot ได้ในเอกสารประกอบ](https://ailoot.ai/docs/). ## สิ่งที่ควรทำในนาทีแรก: หยุด อย่าตื่นตระหนก
ประเด็นสำคัญ หยุดผู้เขียนที่กำลังทำลายข้อมูลทันที รวม child process ที่ยังทำต่อหลังเอเจนต์หยุด อย่ารีบูตหรือปิดโปรเซสไม่เกี่ยวข้องที่อาจถือไฟล์ลบเปิดอยู่ ไม่รับประกันการกู้ เพราะการเขียนทับกับ SSD discard/TRIM ทำให้กู้ไม่ได้ เก็บหลักฐานกับข้อมูลที่รอดบนอุปกรณ์แยกที่ตรวจแล้วก่อนเปลี่ยนสำเนาเสีย
เมื่อเกิดเหตุการณ์เช่นนี้กับคุณ **สิ่งแรกที่ต้องทำคือหยุดเอเจนต์** อย่าพยายามย้อนการกระทำของเอเจนต์ด้วยตัวเอง อย่าสั่งให้เอเจนต์ “กู้คืนทุกอย่าง” และอย่าป้อนพรอมป์ต์ใหม่ การกระทำแต่ละครั้งที่เอเจนต์ทำต่อจากนี้อาจเขียนทับบล็อกบนดิสก์ที่ยังเก็บข้อมูลของคุณอยู่ 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: บันทึกให้ชัดเจนว่าเกิดอะไรขึ้น
ประเด็นสำคัญ วินิจฉัยก่อนกู้คืน หากไม่เข้าใจอย่างชัดเจนว่า “อะไรถูกลบ ใครลบ เมื่อไร และใช้คำสั่งใด” คุณจะกู้คืนอย่างมืดบอดและอาจทำลายข้อมูลที่ยังอยู่ครบ เปิดหน้าต่างเทอร์มินัลใหม่ (ไม่ใช่หน้าต่างที่เอเจนต์กำลังทำงานอยู่) แล้วรัน `git status`, `git log --since` และ `ps aux | grep claude` คัดลอกโฟลเดอร์ `~/.claude/projects/` ทันที—โฟลเดอร์นี้มีบันทึกเซสชันทั้งหมดของเอเจนต์ ซึ่งอาจช่วยในการกู้คืน
เปิดหน้าต่างเทอร์มินัลใหม่ ไม่ใช่หน้าต่างที่เอเจนต์กำลังทำงานอยู่—ให้เปิดอีกหน้าต่างหนึ่ง รันคำสั่งสามรายการนี้ตามลำดับ **1. บันทึกสิ่งที่เปลี่ยนแปลงในรีโพซิทอรี git ให้ชัดเจน:** ```bash git status git log --since="30 minutes ago" --all --oneline ``` ไฟล์ tracked ที่ถูกลบอาจยังอยู่ index หรือ commit ก่อน restore ใด ๆ ต้องเก็บ working tree ปัจจุบันรวม untracked กับ ignored การ restore ที่เดิมอาจทับการแก้ที่รอด ให้ตรวจและกู้ในสำเนาแยก **2. ตรวจสอบว่าโปรเซสของเอเจนต์ใดกำลังทำงานอยู่:** ```bash ps aux | grep -i claude ps aux | grep -i cursor ``` ระบุโปรเซสที่ยังเขียนอันตรายจริง การตรงชื่ออย่างเดียวไม่พอ หยุดแล้วตรวจว่าหยุด คงโปรเซสไม่เกี่ยวข้องที่มีไฟล์เปิดมีประโยชน์ หากหยุดปกติไม่ได้และยังทำลาย อาจจำเป็นต้องบังคับ terminate **3. บันทึกบันทึกเซสชันของเอเจนต์:** Claude Code เก็บเซสชัน JSONL ไว้ใน `~/.claude/projects/` ส่วน Cursor เก็บไว้ใน `~/.cursor/ คัดลอกไว้ **เดี๋ยวนี้**: ```bash cp -r ~/.claude/projects /external/incident-evidence/claude-projects ``` แทน `/external/incident-evidence/` ด้วยโฟลเดอร์หลักฐานที่มีอยู่บนอุปกรณ์ mounted แยกซึ่งตรวจแล้ว ห้ามสำรองบน volume กระทบหรือทับหลักฐานเดิม โฟลเดอร์นี้มีบทสนทนากับเอเจนต์ตามจริง—คำสั่งที่รัน คำตอบที่ให้ และลำดับเหตุการณ์ นี่คือแหล่งข้อมูลหลักสำหรับตรวจสอบเหตุการณ์ และอาจใช้กู้คืนไฟล์ที่ถูกลบจากบริบทที่เอเจนต์เห็นได้ (ดูขั้นตอนที่ 4) ## นาทีที่ 4: git reflog—โอกาสที่ดีที่สุดของคุณ
ประเด็นสำคัญ Reflog หา commit ที่หายจากประวัติ branch ได้ แต่ไม่เก็บไฟล์ working tree ที่ยังไม่ commit หลังเก็บข้อมูลที่รอดกับ Git metadata บนอุปกรณ์แยก ให้ตรวจ repository copy และกู้ commit ที่ยืนยันใน worktree แยก ห้ามเริ่มด้วย reset working tree เสีย
`git reflog` บันทึกการเคลื่อน local references ระหว่างที่รายการยังถูกเก็บ อายุและการ prune ต่างกัน และ unreachable objects ถูกลบได้ จึงไม่ใช่ archive รับประกันทุก commit ในอดีต ทำขั้นกู้ด้านล่างจาก repository copy ที่เก็บบนอุปกรณ์แยก **ขั้นตอนที่ 1. ดูบันทึก:** ```bash 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 กับปลายทางที่ยังไม่ใช้: ```bash 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 ทางการ](https://git-scm.com/docs/git-worktree) **หาก reflog ถูกล้างไปด้วย (เอเจนต์รัน `git gc` ไปแล้ว):** ```bash git fsck --lost-found ``` คำสั่งนี้ค้นหา commits และ blobs (ออบเจ็กต์ไฟล์) ที่ “หายไป” และไม่ได้ผูกกับ branch ใดแล้ว โดยจะปรากฏใน `.git/lost-found/commit/` และ `.git/lost-found/other/` หากต้องการกู้คืนไฟล์จากที่นั่น: ```bash git cat-file -p > recovered-file.ext ``` **กรณีที่ git reflog ช่วยไม่ได้:** - ไฟล์อยู่ใน working tree เท่านั้น โดยไม่มี commit หรือ stash → reflog หาไม่เจอ - ผ่านไปเกิน 90 วัน (ค่า `gc.reflogExpire` มาตรฐาน) และมีการรัน `git gc` แล้ว - รีโพซิทอรีทั้งหมดถูกลบ (`rm -rf .git`)—กรณีนี้ต้องใช้ Time Machine หรือสแนปช็อต ## นาทีที่ 5: กู้คืนฐานข้อมูลจากแบ็กอัป
ประเด็นสำคัญ PostgreSQL Point-In-Time Recovery (PITR) กู้คืนฐานข้อมูลไปยังเวลาใดก็ได้ภายในช่วง 7–35 วัน ใช้ได้กับ Yandex Cloud Managed Postgres, AWS RDS, Supabase Pro และงาน `pg_dump` cron ภายในเครื่องบน Coolify ข้อกำหนดสำคัญคือ ต้องเปิดใช้ PITR **ก่อน** เกิดเหตุการณ์; คุณเปิดย้อนหลังไม่ได้ ให้กู้คืนไปยังอินสแตนซ์ใหม่เสมอ อย่ากู้คืนทับฐานข้อมูลที่กำลังใช้งาน เพื่อไม่ให้การย้อนกลับทำลายข้อมูลเพิ่ม หากไม่ได้เปิดใช้ PITR ให้ใช้สแนปช็อตล่าสุด
ฐานข้อมูลถูกลบด้วย `DROP DATABASE`, `DROP TABLE` หรือ `DELETE FROM ... WHERE ...` (โดยไม่มีเงื่อนไข WHERE) ควรทำอย่างไร? **ขั้นตอนที่ 1. ตรวจสอบว่าผู้ให้บริการของคุณมี PITR หรือไม่:** | ผู้ให้บริการ | ช่วงเวลา PITR | คำสั่งกู้คืน | |----|----|----| | AWS RDS | 1–35 วัน (กำหนดค่าได้) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 วัน (ค่าเริ่มต้น) | กู้คืนจากแบ็กอัปในคอนโซล + ระบุเวลา | | Supabase Pro | 7 วัน (เฉพาะ Pro+) | UI: Database → Backups → Restore | | Coolify + pg_dump ในเครื่อง | ตามตาราง cron | `pg_restore -d new_db backup.dump` | **ขั้นตอนที่ 2. กู้คืนไปยังอินสแตนซ์ใหม่ ไม่ใช่อินสแตนซ์เดิม:** อย่ากู้คืนทับฐานข้อมูลที่กำลังใช้งาน สร้างอินสแตนซ์ใหม่จากแบ็กอัป แล้วเปลี่ยนแอปพลิเคชันให้ใช้ฐานข้อมูลนั้น หากเกิดปัญหา คุณสามารถเปลี่ยน DNS กลับได้ **ขั้นตอนที่ 3. หากไม่ได้เปิดใช้ PITR ให้ใช้สแนปช็อตล่าสุด:** ```bash # 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 และสแนปช็อตดิสก์
ประเด็นสำคัญ หากไฟล์ถูกลบจากดิสก์—ไม่ใช่จาก git หรือฐานข้อมูล—มีวิธีกู้คืนที่ใช้ได้จริงสามวิธี บน macOS ใช้ Time Machine ที่มีสแนปช็อตรายชั่วโมง (หากแล็ปท็อปเชื่อมต่อกับ Time Capsule หรือไดรฟ์ภายนอก) บน Linux ให้รัน `sudo lsof | grep deleted`—อาจดึงไฟล์ที่โปรเซสยังเปิดค้างไว้อยู่ได้ (มีโอกาส 95%); คัดลอกผ่าน `/proc/PID/fd/N` สำหรับกรณีสำคัญ ให้สร้างสแนปช็อตของพาร์ทิชันทั้งหมดด้วย `dd` แล้วกู้คืนด้วย `extundelete` หรือ `photorec`
**macOS—Time Machine:** ```bash # 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—ไฟล์ถูกลบ แต่โปรเซสยังเปิดไฟล์อยู่:** ```bash # 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`:** ```bash lsof | grep deleted ``` การคัดลอกไฟล์ทำได้ยากกว่า (ไม่มี `/proc/`) แต่ทำได้ด้วย `lldb`: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **สแนปช็อตดิสก์ทั้งลูก (Linux, วิธีสุดท้าย):** ```bash sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress ``` คำสั่งนี้บันทึกพาร์ทิชันทั้งหมดเป็นไฟล์อิมเมจ จากนั้นกู้คืนด้วย `extundelete` หรือ `photorec` โอกาสกู้คืนขึ้นอยู่กับปริมาณข้อมูลที่เขียนลงดิสก์ตั้งแต่ลบไฟล์ หากไม่มีการเขียนข้อมูลเลย โอกาสอยู่ที่ 80–90% หากดิสก์ทำงานมาแล้วหนึ่งชั่วโมง โอกาสอยู่ที่ 20–30% ## นาทีที่ 7: หากไม่มีแบ็กอัปควรทำอย่างไร
ประเด็นสำคัญ ไม่มีแบ็กอัป, git reflog ว่างเปล่า และมีข้อมูลใหม่เขียนทับดิสก์ไปแล้ว ยังเหลือทางเลือกสุดท้ายสองทาง: ติดต่อฝ่ายสนับสนุนของผู้ให้บริการ (AWS, Yandex Cloud และ Google Cloud กู้คืนข้อมูลจากที่เก็บข้อมูลภายในเป็นระยะ) หรือกู้คืนผ่านการทำเวอร์ชันของ S3 (หากเปิดใช้ไว้ ทุกเวอร์ชันยังอยู่จริง)
**ตัวเลือกที่ 1—ติดต่อฝ่ายสนับสนุนของผู้ให้บริการ:** AWS, Yandex Cloud, Google Cloud และ DigitalOcean กู้คืนข้อมูลจากที่เก็บข้อมูลภายในเป็นระยะ แม้หลังเกิดเหตุร้ายกับลูกค้า โดยเฉพาะในแพ็กเกจแบบชำระเงิน เปิดทิกเก็ตฝ่ายสนับสนุน ระบุเวลาที่เกิดเหตุอย่างแม่นยำ และแนบภาพหน้าจอสถานะ วิธีนี้มักได้ผลกับผู้ให้บริการรายใหญ่ที่เก็บแบ็กอัปอัตโนมัติไว้ในระบบ โอกาสสำเร็จอยู่ที่ 40–60%; ระยะเวลารอตอบกลับคือ 24–72 ชั่วโมง **ตัวเลือกที่ 2—การทำเวอร์ชันของ S3:** หากไฟล์อยู่ใน S3 (หรือ Yandex Object Storage) และเปิดใช้การทำเวอร์ชันไว้ ทุกเวอร์ชัน **ยังอยู่จริง**; ระบบเพียงทำเครื่องหมายว่า “ถูกลบ” ```bash # 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 แบบง่าย: ```bash # In crontab, every Sunday at 03:00: 0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/ ``` ทำได้ฟรี และช่วยคุณได้เมื่อ “ทุกอย่างหายไป ไม่มีแบ็กอัป และ reflog ว่างเปล่า” ## 7 กฎเพื่อป้องกันไม่ให้เหตุการณ์นี้เกิดขึ้นอีก
ประเด็นสำคัญ เจ็ดกฎที่ป้องกันไม่ให้เอเจนต์ AI ลบฐานข้อมูลหรือโค้ดของคุณ ใช้ Plan Mode ก่อนทำสิ่งที่ทำลายข้อมูล ใช้ hooks ที่ทดสอบเพื่อตรวจรูปคำสั่งอันตรายที่เลือก ร่วมกับขีดจำกัดสิทธิ์ที่บังคับ ให้เอเจนต์ใช้ผู้ใช้ฐานข้อมูลแบบอ่านอย่างเดียว สร้าง commit อัตโนมัติหลังแก้ไฟล์ทุกครั้ง ใช้โฟลเดอร์ sandbox ที่แยกไว้สำหรับการทดลอง สร้างสแนปช็อตดิสก์ด้วย `restic` ทุกชั่วโมง และเก็บเซสชัน JSONL ในไดรฟ์ภายนอก
**1. ใช้ Plan Mode ก่อนการกระทำที่ทำลายข้อมูลทุกครั้ง** ใน Claude Code: ```bash claude --plan ``` เอเจนต์จะสร้างแผน **ก่อน** ลงมือ คุณอ่านแผน เห็น `DROP TABLE users` แล้วก็ยกเลิกได้ หากไม่มี Plan Mode เอเจนต์จะตัดสินใจเองและทำงานภายในเสี้ยวมิลลิวินาที ดูเพิ่มเติมในคู่มือ [Plan Mode ใน Claude Code](https://ailoot.ai/blog/th/claude-code-plan-mode/) **2. Hooks เป็นตัวเตือนเสริม** ใช้ PreToolUse ที่ทดสอบซึ่งอ่าน event JSON จาก stdin และคืน exit 2 เมื่อพบการกระทำเสี่ยงสูง ตัวอย่างครบด้านล่างครอบคลุม Bash, Write และ Edit แต่ไม่ใช่ขอบเขตปลอดภัยและพลาดการกระทำอ้อมได้ ต้องจำกัดสิทธิ์ฐานข้อมูลกับ sandbox ดู[เอกสาร hook ทางการ](https://code.claude.com/docs/en/hooks-guide) และ[คู่มือ Hooks ใน Claude Code 2026](https://ailoot.ai/blog/th/claude-code-hooks/) **3. สร้างผู้ใช้ DB แบบอ่านอย่างเดียวให้เอเจนต์** สร้างผู้ใช้แยกสำหรับเอเจนต์ โดย **ไม่มี** สิทธิ์ `DROP`, `TRUNCATE` หรือ `DELETE`: ```sql 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` ได้: ```json { "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` ทุกชั่วโมง** ```bash # 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 พร้อมใช้สำหรับบล็อกคำสั่งอันตราย
ประเด็นสำคัญ ตัวอย่างด้านล่างเป็น PreToolUse tripwire สำหรับข้อความคำสั่ง Bash ที่เลือกกับ Write/Edit paths อ่อนไหว อ่าน stdin JSON และคืน exit 2 เมื่อ matched อาจพลาดการกระทำอ้อมหรือพราง จึงเสริม sandbox กับ credentials จำกัด ไม่แทน ต้องรวมกับ config เดิมและทดสอบก่อนใช้
รวมรายการนี้ใน `.claude/settings.json` โดยไม่ทับ hooks เดิม: ```json { "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 ต่อไปนี้: ```python 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 ทางการ](https://code.claude.com/docs/en/hooks) การกระทำพิเศษที่ตั้งใจต้องรีวิวแล้วรันนอกเอเจนต์ด้วยบัญชีจำกัดที่เหมาะสม ตัวแปร shell ไม่ใช่อินเทอร์เฟซปิด hook ตามเอกสาร และ hooks ไม่ควบคุมคำสั่งเทอร์มินัลธรรมดา ## ควรให้ AI มีสิทธิ์เมื่อไร (และเมื่อไรไม่ควร)
ประเด็นสำคัญ ห้ามให้เอเจนต์ใช้แฟล็ก `--dangerously-skip-permissions` กับโปรเจกต์ที่มีข้อมูลจริงโดยเด็ดขาด ในโหมด YOLO นี้ การป้องกันทั้งหมดถูกปิดใช้งาน เอเจนต์รันคำสั่ง Bash ใดก็ได้และเขียนไฟล์ได้โดยไม่ต้องยืนยัน และเอเจนต์ย่อยที่ถูกเรียกใช้ก็รับช่วง YOLO โดยไม่มีทางปิดการทำงานได้ ใช้ YOLO เฉพาะในโฟลเดอร์ sandbox สำหรับทดลองเซิร์ฟเวอร์ MCP หรือพรอมป์ต์ใหม่กับข้อมูลจำลอง สำหรับกรณีอื่น ให้ใช้สิทธิ์แบบเจาะจงผ่าน `.claude/settings.json` พร้อมกฎ `allow` และ `deny` ที่ระบุชัดเจน
Anthropic ระบุแฟล็ก `--dangerously-skip-permissions` (หรือที่เรียกว่าโหมด YOLO) ว่าเป็นตัวเลือกสำหรับ “สภาพแวดล้อมที่เชื่อถือได้” แต่ในความเป็นจริงของปี 2026 นี่คือ **เส้นทางตรงสู่หายนะ** เมื่อเอเจนต์ไม่ต้องขออนุญาต มันจะ: - รันคำสั่ง Bash ใดก็ได้โดยไม่ต้องยืนยัน - เขียนไฟล์โดยไม่ถาม - เรียกใช้เอเจนต์ย่อยที่ **รับช่วง** YOLO และไม่มีทางยกเลิกได้ ข้อที่สามแฝงอันตรายที่สุด หากเริ่มเอเจนต์หลักด้วย YOLO เอเจนต์ย่อยก็จะใช้ YOLO ด้วย และคุณไม่มีทางบังคับใช้การตั้งค่าอื่นได้ พรอมป์ต์เดียว—และเอเจนต์คู่ขนาน 10 ตัวที่ทำงานต่อเนื่องกันเป็นทอด ๆ ก็สามารถทำอะไรก็ได้ในระบบของคุณ **กฎ:** | สถานการณ์ | ใช้ YOLO ได้หรือไม่? | |--------------------------------------------------|--------------------| | ทดลองเซิร์ฟเวอร์ MCP ใหม่ในโฟลเดอร์ sandbox | ✅ ได้ | | ทดสอบพรอมป์ต์ใหม่กับข้อมูลจำลอง | ✅ ได้ | | ทำงานกับไฟล์โปรเจกต์จริง | ❌ ไม่ได้ | | คำสั่งใด ๆ ที่แตะฐานข้อมูล | ❌ ห้ามเด็ดขาด | | ดีพลอยขึ้นโปรดักชัน | ❌ ห้ามเด็ดขาด | | จัดการโครงสร้างพื้นฐาน (AWS, Yandex Cloud) | ❌ ห้ามเด็ดขาด | **ทางเลือก—กำหนดสิทธิ์อย่างเจาะจง** ใน `.claude/settings.json`: ```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 นาทีสำหรับบันทึกไว้
ประเด็นสำคัญ บันทึกคู่มือนี้ไว้ในบุ๊กมาร์กเดี๋ยวนี้ เมื่อเกิดเหตุขึ้น ให้เปิดหน้าเว็บแล้วทำตามรายการตรวจสอบ 10 ข้อตามลำดับ ซึ่งจะช่วยประหยัดเวลา 30 นาทีที่ต้องตื่นตระหนก และป้องกันไม่ให้คุณเผลอเขียนทับข้อมูลที่อาจยังกู้คืนได้ หลังจากกู้คืนแล้ว กลับมาตั้งค่ากฎป้องกันทั้ง 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](https://ailoot.ai/blog/th/claude-code-plan-mode/)—เพื่อให้เอเจนต์วางแผน **ก่อน** การกระทำที่ทำลายข้อมูล - [Hooks ใน Claude Code](https://ailoot.ai/blog/th/claude-code-hooks/)—เทมเพลตพร้อมใช้สำหรับบล็อกคำสั่งอันตราย - [วิธีย้อนการเปลี่ยนแปลงใน Claude Code](https://ailoot.ai/blog/th/claude-code-undo-changes/)—คู่มือโดยละเอียดเกี่ยวกับ `/rewind`, git และ 5 วิธีมาตรฐานในการย้อนกลับ - [การตรวจสอบความปลอดภัยใน Claude Code](https://ailoot.ai/blog/th/claude-code-security-review/)—ตรวจสอบความปลอดภัยของโค้ดเป็นประจำ
### แหล่งที่มา - [เอกสาร Hooks ของ Anthropic Claude Code](https://code.claude.com/docs/en/hooks-guide) - [เอกสาร Plan Mode ของ Anthropic Claude Code](https://code.claude.com/docs/en/common-workflows) - [เอกสาร PostgreSQL Point-In-Time Recovery (PITR)](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS—กู้คืนอินสแตนซ์ DB ไปยังจุดเวลา](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL—การแบ็กอัปและกู้คืน](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [เอกสาร git reflog](https://git-scm.com/docs/git-reflog) - [Git fsck—โหมด `--lost-found`](https://git-scm.com/docs/git-fsck)
[ไปที่ Ailoot](https://ailoot.ai/). ## คำถามที่พบบ่อย ### ควรรอคำสั่งปัจจุบันของเอเจนต์ทำเสร็จหรือไม่? ไม่ควร หยุดผู้เขียนทำลายทันทีและตรวจว่าคำสั่งลูก remote หรือฐานข้อมูลหยุดแล้ว คงโปรเซสไม่เกี่ยวข้องที่อาจถือไฟล์ลบกู้ได้ การหยุดเอเจนต์อย่างเดียวอาจเหลือผู้เขียนอื่นทำงาน ### เริ่มกู้ด้วย git reset --hard ได้หรือไม่? ก่อนอื่นเก็บไฟล์ tracked, untracked, ignored ที่รอดกับ Git metadata บนอุปกรณ์แยก ตรวจ repository copy และกู้ commit ที่ยืนยันใน worktree แยก hard reset ที่เดิมอาจทำลายการแก้ยังไม่ commit ที่รอด ## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน. Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ