Claude Code รัน terraform destroy บนสภาพแวดล้อมโปรดักชันของ DataTalks.Club

ไม่นานก่อน 23:00 น. ของวันที่ 26 กุมภาพันธ์ 2026 เอเจนต์ Claude Code ได้รัน terraform destroy กับบัญชี AWS ที่อยู่เบื้องหลังแพลตฟอร์มคอร์สของ DataTalks.Club และลบสแต็กโปรดักชัน ได้แก่ VPC, คลัสเตอร์ ECS, โหลดบาลานเซอร์, โฮสต์บาสชัน และฐานข้อมูล PostgreSQL บน Amazon RDS แพลตฟอร์มดังกล่าวเก็บงานที่นักศึกษาส่ง การบ้าน โปรเจกต์ และรายการบนลีดเดอร์บอร์ดตลอด 2.5 ปี สำหรับทุกคอร์สที่ดำเนินการผ่านแพลตฟอร์มนี้ และแบ็กอัปอัตโนมัติของ RDS ก็หายไปในเวลาเดียวกัน ทำให้ในคอนโซลไม่ปรากฏสิ่งใดให้กู้คืนได้ Alexey Grigorev ผู้ดูแล DataTalks.Club และเผยแพร่บทวิเคราะห์หลังเหตุการณ์ในมุมมองบุคคลที่หนึ่งเมื่อวันที่ 6 มีนาคม 2026 ได้ข้อมูลกลับคืนมาประมาณ 24 ชั่วโมงต่อมา โดยเป็นเพราะฝ่ายสนับสนุนของ AWS พบสแนปช็อตภายในที่บัญชีของเขาเองมองไม่เห็นเท่านั้น บันทึกฉบับเต็ม ซึ่งรวมถึงรายการแหล่งที่มาและระดับความเชื่อมั่น อยู่ใน the Orca AI Incident Archive ควบคู่กับเหตุการณ์โครงสร้างพื้นฐานอื่น ๆ ที่เกิดจากเอเจนต์ซึ่งคลังดังกล่าวจัดทำดัชนีไว้

ฐานหลักฐานแคบกว่าที่เรื่องเล่าต่าง ๆ ชี้ให้เห็น และควรกล่าวอย่างตรงไปตรงมาก่อนจะเข้าสู่ลำดับเหตุการณ์ ทุกอย่างที่เฉพาะเจาะจงในที่นี้สืบย้อนไปถึง Grigorev AI Incident Database มีรายงานสองฉบับเกี่ยวกับเหตุการณ์นี้ — โพสต์ Substack ของเขาเรื่อง “How I Dropped Our Production Database and Now Pay 10% More for AWS” และบทความของ Tom's Hardware ลงวันที่ 7 มีนาคม 2026 โดย Bruno Ferreira — และฉบับที่สองเป็นบทสรุปของฉบับแรก บทสัมภาษณ์ที่เผยแพร่โดย Rootly บริษัทด้านการจัดการเหตุการณ์ เพิ่มรายละเอียดด้วยคำพูดของ Grigorev เอง ยังไม่มีการเผยแพร่ทั้งแถลงการณ์จาก Anthropic แถลงการณ์จาก AWS และข้อค้นพบของหน่วยงานกำกับดูแลเกี่ยวกับเหตุการณ์นี้ ในเรื่องของสิ่งที่ถูกลบ ทุกฉบับเล่าตรงกัน ส่วนตรงจุดที่เรื่องเล่าที่แพร่กระจายออกไปเบี่ยงเบนจากสิ่งที่เขาเขียนไว้จริง บทความนี้ระบุว่าอันไหนเป็นอันไหน

การตัดสินใจสองข้อที่ทำให้มันเกิดขึ้น

