Це залежить від вашого рівня параної. Через те, як SSD обробляє запис даних, робити нуль один раз на SSD не так добре, як це робити на жорсткому диску.
Коли ви пишете певну сторінку даних на HD, нові дані просто записуються над старими даними, замінюючи їх. Напишіть нулі на весь диск, і всі старі дані вже не будуть. SSD-диски, з іншого боку, не можуть просто перезаписати окремі сторінки. Щоб замінити дані на сторінці, спочатку слід стерти старі дані, а SSD не можуть стерти окремі сторінки; вони повинні стерти цілі блоки, що складаються з багатьох сторінок.
Тож, що трапляється, коли ви просите SSD перезаписати, скажімо, сторінку №5, це те, що SSD залишає дані на сторінці №5 у спокої, але позначає їх як недійсні, виділяє ще одну порожню сторінку (скажімо, № 2305), пише нових даних на сторінці № 2305, і зазначає, що наступного разу, коли ОС запитує сторінку №5, замість цього вона повинна отримати № 2305. Оригінальні дані сторінки №5 засідають там до деякого пізнього часу, коли накопичувачу потрібно більше місця, не відсуває залишки дійсних сторінок від блоку та видаляє їх. SSD мають більшу фізичну пам’ять, ніж вони піддають комп’ютеру, тому вони можуть деякий час перемикати такі блоки, перш ніж насправді щось стерти (а коли вони справді щось стирають, немає хорошого способу передбачити, які блоки залишків даних будуть вибирати для стирання). Дивіться цей огляд AnandTech для отримання детальної інформації (попередження: вона досить довга, а відповідні речі розкинуті навколо).
Чистий результат: якщо ви записуєте нулі на "цілий" диск, ви фактично не перезаписали всі старі дані. Ви були оновлені таблиці переведення контролера так , щоб він ніколи не буде повертати старі дані в ОС (ці сторінки все недійсні). Але якщо когось досить жорсткого, щоб обійти контролер, він міг би повернути частину ваших даних.
Перезапис двічі, ймовірно, спрацює, але це залежить від стратегії розподілу контролера. Переписування двічі випадковими даними ( diskutil randomDisk 2 /dev/diskN) трохи ймовірніше, але все ж не гарантується. Обидва вони також мають деякі погані побічні ефекти: вони використовують деякий час роботи накопичувача, а також збільшують логічну фрагментацію на SSD, знижуючи його ефективність запису.
Зауважте, що останні версії графічної утиліти OS X відключають захищені параметри стирання на SSD (з причин, обговорених вище), але версія командного рядка все ж дозволяє їх. До речі, я також бачив кілька рекомендацій щодо безпечного стирання SSD, перетворивши їх у зашифрований формат, але це (якщо щось таке) трохи менш безпечно, ніж перезапис випадковими даними.
Найкращим способом безпечного видалення SSD є використання вбудованої функції захищеного стирання контролера. Це повинно (якщо дизайнери контролерів виконали свою роботу) справді видалити всі блоки, а також мати побічний ефект від скидання логічної карти сторінки, по суті, дефрагментації її та відновлення її початкової продуктивності. На жаль, більшість утиліт, які я бачив для цього (наприклад , HDDErase CMRR ), працює під DOS, яка не завантажується на Mac. Я знайшов публікацію на макромоторах із (досить складними) інструкціями щодо безпечного стирання завантажувального компакт-диска GParted. Можливо, також можливо використовувати Parted Magic з завантажувальної флешки , але я цього не пробував.
Дослідники лабораторії енергонезалежних систем UCSD перевірили різні способи дезінфекції SSD, "стервши" накопичувач, потім розібравши його, щоб обійти контролер, і перевірили на залишки даних ( резюме , повний папір ). Їх результати здебільшого узгоджуються з тим, що я говорив вище (а також показують, що вбудована команда захищеного стирання не завжди виконується належним чином):
Наші результати призводять до трьох висновків: По-перше, вбудовані команди є ефективними, але виробники іноді застосовують їх неправильно. По-друге, перезаписування всього видимого адресного простору на SSD двічі зазвичай, але не завжди, достатньо для очищення накопичувача. По-третє, жодна з існуючих на жорсткому диску методів санітарії окремих файлів не є ефективною на SSD-дисках.
