Стереть SSD надёжно: почему обнуление работает не так, как на HDD

MAATRIX

Если вы когда-то списывали сервер или отдавали диск в утиль, вы наверняка помните привычный ритуал для HDD: прогнать dd if=/dev/zero пару раз, и можно спать спокойно. С SSD этот же ритуал даёт ложное чувство безопасности — часть данных физически может остаться на чипах памяти даже после многократной перезаписи всего видимого объёма диска. Причина в том, как SSD вообще устроен внутри, и разбираться в ней стоит один раз, чтобы потом не гадать, действительно ли диск, который вы отдаёте вместе с сервером или сдаёте в утилизацию, чист.

Почему перезапись логического адреса не значит перезапись физической ячейки

На HDD всё просто: логический адрес блока (LBA) почти всегда соответствует одному и тому же физическому месту на магнитной пластине. Записали новые данные по тому же LBA — старые данные физически затёрты новыми магнитными доменами на том же участке диска. Отсюда и работали классические методы гарантированного стирания HDD: несколько проходов перезаписи гарантированно перекрывали именно те физические сектора, где лежали исходные данные.

На SSD между операционной системой и физическими ячейками NAND-флеш стоит FTL (Flash Translation Layer) — слой прошивки контроллера, который держит таблицу соответствия логических адресов физическим блокам и постоянно её меняет. Об этом же слое подробно рассказано в разборе про wear leveling: контроллер намеренно не пишет новые данные поверх тех же физических ячеек, а перекладывает их в наименее изношенные свободные блоки, чтобы равномерно распределить ресурс записи по всему чипу. Это защищает диск от преждевременного износа — но именно это же превращает наивную перезапись в ненадёжный способ удаления.

Когда вы «перезаписываете» файл на SSD, происходит следующее:

• ОС отправляет запись по тому же логическому адресу, что и раньше;
• FTL находит для этой записи новый, менее изношенный физический блок;
• данные пишутся в новое физическое место;
• старый физический блок с прежним содержимым помечается как «логически невалидный», но сами биты в NAND-ячейках остаются нетронутыми — они физически лежат там до момента, пока контроллер не решит стереть этот блок в рамках сборки мусора (garbage collection).

То есть между «файл перезаписан с точки зрения ОС» и «старые данные физически стёрты с чипа» может пройти сколько угодно времени — от секунд до недель, в зависимости от загрузки диска и алгоритма прошивки. Всё это время исходные данные потенциально читаются напрямую с NAND, если есть доступ к чипам в обход контроллера.

TRIM и garbage collection: почему они не решают задачу стирания

TRIM (на NVMe — команда Deallocate, на практике часто называемая тем же словом) сообщает контроллеру, какие логические блоки больше не содержат нужных данных, и их можно освобождать заранее, не дожидаясь новой записи по этому же адресу. Это заметно ускоряет будущие записи и снижает write amplification — тема отдельного разбора: write amplification: почему SSD пишет больше, чем вы ему отдали.

Но у TRIM есть принципиальные ограничения именно как у инструмента гарантированного удаления:

• TRIM асинхронен. Он помечает блок как свободный, но физическое стирание NAND-ячеек контроллер выполняет по собственному расписанию — когда ему это удобно с точки зрения garbage collection, а не сразу по команде.
• TRIM не гарантирован программно. Поддержка зависит от файловой системы, режима подключения диска, слоя виртуализации и RAID-контроллера — часть конфигураций (например, некоторые аппаратные RAID) TRIM попросту не пробрасывают дальше, и подробнее об этом есть отдельный разбор: что происходит с SSD, когда о TRIM забыли.
• Резервная область недоступна операционной системе. У любого SSD есть spare area — блоки, зарезервированные контроллером под ротацию и не видимые пользователю напрямую. Даже идеальный TRIM по всему видимому объёму не гарантирует, что старые копии данных не осели именно там в процессе прошлых циклов wear leveling.
• Кеш и промежуточные буферы. Часть контроллеров использует небольшую SLC-кеш-область для ускорения записи «на лету», и данные могут какое-то время физически существовать в двух местах — в кеше и в основном массиве TLC/QLC — прежде чем кеш освободится.