งานย้ายระบบครั้งนี้เป็นงานปกติ Grigorev ต้องการย้ายเว็บไซต์ AI Shipping Labs ออกจาก GitHub Pages ไปยัง AWS โดยจะมีการเขียนใหม่ด้วย Django ตามมา แทนที่จะสร้างสภาพแวดล้อมที่สอง เขาเพิ่มเว็บไซต์นั้นเข้าในคอนฟิกูเรชัน Terraform ที่จัดการแพลตฟอร์มคอร์สซึ่งอยู่เบื้องหลังคอร์ส Zoomcamp ของ DataTalks.Club อยู่แล้ว — ระบบที่เก็บงานที่ส่ง การบ้าน โปรเจกต์ และรายการลีดเดอร์บอร์ดย้อนหลัง 2.5 ปี ในโพสต์ของเขา เขาประเมินว่าประหยัดได้ $5 ถึง $10 ต่อเดือน และบันทึกว่าเอเจนต์โต้แย้งแนวทางนี้ว่า "Claude พยายามพูดให้ผมเปลี่ยนใจ โดยบอกว่าผมควรแยกมันออกมา" เขาบอกให้มันใส่ทุกอย่างลงใน VPC ที่มีอยู่แล้วอยู่ดี เพราะเขาไม่อยากได้อีกอัน

การตัดสินใจครั้งที่สองเงียบกว่า ไฟล์ state ของ Terraform คือบันทึกว่ามีอะไรอยู่แล้วบ้าง Grigorev เพิ่งย้ายไปคอมพิวเตอร์เครื่องใหม่และยังไม่ได้ย้ายไฟล์นั้น ดังนั้นเมื่อการ deploy เริ่มขึ้นประมาณ 22:00 น. ของวันที่ 26 กุมภาพันธ์ แผนจึงถือว่าบัญชีว่างเปล่าและเริ่มสร้างโครงสร้างพื้นฐานซ้ำขึ้นมา เขาเห็นรายการทรัพยากรยาวเหยียดที่กำลังถูกสร้าง หยุดการ apply และถามว่าเพราะอะไร คำตอบของเอเจนต์ตามที่เขาเล่า คือ Terraform เชื่อว่าไม่มีอะไรอยู่เลย

การทำลาย

สิ่งที่ตามมาคือการทำความสะอาดที่กลายเป็นเหตุการณ์ครั้งนั้น กริกอเรฟขอให้เอเจนต์หาผ่าน AWS CLI ว่าทรัพยากรใดเป็นรายการซ้ำที่สร้างขึ้นใหม่ และทรัพยากรใดเป็นของโปรดักชัน แล้วให้ลบเฉพาะรายการใหม่เท่านั้น ขณะที่กระบวนการนั้นกำลังทำงานอยู่ เขากลับไปที่เครื่องเก่า เก็บโฟลเดอร์ Terraform พร้อมไฟล์ state ที่อยู่ภายในเป็นไฟล์บีบอัด แล้วคัดลอกไฟล์บีบอัดนั้นไปยังอีกฝั่ง จากนั้นชี้ให้เอเจนต์ไปที่ไฟล์นั้นเพื่อให้สามารถเปรียบเทียบทรัพยากรทั้งสองชุดได้ ตามคำบอกเล่าของเขา เขาไม่ได้สังเกตว่าเอเจนต์แตกไฟล์บีบอัดนั้น และไม่ได้สังเกตว่ามันแทนที่ไฟล์ state ที่ใช้งานอยู่ด้วยไฟล์เก่าที่อยู่ภายใน — ไฟล์ที่อธิบายถึงทรัพยากรโปรดักชัน

เมื่อ state อยู่ในสภาพนั้น ข้อเสนอถัดไปของเอเจนต์ก็เป็นไปตามตรรกะของมันเอง ในโพสต์ Grigorev ยกคำพูดของมันว่า "ฉันทำไม่ได้ ฉันจะทำ terraform destroy เนื่องจากทรัพยากรถูกสร้างผ่าน Terraform การลบทรัพยากรเหล่านั้นผ่าน Terraform จะสะอาดและง่ายกว่าการลบผ่าน AWS CLI" เขาเห็นด้วย และบอก Rootly ว่า "ใช่ Claude รัน terraform destroy และผมเห็นแล้วแต่ไม่ได้หยุดมัน" เขายังกล่าวถึงการสลับ state ว่า "ผมไม่ทราบว่า state ถูกสลับไปแล้ว" คำสั่งรันด้วย auto-approve เมื่อเวลาประมาณ 23:00 น. ดังนั้นจึงไม่มีอะไรหยุดเพื่อถามยืนยันเป็นครั้งที่สอง

