ด้วย ZFS ข้อมูลที่สูญหายมีเพียงแค่ราว 10 นาทีเท่านั้น
(mastodon.social)- แม้ว่า SSD อายุ 2 ปีจะเสียกะทันหัน แต่ด้วยการทำ incremental replication ของ ZFS ก็สามารถกู้ระบบขึ้นมาบนไดรฟ์ใหม่ได้ ทำให้การสูญเสียจริงมีเพียงราว 10 นาที
- ระบบนี้ตั้งค่าให้ สร้างสแนปช็อตทุก 10 นาที ของทั้งไฟล์ซิสเต็มแล้วส่งไปยัง NAS โดยใช้ zrepl ในการทำงานอัตโนมัติ
- สแนปช็อตจะบันทึกสถานะของระบบที่กำลังทำงาน ณ ช่วงเวลาหนึ่ง และ ส่งเฉพาะส่วนที่เปลี่ยนแปลง ทำให้ทำ replication เบื้องหลังได้แม้ในเครือข่ายภายในบ้าน
- กระบวนการกู้คืนต้องรัน 625GiB ZFS receive ข้ามคืน และยังต้องกู้ wrapper key สำหรับการเข้ารหัสด้วย จึงยังห่างไกลจากการกู้คืนแบบอัตโนมัติ
- แม้ ZFS จะมีภาระทั้งด้านการเริ่มใช้งานและการดูแลรักษาสูง แต่ก็แสดงให้เห็นถึง ประสิทธิภาพด้านการกู้คืนจากภัยพิบัติ ที่สามารถคืนแม้กระทั่งสถานะงานกลับมาได้เมื่อไดรฟ์เสียจริง
หลัง SSD เสีย ความสูญเสียที่เหลืออยู่มีเพียง 10 นาที
- ขณะที่เปิดโน้ตบุ๊กเพื่อจะส่งอีเมล หน้าจอกลับ ค้างเป็นสีดำ และหลังรีบูตก็พบว่า SSD อายุ 2 ปีเสียไปแล้ว
- หลังจากกู้ระบบลงไดรฟ์ใหม่ก็สามารถกลับมาใช้งานได้อีกครั้ง โดยข้อมูลที่สูญหายทั้งหมดมีเพียงประมาณ 10 นาที
- โน้ตบุ๊กที่กู้คืนแล้วบูตกลับขึ้นมาที่จุดที่เคยค้างไว้ และแท็บเบราว์เซอร์ก็ยังคืนงานที่ทำค้างไว้เมื่อคืนก่อนกลับมาได้
- แนวคิดแบบโฆษณา Chromebook เมื่อ 12 ปีก่อน ที่ให้ไปต่อจากสถานะเดิมบนอุปกรณ์ใหม่ได้ กลับใช้งานได้จริงในเหตุไดรฟ์เสียครั้งนี้
- วิดีโอที่เกี่ยวข้อง: https://www.youtube.com/watch?v=lm-Vnx58UYo
โครงสร้างที่ใกล้เคียงกับ replication มากกว่าการสำรองข้อมูล
- แทนที่จะสำรองแค่ไดรฟ์ ผู้เขียนเลือกใช้วิธี ทำ replication ของทั้งไฟล์ซิสเต็ม
- เมื่อฤดูหนาวที่ผ่านมา ได้สร้างสตอเรจบนเครือข่ายภายในบ้านเพื่อสำรองข้อมูลเป็นระยะให้กับคอมพิวเตอร์ที่ใช้ทำงานสร้างสรรค์ และจากหลายตัวเลือกก็เลือก ZFS incremental replication
- ZFS สามารถสร้างสแนปช็อตของช่วงเวลาหนึ่งได้อย่างมีประสิทธิภาพ แม้ระบบจะยังทำงานอยู่
- จากนั้นเมื่อส่งไปยังเครื่องอื่น ก็ไม่ต้องส่งข้อมูลทั้งหมดซ้ำ ๆ แต่จะ ส่งเฉพาะข้อมูลที่เปลี่ยนไป
ส่งไปยัง NAS ทุก 10 นาทีด้วย zrepl
- ใช้ zrepl เพื่อทำให้การสร้างสแนปช็อตและการส่งไปยัง NAS เป็นอัตโนมัติ
- การตั้งค่าคือให้ สร้างสแนปช็อตทุก 10 นาที ของทั้งไฟล์ซิสเต็มแล้วส่งออก
- ด้วย incremental snapshot ทำให้แม้รันเบื้องหลังบนเครือข่ายภายในบ้าน ก็ยังทำให้ชุดข้อมูลจำลองอัปเดตอยู่เสมอได้
- การรันครั้งล่าสุดใช้เวลา 14 วินาที ในการส่งข้อมูลประมาณ 64MiB
ภาระงานแบบแมนนวลที่ปรากฏชัดในขั้นตอนกู้คืน
- การกู้ระบบเป็นกระบวนการที่ต้องเรียนรู้ และหลายส่วนยังต้องพึ่ง การทำงานด้วยมือ
- งาน 625GiB ZFS receive ต้องปล่อยรันข้ามคืน
- สแนปช็อตถูกเข้ารหัสโดยคอมพิวเตอร์ต้นทาง ทำให้ NAS ไม่สามารถอ่านเนื้อหาข้างในได้
- หากต้องการใช้งานแบ็กอัปจริง ก็จำเป็นต้องกู้ wrapper key สำหรับการเข้ารหัสกลับมาด้วย
- จนกว่าจะยืนยันได้ครั้งแรกว่าสามารถถอดรหัสข้อมูลได้ กระบวนการกู้คืนทั้งหมดก็เต็มไปด้วยความกังวลอย่างมาก
ต้นทุนในการเริ่มใช้งานและการเปลี่ยนฮาร์ดแวร์
- การตั้งค่า ZFS ในช่วงแรกมี ต้นทุนในการเริ่มต้น สูง เพราะต้องเปลี่ยนทั้งไฟล์ซิสเต็ม
- การดูแลรักษาต้องอาศัยความรู้เฉพาะทางมาก และมีขั้นตอนปฏิบัติงานที่รวมงานแบบแมนนวลอยู่ด้วย
- ถึงอย่างนั้น การที่ตั้งค่า replication ไว้ก่อน SSD จะเสียครั้งแรกก็ถือว่าโชคดี และกรณีนี้ก็แสดงให้เห็นข้อดีของ ZFS อย่างชัดเจน
- ไดรฟ์ที่เสียคือ WD_BLACK SN850 ที่เดิมมาพร้อมกับคำสั่งซื้อ Framework
- เคยเห็นกรณีชวนกังวลในฟอรัมของ Framework ว่าไดรฟ์รุ่นนี้อาจเสียกะทันหันหรือบูตไม่ขึ้น
- ในวันเดียวกันนั้นก็ได้รับ SK Hynix P41 SSD และ Sabrent NVMe enclosure จาก Amazon ภายในเวลาประมาณ 3 ชั่วโมง
1 ความคิดเห็น
ความเห็นจาก Hacker News
ใช้ ZFS อยู่ ก็เลยถือว่าเตรียมพร้อมได้ดีกว่าผู้ใช้ SSD ของ WD หรือ SanDisk รายอื่น
https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
https://news.ycombinator.com/item?id=37042587
https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
https://news.ycombinator.com/item?id=37188736
ทั้งคู่เป็น HGST เป็นวันที่เศร้ามาก แต่โชคดีที่ทำ
zfs sendไปยังอีกสถานที่หนึ่งไว้อย่างสม่ำเสมอ เลยสูญเสียข้อมูลไปน้อยมาก ZFS ยอดเยี่ยมจริงๆGoogle มองว่าคำค้นอย่าง “4TB SanDisk SSD” คือการหาหน้าสินค้า ทำให้ข่าวอย่างบทความของ The Verge หรือ Ars Technica ถูกดันลงไปไกลในผลการค้นหา พอดีกำลังลองใช้ Kagi ซึ่งเป็นเสิร์ชเอนจินแบบเสียเงินอยู่ จึงเป็นโอกาสดีที่จะดูว่าการค้นเว็บอีกแบบจะให้ผลต่างกันไหม แต่ถ้าทั้งเว็บเต็มไปด้วยบทความเชิงชื่นชม ก็ดูเหมือนว่าต่อให้กฎการจัดลำดับความสำคัญต่างกัน ก็ยากจะให้ผลลัพธ์ที่ต่างออกไป
ผลลัพธ์ 5-6 อันดับแรกเป็นร้านค้าออนไลน์ จากนั้นก็เป็นรีวิวของ easeus [1], techpowerup [2], anandtech [3], consumerreviews [4] ซึ่งไม่มีอันไหนมีคำว่า “fail” เลย จุดเดียวที่ดีกว่า Google ในท้ายที่สุดคือมีคำค้นที่เกี่ยวข้องอย่าง “sandisk 4tb ssd failure”, “sandisk 4tb ssd problems” ให้ แต่ไปอยู่ล่างสุดของหน้าเลยมองเห็นยาก ถึงอย่างนั้นก็ยังดีกว่าหน้าผลการค้นหาแรกของ Google ที่ไม่มีคำว่า “fail” โผล่มาเลย
[1]: https://www.easeus.com/knowledge-center/sandisk-4tb-extreme-portable-ssd-v2-full-review.html
[2]: https://www.techpowerup.com/review/sandisk-ultra-3d-4-tb-ssd/
[3]: https://www.anandtech.com/show/16892/sandisk-extreme-pro-crucial-x6-4tb-portable-ssds
[4]: https://consumerreviews.store/sandisk-4tb-extreme-portable-ssd-up-to-1050mb-s-usb-c-usb-3-2-gen-2-review/
ก่อนจะออกจากโลก Linux ไปอย่างสิ้นเชิง ผมเพิ่งเริ่มค่อย ๆ ขุดภูเขาน้ำแข็งที่ชื่อ btrfs ดู ซึ่งก็น่าสนใจไม่น้อย
มันดูมีศักยภาพมากในหลายด้าน ทั้งเรื่องการปฏิวัติการสำรองข้อมูล การจัดวางดิสก์ และฟีเจอร์อื่น ๆ อีกมากมาย btrfs ไม่ใช่ ZFS แต่มีฟังก์ชันบางส่วนที่ทับซ้อนกัน และก็ใกล้เคียงกับคำว่า “ZFS สำหรับคนงบน้อย” อยู่เหมือนกัน อีกทั้งเรื่องไลเซนส์ การแพ็กเกจ และสถานะการรวมอยู่ในเคอร์เนลของ ZFS ก็ยังค่อนข้างก้ำกึ่ง ทำให้ในบางระบบปฏิบัติการ btrfs เป็นตัวเลือกที่สมเหตุสมผลกว่ามาก
ครั้งหนึ่งผมเคยเล่าใน Linux User Group ว่าต้องถอดสายไฟเพื่อรีบูตคอมพิวเตอร์ แล้วก็โดนดุหนักมากเพราะการกระทำโง่ ๆ แบบนั้น พร้อมถูกแนะนำให้ใช้ ZFS แต่พอคิดว่าระบบนั้นคือ Raspberry Pi มุมมองว่าอะไรฉลาดกว่ากันก็อาจเปลี่ยนไปได้
ถ้าไม่ใช้งาน SD card หนักเกินไป อุปกรณ์พวกนี้ก็ทำงานได้เสถียรมากแบบต่อเนื่องยาว ๆ ZFS ดูยอดเยี่ยมจริง แต่ถึงวันหนึ่งผมจะซื้อ NAS ก็คงไม่อยากเสียเงินกับฮาร์ดแวร์ที่ต้องรองรับ ZFS เลยคิดว่าน่าจะใช้แค่ RAID กับ ext4 มากกว่า
ส่วน btrfs ผมเลี่ยงมาตลอด เพราะทุกไม่กี่เดือนจะเห็นโพสต์แนว “BTRFS ทำข้อมูลฉันหาย” แล้วก็ตามมาด้วยการถกเถียงกันว่าเป็นความผิดของ btrfs จริงหรือไม่ ช่วงนี้เหมือนจะเห็นโพสต์แบบนั้นน้อยลง อาจถึงเวลาที่ควรกลับไปมองมันใหม่ก็ได้
โดยเฉพาะกับอิมเมจ VM แบบ sparse และสำหรับงานแบบนั้นผมมองว่า zvol ดีกว่ามาก
เมื่อหลายปีก่อนเคยมี วิกฤตคาปาซิเตอร์ ตอนนี้ชักเหมือนกำลังเจอวิกฤตอุปกรณ์เก็บข้อมูลแทน
มันเริ่มน่าเหลือเชื่อที่สตอเรจทุกอย่างดูแย่ลงเรื่อย ๆ WD กำลังทำ HDD พังด้วย SMR และผู้ผลิตก็พูดกันหน้าตาเฉยว่าอายุการใช้งาน 3 ปีของ SSD กับ HDD นั้นนานมากแล้ว ปีนี้ปีเดียว Kingston SSD ของผมตายไปตัวหนึ่ง ซึ่งอายุราว 8 ปีก็พอเข้าใจได้ แต่ WD HDD แบบพกพาก็ตายภายในราว 2 ปีเหมือนกัน
ทุกวันนี้ในอินเทอร์เน็ตเต็มไปด้วยเรื่องข้อมูลสูญหายและปัญหาอายุการใช้งาน เมื่อ 20 ปีก่อน HDD ก็ไม่ใช่ของที่ใช้ได้ตลอดกาลหรอก แต่เท่าที่จำได้ อย่างน้อยมันก็อยู่ได้นานกว่าอายุการใช้งานที่เป็นประโยชน์ของคอมพิวเตอร์ที่ซื้อมาพร้อมกันแน่นอน
ยุคนั้นคือยุคของไดรฟ์ IBM Deathstar ชื่อกระฉ่อน ที่สารเคลือบแม่เหล็กหลุดออกจากแพลตเตอร์กันแบบตามตัวอักษรจริง ๆ ยังมีไดรฟ์ Maxtor สุดสยองที่พังใน 1–2 ปีด้วย และหลัง Seagate ซื้อ Maxtor ไป ช่วงหนึ่งไดรฟ์ Seagate เองก็ไม่น่าไว้ใจเหมือนกัน ผมเคยดูแลเซิร์ฟเวอร์ที่มีดิสก์ราว 8 ลูก และต้องคอยเปลี่ยนทีละลูกแทบทุกปี
แต่ตอนนี้ผมช่วยดูแลเซิร์ฟเวอร์ ZFS ที่มีไดรฟ์มากกว่า 20 ลูก อายุการใช้งานของไดรฟ์ก็อยู่ราว 4–5 ปี อีกอย่างหนึ่งคือคอมพิวเตอร์ในสมัยนั้นตกรุ่นเร็วกว่ามาก ตอนนี้คอมอายุ 6 ปียังใช้งานได้สบาย แต่สมัยนั้นคอมอายุ 3 ปีก็รู้สึกเก่าอย่างชัดเจนแล้ว
เรากำลังชนเพดานการขยายตัว และการเติบโตแบบเอ็กซ์โปเนนเชียลก็กำลังชะลอลง
แต่ตอนนี้แทบไม่เห็นเรื่องแบบนั้นกับ SSD เลย แม้แต่ Intel SSD รุ่นเก่าช่วงปลายยุค 2000 ที่ขึ้นชื่อว่ามีปัญหา ผมใช้ไปหลายปีแล้วส่งต่อให้แม่ และมันก็ยังทำงานได้ดีอยู่ใน MacBook รุ่นเก่าเครื่องเดิม ผมเลยอยากรู้เหมือนกันว่าข้อมูลจริง ๆ เป็นอย่างไร
SSD ผมก็โชคดีเหมือนกัน แต่บนเดสก์ท็อปผมยังคงเก็บไดเรกทอรี
/homeและอาร์เรย์ RAID ไว้บนไดรฟ์จานหมุนรุ่นเก่า เลยใช้ SSD ลูกเล็ก ๆ เท่านั้นมีข้อยกเว้นอยู่สองกรณี ผมถอด WD Red ก่อนยุค SMR สองลูกออกจาก NAS เครื่องเก่าเพราะจะอัปเกรดเป็นดิสก์ที่ใหญ่กว่า แล้วเก็บไว้ในถุงกันไฟฟ้าสถิตในลิ้นชัก ทั้งที่ตอนเก็บยังปกติดีทุกอย่าง ประมาณ 2.5 ปีต่อมาพอต้องใช้เป็นดิสก์สำรองเลยหยิบออกมาตรวจดู ปรากฏว่าทั้งคู่ใช้ไม่ได้แล้ว ลูกหนึ่งตายสนิท อีกลูกพอมองเห็นแต่ไม่สามารถอ่านได้ ลูกแรกต่อเข้าไปแล้วยังไม่ขึ้นอะไรเลย ผมลองทำความสะอาดจุดสัมผัสทุกจุดรวมถึงขาคอนโทรลเลอร์ PCB แล้วก็ไม่ช่วยอะไร สุดท้ายเลยทิ้งไป ส่วนอีกลูกกลับมาใช้ใหม่ได้ก็ต่อเมื่อฟอร์แมตทั้งลูกใหม่หมด แต่แม้ใช้ testdisk ก็ไม่มีทางกู้ข้อมูลเก่ากลับมาได้ เรื่องแบบนี้ผมไม่เคยเจอและไม่เคยคาดคิดมาก่อน เลยพูดตรง ๆ ว่าค่อนข้างกังวล
ดิสก์ตายกันแบบสุ่มอยู่เสมอ และนั่นก็เป็นหนึ่งในเหตุผลที่ Sun สร้าง ZFS ขึ้นมา
สรุปสั้นมาก ๆ คือเธรดบน Mastodon กำลังชี้ไปที่ https://zrepl.github.io
“zrepl คือโซลูชันแบบครบวงจรในที่เดียวสำหรับการทำ ZFS replication”
ตัวอย่างเช่น ถ้าใช้ S3 เป็นสตอเรจได้โดยตรงก็คงเจ๋งดี
Zrepl คือหนึ่งในเหตุผลใหญ่ที่ทำให้ผมใช้ชีวิตแบบดิจิทัลโนแมดได้อย่างสบายใจ
มีสคริปต์ที่รันประมาณคืนละครั้ง เปิด ZFS pool ที่ป้องกันด้วย LUKS ซึ่งมี header แยกต่างหาก แล้วคัดลอก snapshot ทั้งหมดไปยัง NVME enclosure ที่อยู่ใน “กระเป๋า” ซึ่งไม่เคยห่างตัวผมเลย
ด้วยคอนฟิกนี้รวมกับ NixOS ผมสามารถ provision โน้ตบุ๊กเครื่องใหม่ที่เหมือนเดิมได้ภายในประมาณ 10 นาที ช่วงหลังผมยังเพิ่มการทำ offsite replication เข้าไปด้วย ดังนั้นต่อให้โดนปล้นแบบหนักจริง ๆ โอกาสที่จะสูญเสียข้อมูลอย่างร้ายแรงก็แทบเป็นศูนย์
Zrepl เป็นซอฟต์แวร์ที่ยอดเยี่ยมจริง ๆ เริ่มใช้งานก็ง่าย แต่ก็ละเอียดและทรงพลังพอที่จะปรับแต่งได้ทุกจุดเมื่อจำเป็น จะชมแค่ไหนก็ยังไม่พอ
การทำ สแนปช็อตทุก 10 นาที ของไฟล์ซิสเต็มอาจมีผลทำให้ SSD พังได้หรือไม่?
ตามสัญชาตญาณแล้ว ต่อให้ถ่ายสแนปช็อตบ่อยมาก ปริมาณการเขียนที่เพิ่มขึ้นก็น่าจะน้อยพอสมควร ถึงอย่างนั้นถ้ามีการวัดแบบเป็นวิทยาศาสตร์ก็น่าจะดี
เมื่อก่อนผมเคยดูแลเซิร์ฟเวอร์บางเครื่องที่ถ่ายสแนปช็อตด้วย ZFS ทุกนาที ทุกชั่วโมง และทุกวัน สแนปช็อตรายนาทีจะถูกลบหลัง 60 นาที และมีงาน cron จากอีกเครื่องหนึ่งคอยแบ็กอัปสแนปช็อตรายชั่วโมงและรายวัน สแนปช็อตรายชั่วโมงจะเก็บไว้ราว 72 ชั่วโมง และสแนปช็อตรายวันจะเก็บถาวร สแนปช็อตรายนาทีมีไว้เพื่อย้อนความผิดพลาดจากการทำ SQL migration ด้วยมือ และมันก็ใช้ได้ผลดี
ตอนนี้ผมก็ยังใช้ ZFS บนเซิร์ฟเวอร์ FreeBSD อยู่ แต่โปรเจ็กต์ปัจจุบันมีทราฟฟิกต่ำ และการเปลี่ยนแปลงข้อมูลสำคัญก็ไม่ค่อยเกิดขึ้นแล้ว ดังนั้นบนเซิร์ฟเวอร์ส่วนตัวผมจึงถ่ายสแนปช็อตด้วยมือตอนประมาณสัปดาห์ละครั้ง และสั่งแบ็กอัปจากอีกเซิร์ฟเวอร์ด้วยมือ อีกทั้งตอนนี้ผมสแนปช็อตเฉพาะส่วนของไฟล์ซิสเต็มที่มีฐานข้อมูล PostgreSQL และข้อมูลแอปพลิเคชันเท่านั้น ข้อมูลระบบปฏิบัติการผมไม่ได้ใส่ใจมากเหมือนเดิมแล้ว ถ้าเกิดฮาร์ดแวร์พังรุนแรง ก็แค่ติดตั้ง OS ใหม่ จดค่าตั้งสำคัญไว้ และตั้งให้สคริปต์แบ็กอัปคัดลอกค่าเหล่านั้นแทนของจุกจิกอื่น ๆ ตอนที่มันรัน
สแนปช็อตแทบไม่ได้เขียนอะไรเพิ่ม และทั้ง SSD กับ ZFS ก็ใช้ copy-on-write เหมือนกัน นั่นคือ ต้นทุนการเขียนหลังมีสแนปช็อตก็เท่ากับก่อนมีสแนปช็อต
แต่ยังขาดบริบทอยู่ ทั้ง SSD และ ZFS ไม่ชอบสภาวะที่เต็มหรือเกือบเต็ม หากข้อมูลใช้งานจริงมีประมาณ 650GB และไดรฟ์มี 1TB การมีสแนปช็อตอาจทำให้การใช้งานไดรฟ์เกิน 90% ได้ง่าย ซึ่งแค่นั้นก็อาจทำให้ ZFS ทำงานได้ไม่ดีแล้ว
ถ้าสมมติว่ามีข้อมูล 100GB, ขนาดบล็อก 128K และพอยน์เตอร์ 64 บิต ข้อมูลใหม่ที่ต้องเขียนต่อสแนปช็อตน่าจะอยู่ราว 5MB ถ้าทำแบบนี้ 6 ครั้งต่อชั่วโมง หรือ 52,560 ครั้งต่อปี จะมากพอให้ไดรฟ์สึกหรอก่อนเวลาไหม คิดออกมาได้ประมาณ 256GB ต่อปี ซึ่งน่าจะต่ำกว่า 1% ของความทนทานการเขียนของ SSD ดังนั้นถ้าสแนปช็อตทุก 10 นาทีเป็นสาเหตุสำคัญจริง ผมก็คงแปลกใจ
ผมอาจคำนวณผิดก็ได้ และนี่เป็นการประเมินจากแหล่งที่ไม่น่าเชื่อถือเท่าไร ยินดีรับการแก้ไข ถึงอย่างนั้นถ้าตัวเลขที่ผมประเมินยังสูงกว่าความเป็นจริง และแม้แบบนั้นก็ยังไม่น่ากระทบอายุการใช้งานมากนัก ประเด็นนี้อาจไม่ได้สำคัญเท่าไร
ZFS ใช้ copy-on-write ดังนั้นเวลาแก้ไขไฟล์ก็ยังเกิดการเขียนเท่าเดิม เพียงแค่ข้อมูลเก่าบางส่วนจะไม่ถูกลบเท่านั้น
ถ้าอย่างนั้น การเขียน 5MB ทุก 10 นาที ในทางปฏิบัติอาจกลายเป็น 600MB ต่อชั่วโมง, 4.8TB ต่อวันทำงาน 8 ชั่วโมง, และ 24TB ต่อสัปดาห์แบบ 40 ชั่วโมง ซึ่งบนไดรฟ์ 1TB จะเท่ากับ 3.43 DWPD แบบเรียลไทม์ และ 2500TBW ในเวลา 2 ปีแบบเรียลไทม์[2]
ค่าความทนทานการเขียนอย่างเป็นทางการของ SN850 คือ 600TBW แต่ก็มีโอกาสสูงว่าค่านี้ถูกตั้งไว้ต่ำแบบระมัดระวังเพราะเรื่องการรับประกัน น่าสนใจตรงที่ 2500TB ก็เป็นตัวเลขความทนทานที่พบได้บ่อยใน SSD หลายรุ่นในตลาดนี้ มองโดยรวมแล้วจึงฟังดูไม่ถึงกับเป็นไปไม่ได้เสียทีเดียว
ถ้าไดรฟ์ยังไม่ตาย ก็อยากรู้เหมือนกันว่าคอนโทรลเลอร์รายงานอะไรในข้อมูล SMART บ้าง บน Linux ให้รัน
apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sdaแล้วมันจะแสดงตารางออกมา[4] ส่วนบน Windows ก็ลง CrystalDiskInfo[3] ได้เลย1: https://news.ycombinator.com/item?id=29165202
2: DWPD: drive writes per day, TBW: Total Bytes Written - หน่วยเป็นเทราไบต์
3: https://crystalmark.info/en/software/crystaldiskinfo/
4: “Pre-fail” หมายความว่าค่านี้ควรเปลี่ยนเมื่อใกล้เสีย ไม่ได้แปลว่า “อันนี้แย่และกำลังจะพัง” ส่วน “Old_age” หมายถึงเป็นค่าที่เกี่ยวกับอายุ ไม่ได้แปลว่า “ไดรฟ์นี้เก่า” โดยปกติทุกช่องจะแสดงทั้ง Pre-fail และ Old_age เสมอ ผมคิดว่ามีใครสักคนควรเปลี่ยนชื่อมันเป็น “somewhat_boolean” กับ “life_remain” ไปตั้งนานแล้ว
ปกติผมใช้แบ็กอัปแบบ incremental ของ Apple Time Machine ไปยังเซิร์ฟเวอร์ดิสก์หมุนของ Synology
เวลาจะทำงานเสี่ยง ๆ หรืออัปเกรดเครื่อง ผมก็บางครั้งมิเรอร์ไดรฟ์ภายในไปยัง SSD ภายนอกด้วย วิธีนี้ใช้ได้ดี การกู้คืนจาก Time Machine อาจช้าพอสมควร แต่ข้อมูลสำคัญส่วนใหญ่ของผมอยู่ใน Git และสตอเรจที่โฮสต์ไว้แล้ว เลยไม่เคยเป็นปัญหาใหญ่ ผมจะใช้ Time Machine เป็นครั้งคราวตอนที่อยากกู้ไฟล์เดี่ยวกลับมา
ผมก็มีไดรฟ์ SanDisk รุ่นอื้อฉาว[0] อยู่ลูกหนึ่งเหมือนกัน แต่ไม่ได้ใช้กับงานสำคัญ มีไว้เก็บเกมประมาณนั้น ในฐานะผู้ใช้ Mac เกมไม่ใช่ปัจจัยใหญ่ และถ้ามันพังไปก็ไม่ถึงกับต้องร้องไห้
[0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/
ดูเหมือนว่าจะทำงานได้ดีกว่าการแบ็กอัปอัตโนมัติหรือแบบตามเวลาของ Apple มาก
สแนปช็อตของฉันถูกเข้ารหัสจากเครื่องต้นทาง NAS อ่านไม่ได้ ซึ่งเป็นจุดที่เจ๋งดี
ดังนั้นถ้าจะใช้แบ็กอัป ก็ต้องกู้คืน wrapper key สำหรับการเข้ารหัสด้วย ไม่ได้โกหกเลยว่ามันค่อนข้างน่ากลัวจนกว่าจะยืนยันได้ครั้งแรกว่าสามารถถอดรหัสข้อมูลได้
อย่าคิดว่าวิธีแบ็กอัปแบบทำเองจะใช้งานได้จริง จนกว่าจะตรวจสอบเป็นระยะแล้วว่าสามารถกู้คืนข้อมูลได้จริง
อนาคตอันใกล้ของ Linux ในที่นี้คือ bcachefs
https://bcachefs.org/
แต่การผลักดันเข้า upstream ก็กำลังดำเนินอยู่
ข้อความที่ว่า “มันค่อนข้างน่ากลัวจนกว่าจะยืนยันได้ครั้งแรกว่าสามารถถอดรหัสข้อมูลได้” ฟังดูเหมือนขั้นตอนนี้ถูกทดสอบและจัดทำเอกสารไว้น้อยกว่าที่ควร
สำหรับระบบใช้งานในบ้านหรือเดสก์ท็อปส่วนตัว นี่ไม่ใช่เรื่องที่พบได้ยากมากนัก ถึงอย่างนั้นก็คงไม่อยากมานั่งแกะขั้นตอนกู้คืนสด ๆ หน้างานบนเซิร์ฟเวอร์โปรดักชัน
ตอนที่โหลดไม่สำเร็จก็สิ้นหวังอยู่ชั่วครู่ แต่ไม่นานก็รู้ตัวว่าพลาดตรงไหน ในช่วงเวลาที่มันล้มเหลวแบบนี้ ช่องโหว่ทุกจุดของกระบวนการจะปรากฏชัดเจนขึ้นมาอย่างน่าตกใจ