Вывод простой: TRIM — отличный механизм для производительности и здоровья диска, но он не проектировался как гарантия безопасного удаления и не даёт такой гарантии сам по себе.

Почему многократная перезапись как для HDD не работает — и вредит SSD

Классические методы гарантированного стирания HDD (несколько проходов случайными паттернами, известные по старым военным и государственным стандартам) исходили из физики магнитной записи и адресации «один LBA — одно физическое место». На SSD оба этих допущения не работают:

1. Перезапись LBA не бьёт по тем же физическим ячейкам — из-за FTL и wear leveling, как описано выше, старые данные могут физически пережить десятки «перезаписей» того же логического адреса.
2. Резервная область и переразмеченные блоки вообще не адресуются напрямую — многократная перезапись видимого пользователю объёма диска физически не затрагивает spare area и блоки, выведенные из ротации как «слабые», но ещё хранящие старые данные.
3. Каждый лишний проход перезаписи — это реальный расход ресурса записи (TBW/DWPD), который у SSD ограничен физически — подробнее в материале про ресурс SSD и TBW. Несколько проходов «стирания по-старому» на SSD не увеличивают надёжность удаления, зато ощутимо приближают диск к исчерпанию ресурса — двойной проигрыш.

Ниже — сравнение, почему подход, который был правильным для HDD, для SSD не переносится один в один.

Штатное решение: команды безопасного стирания на уровне самого накопителя

Правильный инструмент для SSD — не перезапись через файловую систему, а команда, которая выполняется прошивкой самого контроллера и работает на уровне, недоступном обычной записи данных. Смысл в том, что стирание инициируете вы, а физически его выполняет контроллер, у которого есть доступ ко всем блокам диска — включая резервную область и переразмеченные ячейки, которые операционная система вообще не видит.

Для этого производители дисков предусмотрели штатные команды, стандартизированные на уровне интерфейса накопителя:

• Для SATA-дисков — ATA Secure Erase. Команда, встроенная в стандарт ATA, инициирует полный сброс всех пользовательских блоков на уровне контроллера. Есть режим Enhanced Secure Erase — на дисках, которые его поддерживают, он в дополнение к обычному сбросу перезаписывает ячейки заданным паттерном на уровне прошивки.
• Для NVMe-дисков — команда Format с указанием режима стирания (Secure Erase Settings) и отдельная команда Sanitize. Format с соответствующим параметром запускает либо криптографическое стирание (см. ниже), либо блочное стирание пользовательских данных силами контроллера. Sanitize — более строгая операция, которая по спецификации NVMe должна гарантированно затронуть и восстановленные (переразмеченные) блоки, а не только текущую активную область.
• Криптографическое стирание (crypto erase / cryptographic erase). Если диск умеет шифровать данные на лету (self-encrying drive, SED) собственным внутренним ключом, «стирание» может свестись к уничтожению этого ключа контроллером — тогда все ранее записанные данные мгновенно становятся нечитаемым шифротекстом без него, физически ничего не перезаписывая. Это самый быстрый вариант из штатных, но он полагается на то, что реализация шифрования в прошивке действительно надёжна, а сам ключ контроллер не хранил где-то ещё в открытом виде.

Общий принцип у всех этих команд один: стирание выполняет тот же контроллер, что управляет wear leveling и знает реальную физическую карту диска — а не операционная система, которая видит только логические адреса. Именно поэтому такие команды и дают гарантию, которую не даёт перезапись через dd или аналогичные утилиты уровня файловой системы.

Практический план для сервера перед передачей или списанием диска

Если вы администрируете арендованный или собственный сервер и диск подлежит замене, возврату провайдеру или утилизации, порядок действий обычно такой.

Сначала определите тип накопителя и доступный инструментарий:

lsblk -d -o NAME,ROTA,MODEL

