"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX
Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:
Сначала думал сделать что-то типа или , но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?
Вы проверяли, что skip корректно отработал?
комментариев: 9796 документов: 488 редакций: 5664
Сначала у меня не сработало из-за того, что в первом dd задал ещё и count. При этом, какой бы большой count не задавать, получалось
А теперь, сравните без skip:
и со skip:
Со skip не работает второй dd и ничего не выдаёт на выход, в то время как из первого dd всё проходит через openssl и pv (или mbuffer), вот только куда?
Попробуйте
Хотя мне кажется что достаточно пропустить один блок: skip=1.
Но только перед каждым циклом очистки нужно готовить CD для перезаписи.
комментариев: 9796 документов: 488 редакций: 5664
Но только если не использовать count, даже со множителем.
И опять же, просто при таком выводе маскируется ошибка dd: `standard input': cannot skip to specified offset:
Можно перенаправить её в файл даже из "работающей" команды:
комментариев: 9796 документов: 488 редакций: 5664
С gpg -c возникает такая же ошибка на dd, он ещё и заметно медленнее.
С другой стороны, ещё один повод задуматься, стоит ли доверять внешним командам в нестандартных вариантах использования, когда дело касается не наглядных результатов, а безопасности. Как бы такой, доведённый до абсурда Unix-way, не вышел боком. Может надёжнее всё-таки нулями в сам LUKS-контейнер? Все команды LUKS легко запомнить.
С учётом современной плотности записи на диски... наверное, однократной перезаписи достаточно. Я иногда тру как dd if=/dev/zero of=/path/to/file count=999999999999999, где file — файл на файловой системе, которую надо зачистить. Не знаю, насколько это безопасно. Обычно жду, когда dd вылетит с ошибокой, жалуясь на недостаток места, и считаю, что относительно безопасно всё затёрто.
Но тут есть тонкости, типа имён вложенных директорий, которые, возможно, могут как-то остаться. Например, обычная директория занимает 4.0K при вызове как ls -lad /path/to/dir, но у меня есть директория на ext3, в которой содержалось очень много мелких файлов. После того, как я зашреддил те файлы, размер директории так и остался большим — 1.3M, хотя внутри неё пусто. В общем, чудеса. Для серьёзного затирания информации вряд ли стоит полагаться на такой метод, но, если вы отдаёте себе отчёт во всех подводных камнях, то можно.
Для себя определил наиболее безопасный способ уничтожения информации с сохранением работоспособности диска:
1. Встроенная ATA-команда Secure Erase (заполняет нулями всё доступное место, а не только LBA)
2. Тройной проход dd с заполнением устройства случайными битами.
В общем-то первого пункта достаточно, второй скорее по традиции, для перестраховки. Это относится к hdd. С флешем и CD/DVD могут быть свои тонкости.