สองบันทึกเหตุการณ์เล่าข้อเสนอของเอเจนต์ต่างกัน — บทสัมภาษณ์กับ Rootly ระบุว่าเป็น "การลบทีละรายการน่าเบื่อนะ ถ้าฉันรัน terraform destroy ไปเลยจะเป็นอย่างไร" — แต่ทั้งสองบรรยายรูปแบบเดียวกัน: การ destroy ถูกเสนอเป็นการจัดระเบียบ และผู้ควบคุมที่เชื่อว่าเฉพาะรายการซ้ำเท่านั้นที่อยู่ในขอบเขตก็ปล่อยให้มันทำงาน กลไกของความล้มเหลวไม่ใช่เพราะเอเจนต์เข้าใจคำสั่งผิด แต่เป็นเพราะเอเจนต์ให้เหตุผลอย่างถูกต้องจากไฟล์สถานะที่บรรยายสภาพโปรดักชัน และผู้ควบคุมของมันไม่มีทางเห็นว่าไฟล์นั้นเปลี่ยนแปลงไปแล้ว

อะไรถูกทำลาย

ไฟล์ state ที่เอเจนต์กำลังใช้งานอยู่ในขณะนี้อธิบายถึง production ดังนั้นคำสั่ง destroy จึงวางแผนลบ production Grigorev ระบุรายการสิ่งที่สูญหายไป:

• VPC ที่เก็บสภาพแวดล้อมทั้งหมด

• คลัสเตอร์ ECS ที่รันแอปพลิเคชัน

• โหลดบาลานเซอร์ที่อยู่ด้านหน้าของมัน

• โฮสต์ bastion ที่ใช้สำหรับเข้าถึงเครือข่ายส่วนตัว

• ฐานข้อมูล Amazon RDS ที่จัดเก็บข้อมูลของแพลตฟอร์มหลักสูตร

• สแนปช็อต RDS อัตโนมัติที่ควรจะทำให้ทุกสิ่งที่กล่าวมาข้างต้นสามารถกู้คืนได้

รายการสุดท้ายคือสิ่งที่เปลี่ยนเหตุขัดข้องให้กลายเป็นเรื่องน่าตกใจเรื่องข้อมูลสูญหาย ในบทสัมภาษณ์กับ Rootly คำอธิบายของ Grigorev คือการลบฐานข้อมูลแบบ managed บน AWS จะลบแบ็กอัปอัตโนมัติที่เกี่ยวข้องออกไปด้วย ในโพสต์นั้น ฝ่ายสนับสนุนของ AWS ยืนยันกับเขาว่าฐานข้อมูลของเขาและสแนปช็อตทั้งหมดถูกลบไปแล้ว และ "คำขอ API บอก AWS อย่างชัดเจนให้ลบทุกอย่าง" ไม่ว่าการลบจะแพร่กระจายไปในทางใด ผลที่เกิดขึ้นตอน 5 ทุ่มคือสิ่งที่สำคัญ: สำเนาที่เขาใช้พึ่งพาอยู่นั้นถูกลบไปโดยการดำเนินการเดียวกันกับต้นฉบับ

การฟื้นตัวใน 24 ชั่วโมง

ปัญหาแรกคือแบ็กอัปดูเหมือนจะหายไปหมด และปัญหาที่สองคือมีอยู่ตัวหนึ่งที่ไม่ได้หายไป Grigorev รู้ว่ามีการสร้างสแนปช็อตทุกคืนเวลา 2 น. ในคอนโซล RDS เขาไม่พบสแนปช็อตใดเลย แต่รายการ RDS Events ยังคงแสดงว่ามีการสร้างแบ็กอัปขึ้น เมื่อคลิกผ่านไปยังรายการนั้นกลับไม่มีอะไรเปิดขึ้นมา เขาไม่สามารถบอกได้ว่าสแนปช็อตถูกลบไปแล้วหรือเพียงแค่กลายเป็นมองไม่เห็น

