Как вытереть свободное пространство на диске в Linux?

После того как файл уходится запись файловой системы, данные, которые оставляют на жестком диске, являются бессмысленной последовательностью 1's и 0. Если Вы надеетесь заменять ту бессмысленную последовательность другой бессмысленной последовательностью, я могу совет некоторые коммерческие продукты для того, чтобы безопасно стереть диски, как arconis.

Я использую dd для выделения одного или нескольких больших файлов для заполнения свободного пространства затем используйте безопасную утилиту удаления.

Выделить файлы с попыткой dd:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Это генерирует названный файл delete_me это составляет 100 МБ в размере. (Здесь bs набор "размера блока" к 1k, и count количество блоков для выделения.)

Затем используйте свою любимую безопасную утилиту удаления (я использовал shred) на файлах, так созданных.

Но ОТМЕТЬТЕ ЭТО: буферизация означает, делаете ли Вы целый диск, Вы не можете получить абсолютно все!

Эта ссылка рекомендует scrub для стирания свободного пространства. Не попробовали его.

У Вас, вероятно, уже есть GNU coreutils пакет, установленный в Вашей системе. Это обеспечивает клочок команды.

Самый быстрый путь, если Вы только нуждаетесь в единственной передаче и просто хотите заменить все нулями:

cat /dev/zero > zero.file
sync
rm zero.file

(выполненный из каталога в файловой системе Вы хотите вытереть),
_{( sync команда является мерой по паранойе, которая гарантирует, что все данные записаны в диск - интеллектуальный диспетчер кэша мог бы решить, что это может отменить записи для любых незаконченных блоков, когда файл является несвязанным),}

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

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Этого должно быть достаточно для остановки кого-то читающего старое содержание файла без дорогой судебной операции. Для немного более безопасного, но медленнее, различная замена /dev/zero с /dev/urandom. Поскольку больше паранойи выполняет несколько шагов с /dev/urandom, хотя, если Вам нужно так много усилия shred утилита от coreutils пакета является способом пойти:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Обратите внимание, что в выше маленького файла измельчен прежде, чем создать большее, таким образом, он может быть удален, как только большее завершено вместо того, чтобы иметь необходимость ожидать его, чтобы быть измельченным, оставляя файловую систему с нулевым свободным пространством в течение времени, которое берет. Процесс клочка с занимает много времени на большой файл и если Вы не пытаетесь скрыться, что-то из NSA не действительно необходимый IMO.

Все вышеупомянутое должно работать над любой файловой системой.

Пределы размера файла:

Как DanMoulding указывает в комментарии ниже, это может иметь проблемы с размером файла limis в некоторых файловых системах.

Для FAT32 это определенно было бы беспокойство из-за предела файла на 2 ГиБ: большинство объемов больше, чем это в эти дни (8 ТиБ предел размера тома IIRC). Можно работать вокруг этого путем передачи по каналу большого cat /dev/zero выходной вывод через split генерировать несколько меньших файлов и скорректировать клочок и удалить этапы соответственно.

С ext2/3/4 это - меньше беспокойства: с 4K блоком по умолчанию/распространенным предел размера файла составляет 2 ТиБ, таким образом, у Вас должен был бы быть огромный объем для этого, чтобы быть проблемой (размер максимальной громкости при этих условиях составляет 16 ТиБ).

С (все еще экспериментальный) btrfs и максимальный файл и размеры тома являются крупным 16EiB.

Под NTFS макс. длина файла больше, чем длина максимальной громкости, в некоторых случаях ровная.

Начальные точки для большего количества информации:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Виртуальные устройства

Как упомянуто в комментариях недавно, существуют дополнительные соображения для виртуальных устройств:

• Для редко выделенных виртуальных дисков другие методы, такие как используемые zerofree будет быстрее (хотя, в отличие от этого, cat и dd это не стандартный инструмент, что можно полагаться на то, чтобы быть доступным в в значительной степени любой подобной Unix ОС).

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

• Даже для виртуальных устройств фиксированного размера, Вы не можете иметь никакого контроля над тем, где устройство живет физически, таким образом, оно могло быть перемещено вокруг его текущего местоположения или на новый набор физических дисков в любое время и большинства, которое можно вытереть, текущее местоположение, не любые предыдущие местоположения, блок, возможно, находился в прошлом.

