DBAN เพื่อล้างแฟลชไดรฟ์


1

ฉันรู้ว่า DBAN สามารถใช้ล้าง HDD ได้อย่างปลอดภัยและฉันรู้ว่าไม่สามารถใช้เช็ดอย่างปลอดภัย SSD ได้

แฟลชไดรฟ์คืออะไร ฉันเข้าใจว่า SSD ใช้หน่วยความจำแฟลช แต่พวกเขาย้ายข้อมูลไปรอบ ๆ ในขณะที่แฟลชไดรฟ์ ฉันรู้ว่า DBAN ไม่สามารถลบ SSD ได้อย่างปลอดภัย แต่จะลบแฟลชไดรฟ์อย่างปลอดภัยหรือไม่

และใช่ฉันรู้ว่ามันลดอายุการใช้งานของแฟลชไดรฟ์ฉันไม่สนใจสิ่งนั้น

ขอขอบคุณ


2
แม้แต่การ์ด microSD ขนาดเล็กก็ยังมีคอนโทรลเลอร์ FTL อยู่ซึ่งจะย้ายข้อมูลไปรอบ ๆ : bunniestudios.com/blog/?p=3554
AB

ลิงค์ที่น่าสนใจ จากการอ่านบทความของฉันนี้ใช้สำหรับการแมปออกบล็อก "โรงงานไม่ดี" แทนที่จะย้ายข้อมูลไปรอบ ๆ - ในขณะที่ฉันแน่ใจว่ามันเป็นไปได้ในทางเทคนิคที่จะเกิดขึ้นโดยใช้ชิปที่กำหนดบทความที่แสดงถึงสิ่งที่ตรงกันข้าม ทั่วไป - ชิปที่ไม่ดีบางส่วนถูกนำไปรีไซเคิลในแฟลชไดรฟ์ใหม่
davidgo

ฉันไตร่ตรองการเชื่อมโยงเฉพาะภาพของ microSD ที่เปิดอยู่ซึ่งมีคอนโทรลเลอร์ปรากฏอยู่ มันไม่ได้พูดถึง แต่เหมือนกับอุปกรณ์แฟลชอื่น ๆ มันจะทำการปรับระดับการสวมใส่ (ซึ่งย้ายข้อมูลที่ไม่เกี่ยวข้องเมื่อรับการเขียน) และยอมรับ TRIM / DISCARD ถ้าโฮสต์รองรับ (เช่น: microSD ไม่ได้เชื่อมต่อผ่านอินเตอร์เฟส USB แต่สำหรับเช่นบัส SDIO) สองอันสุดท้ายหมายความว่ามันจะใช้พื้นที่ที่มีอยู่เนื่องจากการคาดการณ์มากเกินไปเพื่อให้ทำงานได้ดีขึ้น
AB

คำตอบ:


1

หากว่าแฟลชไดรฟ์นั้นไม่มีเซกเตอร์เสียพร้อมข้อมูลและไม่ได้จัดเตรียมแบบเดียวกับ SSD (และพวกเขาส่วนใหญ่จะไม่ได้รับการจัดเตรียมมากเกินไป) ปลอดภัยที่จะใช้ DBAN - แม้ว่า DBAN จะทำสิ่งต่าง ๆ มากเกินไป เมื่อ 1 จะพอเพียง)

FWIW, DBAN - ด้วยการผ่านหลายครั้ง - จะทำงานได้ดีในการเช็ด SSD เช่นกัน (ถ้าฝ่ายตรงข้ามของคุณเป็นหน่วยงานรัฐบาลหรือได้รับเงินทุนเท่ากันวิธีเดียวที่จะทำให้แน่ใจได้ว่าข้อมูลของคุณจะไม่สามารถกู้คืนได้อย่างแน่นอนคือใช้ FDE ก่อนที่จะวางข้อมูลใด ๆ ลงในไดรฟ์หรือ - ที่เก็บข้อมูลซึ่งมี FDE ในตัวไดร์ฟ)

