คำตอบสั้นๆ: บันทึกแฮชเมื่อเขียนไฟล์ แล้วเปรียบเทียบภายหลัง หากแฮชต่างกันและไม่มีอะไรแก้ไขไฟล์ ข้อมูลก็เปลี่ยนไปโดยที่คุณไม่รู้
ไม่มีอะไรอื่นหาเจอ ดิสก์ที่มีความเสียหายแบบเงียบผ่านการปฐมพยาบาล รายงาน SMART ว่าปกติ และเมานต์ได้สมบูรณ์
ที่เก็บข้อมูลเป็นสิ่งทางกายภาพ โดเมนแม่เหล็กบนดิสก์หมุนอ่อนลง ประจุรั่วออกจากเซลล์ในหน่วยความจำแฟลช เร็วขึ้นเมื่ออุ่น และเร็วขึ้นอีกเมื่อไดรฟ์ไม่ได้ต่อไฟเป็นเวลานาน สายอาจทำบิตหล่นระหว่างส่ง เฟิร์มแวร์มีบั๊ก
ไดรฟ์แก้ไขส่วนใหญ่ของเรื่องนี้เอง ด้วยรหัสแก้ไขข้อผิดพลาดและการย้ายเซกเตอร์ที่เริ่มเสีย ความเสียหายที่สำคัญคือส่วนที่หลุดรอดไปได้: การอ่านที่คืนข้อมูลต่างจากที่เขียน และรายงานว่าสำเร็จ
ชื่อที่คนเถียงกัน บางคนเรียก bit rot บางคนเรียกข้อมูลเสียหายแบบเงียบ บางคนเรียกการเสื่อมของข้อมูล สำหรับเรา ทั้งหมดคือสิ่งเดียวกัน: ไฟล์ต่างไปและไม่มีอะไรบอก
นี่คือส่วนที่ควรเข้าใจ เพราะมันอธิบายว่าทำไมทุกเครื่องมือที่คุณจะหยิบมาใช้คือเครื่องมือที่ผิด
cp และ Finder อ่านข้อมูลแล้วเขียนข้อมูล หากการอ่านได้ข้อมูลผิด มันก็เขียนข้อมูลผิดนั้นอย่างซื่อสัตย์ดังนั้นความจริงคือ: Mac ของคุณไม่มีกลไกใดที่จะบอกคุณ อาการแรกคือรูปที่มีแถบขยะพาดผ่าน ไฟล์เก็บถาวรที่เปิดไม่ได้ หรือวิดีโอที่หยุดกลางคัน
เกิดยากเมื่อนับต่อไฟล์ แต่ไม่ยากเมื่อเป็นคอลเลกชันใหญ่ในเวลานาน ซึ่งคือกรณีที่ข้อมูลสำรองมีไว้ มีสองอย่างที่เพิ่มโอกาสอย่างเห็นได้ชัด:
เหตุผลที่มันสำคัญในข้อมูลสำรองมากกว่าบนดิสก์ใช้งานคือ ไฟล์ใช้งานถูกเปิด และไฟล์เสียที่ถูกเปิดคือความเสียหายที่คุณพบแล้ว ข้อมูลสำรองถูกเขียนครั้งเดียวและไม่เคยถูกอ่าน หมายความว่าความเสียหายในข้อมูลสำรองจะถูกพบในวันที่คุณต้องใช้มัน
บันทึกสิ่งที่คุณเขียน:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtแล้วหลายเดือนต่อมา ถามว่ามันยังเหมือนเดิมไหม:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'สิ่งที่พิมพ์ออกมาคือไฟล์ที่ข้อมูลเปลี่ยนไป หากคุณไม่ได้แก้ไข นั่นคือคำตอบ
สองข้อในทางปฏิบัติ เก็บไฟล์แฮชไว้ที่อื่นที่ไม่ใช่ไดรฟ์ที่มันอธิบาย ไม่อย่างนั้นคุณจะเสียทั้งคู่พร้อมกัน และการตรวจนี้ใช้เวลาเท่ากับการอ่านทั้งไดรฟ์ ดังนั้นตั้งเวลาไว้ตอนกลางคืน
ทั้งหมดข้างต้นคือเหตุผลที่แอปมีรูปร่างแบบนี้ มันเก็บทุกชิ้นของข้อมูลสำรองภายใต้แฮชของเนื้อหา แล้วอ่านข้อมูลสำรองกลับตามกำหนดเวลาและตรวจแต่ละชิ้นกับแฮชที่ใช้จัดเก็บ
ความไม่ตรงกันจึงเป็นหลักฐาน: ข้อมูลไม่ใช่ข้อมูลที่ถูกเขียน และไม่มีการตีความใดที่ทำให้มันไม่เป็นไร ชิ้นที่ถูกลบไปใต้ข้อมูลสำรองจะถูกรายงานว่าหายไป และคะแนนบนหน้าจอหลักนับเฉพาะสิ่งที่ตรวจสอบเมื่อเร็วๆ นี้ ซึ่งเป็นเหตุผลที่มันต่ำกว่าที่คนคาด และนั่นคือประเด็น
การมีตำแหน่งที่สองสำคัญตรงนี้มากกว่าที่ใดในเว็บไซต์นี้ ความเสียหายในสำเนาหนึ่งเป็นแค่ความไม่สะดวกเมื่อมีสองสำเนา และเป็นจุดจบของไฟล์เมื่อมีสำเนาเดียว
ไม่ การปฐมพยาบาลตรวจโครงสร้างระบบไฟล์ ไม่ใช่เนื้อหาไฟล์ ไดรฟ์ที่มีไฟล์เสียหายแบบเงียบผ่านได้สะอาด ซึ่งคือสิ่งที่ทำให้ปัญหานี้เป็นอย่างที่มันเป็น
ไม่ได้สำหรับเรื่องนี้ SMART รายงานข้อผิดพลาดที่ไดรฟ์ตรวจพบและแก้ไขหรือย้ายตำแหน่งแล้ว ความเสียหายแบบเงียบคือประเภทที่ไดรฟ์ไม่ได้ตรวจพบ แต่ก็ยังควรตรวจสอบไดรฟ์ที่กำลังจะเสีย ซึ่งเป็นปัญหาอีกแบบที่เห็นได้ชัดกว่า
มันทำ checksum ให้เมทาดาทาของตัวเอง ไม่ใช่ข้อมูลไฟล์ของคุณ ZFS และ Btrfs ทำ checksum ให้เนื้อหาไฟล์และซ่อมจากสำเนาซ้ำได้ และทั้งสองไม่มีให้ใช้เป็นโวลุ่มเริ่มระบบหรือโวลุ่มภายนอกปกติของ macOS ช่องว่างนั้นคือเหตุผลที่การตรวจระดับแอปพลิเคชันควรมี
บ่อยพอที่จะพบสำเนาที่เสียขณะที่สำเนาที่ดียังอยู่ ทุกไตรมาสสมเหตุสมผลสำหรับคลังเก็บถาวร ทุกเดือนหากเป็นสำเนาเดียวของสิ่งที่หาทดแทนไม่ได้ คำตอบที่ถูกคือความถี่ที่คุณจะไม่ข้ามจริงๆ ซึ่งเป็นเหตุผลว่าควรเป็นอัตโนมัติ
ไม่ การตรวจสอบบอกคุณว่าสำเนาเสียแล้ว มันคืนไฟล์ให้ไม่ได้ การตรวจพบมีประโยชน์ก็ต่อเมื่อมีสำเนาที่สองให้กู้คืน ซึ่งคือข้อโต้แย้งทั้งหมดของกฎ 3-2-1
ที่เกี่ยวข้อง: วิธีตรวจว่าข้อมูลสำรองอ่านได้, รูปแบบคลังข้อมูล และ กฎ 3-2-1