• Для вышеупомянутых проблем на виртуальных устройствах: если Вы не управляете хостом (хостами) и можете сделать безопасную очистку их освобожденного пространства, позже вытирающего диски в VM или перемещающего виртуальное устройство вокруг, нет ничего, что можно сделать об этом после факта. Единственное обращение за помощью должно использовать полное шифрование диска от запуска, таким образом, ничто незашифрованное не является каждым записанным к физическим средам во-первых. Может все еще быть призыв к очистке свободного пространства в VM, конечно. Обратите внимание также, что FDE может сделать редкие виртуальные устройства намного менее полезными, поскольку слой виртуализации не может действительно видеть, какие блоки не использованы. Если слой файловой системы ОС отправляет команды для обрезки на виртуальное устройство (как будто это - SSD), и виртуальный контроллер интерпретирует их, то это может решить это, но я не знаю ни о каких обстоятельствах, где это на самом деле происходит, и более широкое обсуждение этого является вопросом для в другом месте (мы уже рядом с тем, чтобы быть вне темы для исходного вопроса, поэтому если это возбудило Ваш интерес, некоторое экспериментирование и/или последующие вопросы могут быть в порядке).

Вот то, как сделать это с GUI.

1. Установка BleachBit
2. Выполненный как корень путем нажатия на Applications - Системные Инструменты - BleachBit как Администратор.
3. В предпочтениях скажите это, какие пути Вы хотите. Обычно это предполагает их хорошо. Вы хотите включать один записываемый путь для каждого раздела. Обычно это-/home/username и/tmp, если они не тот же раздел, в этом случае просто выберите тот.
4. Проверьте поле System - Свободное пространство на диске Очистки.
5. Нажмите Delete.

Усовершенствование BleachBit по dd (который иначе очень хорош) состоит в том, когда диск наконец полон, BleachBit создает маленькие файлы для стирания inodes (который содержит метаданные как имена файлов, и т.д.).

ПРЕДУПРЕЖДЕНИЕ

Я был потрясен тем, сколько файлы photorec могли получить от моего диска, даже после стирания.

Существует ли больше безопасности в заполнении "свободного пространства", только 1 раз с 0x00 или 38 раз с различными cabalistic стандартами является большим количеством академического обсуждения. Автор оригинальной статьи 1996 года на уничтожении записал себе эпилог, говоря, что это является устаревшим и ненужным для современных аппаратных средств. Нет никакого зарегистрированного случая физически заменяемых данных, обнуляет и восстановленный впоследствии.

Истинная хрупкая ссылка в этой процедуре является файловой системой. Некоторые файловые системы резервируют пространство для специального использования, и это не сделано доступным как "свободное пространство". Но Ваши данные могут быть там. Это включает фотографии, персональные электронные письма простого текста, безотносительно. Я только что погуглил reserved+space+ext4 и изучил это 5% из моего home раздел был зарезервирован. Я предполагаю, что это то, где photorec найденный большой частью моего материала. Заключение: уничтожающий метод не является самым важным, даже многопроходный метод все еще оставляет данные на месте.

Можно попробовать # tune2fs -m 0 /dev/sdn0 прежде, чем смонтировать его. (Если это будет корневым разделом после перезагрузки, удостоверьтесь выполненные -m 5 или -m 1 после размонтирования его).

Но тем не менее, так или иначе, может быть некоторое оставленное пространство.

Единственный действительно безопасный путь состоит в том, чтобы вытереть целый раздел, создать файловую систему снова и затем восстановить Ваши файлы от резервного копирования.

Быстрый путь (рекомендован)

Выполненный из каталога в файловой системе Вы хотите вытереть:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

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

Это должно быть достаточно хорошо для большинства людей.

Медленный (параноидальный) путь

Нет никакого зарегистрированного случая данных, восстанавливаемых после вышеупомянутой очистки. Это было бы дорого и требование ресурса, если это возможно, вообще.

Все же, если бы у Вас есть причина думать, что секретные агентства потратили бы много ресурсов для восстановления файлов, это должно быть достаточно:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Требуется намного более длительное время.

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

Очень медленный путь (сумасшедший параноик)

Даже автор оригинальной статьи 1996 года на уничтожении записал эпилог, говоря, что это является устаревшим и ненужным для современных аппаратных средств.

Но если уже у Вас есть много свободного времени, и Вы не возражаете тратить впустую свой диск с большой перезаписью, там это идет:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Примечание: это чрезвычайно эквивалентно использованию безопасного - удаляют инструмент.

Перед редактированием это сообщение было переписыванием David Spillett. Команда "кошки" производит сообщение об ошибке, но я не могу записать комментарии к сообщениям других людей.