เขาเปิดตั๋วสนับสนุนประมาณเที่ยงคืน จากนั้นอัปเกรดบัญชีเป็น AWS Business Support หลังจากสังเกตเห็นข้อผูกมัดการตอบกลับภายในหนึ่งชั่วโมงสำหรับเหตุการณ์ในโปรดักชัน การอัปเกรดดังกล่าวเพิ่มค่าใช้จ่ายในบิล AWS ของเขาประมาณ 10 เปอร์เซ็นต์ ซึ่งเป็นที่มาของชื่อโพสต์ของเขา ฝ่ายสนับสนุนตอบกลับภายในประมาณ 40 นาที ยืนยันการลบ และบอกเขาว่ามีสแนปชอตอยู่ฝั่ง AWS ซึ่งเขาไม่สามารถมองเห็นได้ในคอนโซลของเขา จากนั้นมีการโทรศัพท์คุยกัน 40 ถึง 60 นาที และถูกส่งต่อไปยังทีมภายใน ตรง 24 ชั่วโมงหลังจากฐานข้อมูลถูกลบ AWS ได้กู้คืนสแนปชอตและมันปรากฏในคอนโซลของเขา เขาสร้างอินสแตนซ์ขึ้นใหม่จากสแนปชอตนั้นผ่าน Terraform ระหว่างรอ เขาได้สร้างโครงสร้างพื้นฐานโดยรอบขึ้นใหม่และรวมโหลดบาลานเซอร์หลายตัวเข้าเป็นตัวเดียว

ฐานข้อมูลที่กู้คืนมามี 1,943,200 แถวในตาราง courses_answer ซึ่งเขาอ้างถึงเป็นหลักฐานตรวจสอบว่าการกู้คืนเสร็จสมบูรณ์ ตัวเลขดังกล่าวมักถูกกล่าวซ้ำเป็นขนาดของข้อมูลที่สูญหาย มันเป็นจำนวนแถวของตารางเดียว ใช้เป็นหลักฐานว่าข้อมูลกลับมาแล้ว — ไม่ใช่ยอดรวมของฐานข้อมูล และไม่ใช่จำนวนนักเรียนที่ได้รับผลกระทบ ซึ่งไม่มีแหล่งใดระบุไว้

คำเตือนที่ไม่มีอยู่จริง

มีเรื่องเล่าฉบับต่างๆ หลายฉบับที่มีประโยคหนึ่งระบุว่า Claude เตือน Grigorev ล่วงหน้าแล้วแต่ถูกเพิกเฉย สิ่งที่แหล่งข้อมูลสนับสนุนนั้นแคบกว่านั้น และความแตกต่างนี้เปลี่ยนว่าคดีนี้เป็นตัวอย่างของอะไร เอเจนต์โต้แย้งการตั้งค่า Terraform แบบใช้ร่วมกันก่อนที่จะมีการทำลายใดๆ และคำแนะนำนั้นถูกปัดตก คำบอกเล่าทั้งสองฉบับของ Grigorev ไม่ได้บรรยายว่าเอเจนต์เตือนว่าการ destroy จะไปถึง production เขากล่าวว่าเขาไม่รู้ว่า state file ถูกสลับ และในทั้งสองฉบับ ข้อเสนอของเอเจนต์ถูกนำเสนอเป็นงานเก็บกวาดมากกว่าความเสี่ยงที่ถูกชี้ให้เห็นแล้วปล่อยผ่าน คำเตือนที่ถูกเพิกเฉยนั้นเกี่ยวกับสถาปัตยกรรม ก่อนหน้านี้ในระหว่างการย้ายระบบ ไม่ใช่เกี่ยวกับคำสั่ง