Поле ROTA со значением 0 означает твердотельный диск (SSD/NVMe), 1 — механический (HDD).

Для NVMe-дисков используется nvme-cli:

nvme id-ctrl /dev/nvme0 | grep -i sanitize
nvme sanitize /dev/nvme0 --sanact=1
nvme sanitize-log /dev/nvme0

Первая команда покажет, какие режимы санитизации вообще поддерживает конкретная модель — набор возможностей у разных контроллеров различается, и не все диски поддерживают все режимы. Вторая запускает операцию (конкретные значения sanact зависят от прошивки — сверяйтесь с документацией на модель), третья позволяет отслеживать прогресс, поскольку полное стирание может занимать заметное время в зависимости от объёма и модели диска.

Для SATA SSD — hdparm:

hdparm -I /dev/sda | grep -i security
hdparm --user-master u --security-set-pass p4ss /dev/sda
hdparm --user-master u --security-erase p4ss /dev/sda

Первая команда покажет, поддерживает ли диск Secure Erase и не заблокирован ли он «замороженным» состоянием (frozen) — это частая ловушка: некоторые системы и материнские платы блокируют команду безопасности после старта, и тогда диск нужно физически переподключить (hot-plug или перезагрузка с другого контроллера) перед стиранием.

Отдельный практический совет, который сильно упрощает жизнь: если диск с самого начала эксплуатации был зашифрован (например, через LUKS на Linux), то для гарантированного уничтожения данных перед списанием достаточно надёжно уничтожить ключевой материал шифрования — заголовок LUKS с ключевыми слотами — а не стирать весь массив физически. Это на порядок быстрее полного Sanitize на больших дисках. Как это соотносится с другими сценариями шифрования диска и что именно оно закрывает, разобрано в статье шифрование дисков: что защищает, а что нет.

После стирания стоит выборочно проверить результат — прочитать несколько случайных участков диска низкоуровневой утилитой и убедиться, что данные заменены на предсказуемый паттерн (обычно нули или единицы, в зависимости от режима), а не остались читаемым содержимым.

Когда штатного стирания недостаточно: шифрование заранее и физическое уничтожение

Штатные команды стирания — это индустриальный стандарт для подавляющего большинства сценариев: замена диска, возврат оборудования провайдеру, плановая утилизация. Но для по-настоящему критичных данных — например, при работе с персональными данными под регуляторными требованиями, где нужна не просто уверенность, а доказуемая гарантия уничтожения физического носителя, — практика обычно строже:

• Шифрование диска с первого дня эксплуатации. Если весь массив изначально зашифрован на уровне блочного устройства, у вас всегда остаётся быстрый и надёжный запасной вариант — криптографическое уничтожение ключа, даже если по каким-то причинам штатная команда стирания на конкретном диске недоступна или не сработала. Это не отменяет физическое стирание, а добавляет к нему независимый второй рубеж.
• Физическое уничтожение накопителя. Самый надёжный вариант из всех — механическое разрушение чипов NAND-памяти до состояния, когда считывание данных физически невозможно. В отличие от механических дисков, для SSD не работает размагничивание (degausser) — флеш-память хранит заряд, а не намагниченность, так что этот метод, стандартный для HDD, на SSD просто бесполезен. Для SSD применяют промышленное измельчение (шреддинг) с достаточно мелкой фракцией, чтобы отдельные чипы памяти были физически разрушены, а не просто отделены друг от друга.
• Документальное подтверждение уничтожения. Для регулируемых данных обычно важен не только сам факт стирания, но и акт/сертификат от организации, которая его выполнила — это то, что реально спрашивают при проверке соответствия, а не сам факт «мы что-то стёрли».

Здесь стоит подчеркнуть: для подавляющего большинства серверов и обычных данных штатной команды безопасного стирания на уровне контроллера более чем достаточно, и физическое уничтожение — это не универсальная рекомендация всем подряд, а мера для узкого круга по-настоящему критичных случаев, где цена ошибки несопоставимо выше стоимости замены диска.

Частые вопросы