ฉันรู้ว่าสิ่งที่ฉันเขียนด้านบนอาจจะขัดแย้ง - โปรดแจ้งข้อกังวลในความคิดเห็นก่อนที่จะลงคะแนนฉัน - แต่เพื่อสรุปการโต้แย้งหลักของฉัน -

  1. ความคิดเรื่องการใช้บัตรผ่านหลายครั้งมาจากหลาย ๆ ปีที่ผ่านมาจากชายคนหนึ่งชื่อปีเตอร์กัตแมน (คนที่ฉันเคยพบ) - "The Gutmann Method" และเป็นกลไกในการล้างข้อมูลจากไดรฟ์ทุกประเภทที่มีอยู่ในเวลานั้น แม้แต่ Gutmann ก็แนะนำว่าคุณไม่จำเป็นต้องวิ่งผ่านเลย - แต่อันไหนขึ้นอยู่กับการขับเคลื่อนของเวลา (มากกว่า 20 ปีที่แล้ว) ต่อมาไดรฟ์ได้เพิ่มความหนาแน่นจนถึงจุดที่เชื่อว่า 1 รอบของศูนย์นั้นเพียงพอที่จะทำให้ไม่สามารถกู้คืนข้อมูลได้แม้ว่าจะมีการโต้แย้งสัปดาห์สำหรับข้อมูลสุ่มหรือการสุ่ม 1 รอบ (เพื่อความชัดเจนฉันสมมติว่าข้อมูลที่มีความหมายคือ 1 ไบต์หรือมากกว่า - อัตราข้อผิดพลาดเมื่อฉันดูครั้งล่าสุดเป็นบางอย่างเช่น 25% ต่อ BIT ครั้งสุดท้ายที่ฉันดูเมื่อหลายปีก่อน

  2. เหตุผลที่การส่ง SSD ครั้งเดียวไม่เพียงพอนั้นเป็นเพราะการปรับระดับการสึกหรอ การเขียนข้อมูลสุ่มหลายรอบจะทำให้กลไกนี้พ่ายแพ้


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

@Louis - บางทีเรากำลังพูดถึงจุดประสงค์ข้าม ความขัดแย้งของฉันคือสำหรับ SSD เมื่อคุณเขียนทับดิสก์หลายครั้งเพราะคุณเขียนทับมากกว่า 1 ดิสก์ที่มีมูลค่าของพื้นที่การเขียนทับจะถูกผลักเข้าไปในพื้นที่ที่มีการเขียนทับมากเกินไป (นี่คือคำสั่งไปยังที่อยู่ในคำถามที่คุณลาดเทใช้ DBAN ปลอดภัยลบ SSD.
davidgo

1
ฉันอยู่กับคุณ ฉันคิดว่ามันปลอดภัยที่จะสมมติว่าแฟลชไดรฟ์ USB ไม่ได้มาพร้อมพื้นที่จัดเก็บพิเศษสำหรับการปรับระดับการสึกหรอดังนั้นเราจึงสามารถเขียนทับไดรฟ์ทั้งหมดได้อย่างแท้จริงเขียนทับทุกอย่าง
หลุยส์

@Louis ฉันจะไม่มั่นใจอย่างนั้น: เนื่องจาก USB แฟลชไดรฟ์ไม่สามารถยอมรับ TRIM / DISCARD ผ่าน USB API ได้โดยเฉพาะอย่างยิ่งพวกเขาต้องการ overprovisionning เพราะเมื่อแฟลชดิสก์เต็ม (เช่นระบบไฟล์เต็ม ) หากไม่มีการจัดเตรียมมากเกินไปมันจะไม่สามารถทำการปรับระดับได้อีกต่อไป เมื่อคุณสามารถออกคำสั่ง TRIM / DISCARD ได้ก็ไม่จำเป็นต้องมีการเตรียมการมากเกินไป
AB

2
@Louis ดูที่en.wikipedia.org/wiki/USB_mass_storage_device_class - พวกเขามักจะระบุว่าเป็น USB Attached SCSI และใช้ SCSI transparent version SCSI และฉันเชื่อว่าคำสั่งที่ใช้นั้นใช้ทั้ง SCSI และ ดิสก์ SATA
davidgo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.