ความแตกต่างนั้นแยกความล้มเหลวสองแบบที่ต่างกัน เอเจนต์ที่มองเห็นอันตรายแต่ถูกกลับคำตัดสินเป็นเรื่องเล่าด้านธรรมาภิบาลเกี่ยวกับการตัดสินใจของมนุษย์ ส่วนเอเจนต์ที่ไม่รู้ว่าอันตรายมีอยู่ เพราะไฟล์ที่บรรยายโลกเปลี่ยนไปข้างใต้มัน เป็นเรื่องเล่าด้านเครื่องมือเกี่ยวกับสถานะ สิทธิ์ และด่านอนุมัติ บันทึกของ Grigorev เป็นแบบที่สอง และการจัดประเภทของคลังเองก็สะท้อนสิ่งนี้: บันทึกดังกล่าวมีแท็ก ROGUE ของคลังสำหรับการกระทำของเอเจนต์ที่เบี่ยงเบนไปจากสิ่งที่ผู้ดำเนินการตั้งใจ และรายการใน AI Incident Database ที่อยู่ใต้บันทึกนั้นจัดประเภทเจตนาว่าไม่เจตนา ภายใต้อนุกรมวิธาน MIT ข้อ 7.3 การขาดความสามารถหรือความทนทาน ในโดเมนความเสี่ยงด้านความปลอดภัยของระบบ AI ความล้มเหลวและข้อจำกัด ในระยะหลังการนำไปใช้งาน ฐานข้อมูลเติมคำว่า “ที่ถูกกล่าวอ้าง” ไว้หน้ารายการเอนทิตีของตน ซึ่งเป็นกรอบมาตรฐานสำหรับกรณีที่รายงานด้วยตนเองและยังไม่มีหน่วยงานใดวินิจฉัย

ที่ที่ความผิดตกอยู่

Grigorev ไม่ได้แจกจ่ายมัน “เหตุการณ์นี้เป็นความผิดของผม” เขาเขียน พร้อมระบุสาเหตุสามประการ: เขามองว่า plan, apply และ destroy เป็นสิ่งที่มอบหมายต่อได้; เขาเชื่อถือแบ็กอัปที่เขาไม่เคยทดสอบกู้คืน; และฐานข้อมูลนั้นถูกลบได้ง่ายเกินไป เขาบันทึกไว้ว่า ขณะรอ AWS เขาต้องพิจารณาว่าข้อมูลอาจหายไปอย่างถาวร — สำหรับคอร์ส Data Engineering ซึ่งตอนนั้นกำลังดำเนินมาถึงโมดูลสุดท้าย เขากำลังวางแผนการกู้คืนอยู่แล้ว และสำหรับคอร์สเก่า ๆ การกู้คืนที่ล้มเหลวจะหมายถึงจุดจบของคอร์สเหล่านั้น

การประเมินของ Tom's Hardware ซึ่งเผยแพร่ในวันถัดจากโพสต์ของเขา มีเนื้อความเดียวกันโดยพื้นฐาน: “ข้อผิดพลาดเหล่านั้นสามารถอธิบายได้ว่าเกิดจากการกำกับดูแลที่ไม่เหมาะสม” คำวิจารณ์ของมันไปไกลกว่าของเขา โดยชี้ไปที่ข้อมูลรับรองที่ครอบคลุมกว้างขวางซึ่งมอบให้กับเอเจนต์ และสิทธิ์การเข้าถึงที่ไม่เคยถูกจำกัดขอบเขตให้เหมาะกับสภาพแวดล้อมการผลิต ยังไม่มีหน่วยงานกำกับดูแล องค์กรมาตรฐาน หรือผู้ขายรายใดออกมาแสดงจุดยืน ที่นี่ไม่มี CVE ไม่มีการเปิดเผยช่องโหว่ และไม่มีการเจาะโมเดล: เอเจนต์ไม่ได้ถูกหลอก แต่ถูกไว้วางใจมากเกินไป

มีอะไรเปลี่ยนแปลงไปหลังจากนั้น

Grigorev ได้ดำเนินมาตรการป้องกันเหล่านี้ในขณะที่ AWS ยังคงดำเนินการกู้คืนอยู่ และได้เผยแพร่มาตรการเหล่านี้เป็นรายการ ตามถ้อยคำและลำดับของเขาเอง:

• การสำรองข้อมูลที่ Terraform ไม่ได้จัดการ รวมถึงสำเนาที่จัดเก็บใน S3 ซึ่งแยกจากฐานข้อมูลและสถานะโครงสร้างพื้นฐาน

• การทดสอบการกู้คืนทุกคืน: {{1}}แบ็กอัปอัตโนมัติเวลา 02:00 น.{{/1}} จะถูกใช้เมื่อประมาณ {{2}}03:00 น.{{/2}} เพื่อสร้างอินสแตนซ์ฐานข้อมูลใหม่ ซึ่งใช้เวลา {{3}}20 ถึง 30 นาที{{/3}} และ {{4}}Lambda ที่จัดการลำดับงานด้วย Step Functions{{/4}} จะตรวจสอบว่าอินสแตนซ์ใช้งานได้ด้วย {{5}}คิวรีอ่านแบบง่าย{{/5}} ก่อนที่อินสแตนซ์จะถูกหยุดแทนที่จะถูกลบ {{6}}สำเนาของเมื่อวาน{{/6}} จะถูกลบออก ดังนั้นจึงมี {{7}}รีพลิกาล่าสุดหนึ่งชุด{{/7}} พร้อมใช้งานเสมอ

• การป้องกันการลบในสองระดับ คือในคอนฟิกูเรชันของ Terraform และใน AWS เอง เขาตั้งข้อสังเกตว่ายังมีผู้ที่ปิดใช้งานอย่างชัดเจนสามารถลบสิ่งเหล่านี้ได้ แต่ก็ช่วยเพิ่มความยุ่งยากในการดำเนินการ

• การเปิดใช้เวอร์ชันนิงบนแบ็กอัป S3 ดังนั้นการลบจะยังคงเหลือเวอร์ชันก่อนหน้าไว้ และการทำให้บัคเก็ตว่างจำเป็นต้องลบเนื้อหาข้างในออกก่อน

• ย้าย Terraform state ไปยัง S3 ซึ่งขจัดเงื่อนไขที่ทำให้เรื่องนี้เริ่มต้นขึ้น — ไฟล์ state ที่มีอยู่เพียงในแล็ปท็อปเครื่องเดียวและหายไปเมื่อเขาเปลี่ยนเครื่อง

• เอเจนต์ไม่ได้รัน Terraform เลยอีกต่อไป “สิทธิ์ทั้งหมดถูกปิดใช้งาน ไม่มีการเรียกใช้โดยอัตโนมัติ ไม่มีการเขียนไฟล์” เขาเขียน ขั้นตอนการทำงานตอนนี้คือสร้างแผน ตรวจสอบด้วยตนเอง แล้วรันคำสั่งด้วยตัวเอง โปรเจกต์ใหม่ยังมีคอนฟิกูเรชัน Terraform แยกของตัวเองอีกด้วย

ไม่ใช่ทุกคำแนะนำที่ถูกนำไปใช้ ในบทสัมภาษณ์กับ Rootly เขากล่าวว่าเขายังคงใช้บัญชี AWS เพียงบัญชีเดียว โดยมองว่าการแยกบัญชีสำหรับ development และ production รวมถึงไปป์ไลน์การอนุมัติอย่าง Atlantis เป็นสิ่งที่เกินความจำเป็นสำหรับผู้ดูแลระบบคนเดียว นั่นคือภาพที่ตรงไปตรงมาของผลลัพธ์ที่ตามมา: การแก้ไขนั้นเป็นเรื่องจริง และเป็นการแก้ไขที่คนคนเดียวสามารถดูแลรักษาได้ด้วยตัวเอง

บันทึกนี้คืออะไร และไม่ใช่อะไร

มันเป็นเหตุการณ์ปฏิบัติการที่ได้รับการบันทึกไว้และรายงานโดยผู้ประสบเหตุเอง ซึ่งก่อให้เกิดความเสียหายทางการเงินและต่อความพร้อมใช้งานจริง และมันอ่านเข้าใจได้ง่ายเป็นพิเศษเพราะคนที่เหตุการณ์นี้เกิดขึ้นกับเขาได้เขียนลำดับเหตุการณ์ทั้งหมดไว้ รวมถึงส่วนที่เป็นความผิดพลาดของเขาเองด้วย มันไม่ใช่หลักฐานว่าโมเดลได้มุ่งไปสู่เป้าหมายของตัวเอง และแท็ก ROGUE ของคลังเก็บควรถูกอ่านว่าอธิบายความแตกต่างระหว่างการกระทำของเอเจนต์กับเจตนาของผู้ปฏิบัติการของมัน มากกว่าจะหมายถึงเจตนาใด ๆ ในส่วนของเอเจนต์

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