Безопасно забить диск фигнёй

Всё ли я сделал правильно?

Нет, забивать диск нужно не фигнёй, а программой Microsoft Bob, которую писал Gaben, когда работал в Microsoft.

https://technet.microsoft.com/ru-ru/magazine/2008.07.windowsconfidential.aspx

То есть, надёжнее скачать это, выводить по while true, а вывод ddшить на диск?

Я понял юмор. А если серьёзно?

cat /dev/zero > /dev/sda вполне бы хватило

Я этот метод на archwiki прочитал, он там рекомендован. Понимаю, что мб оверкилл. Для меня главное знать, не «недокилл» ли.

Лучше диск кирпичом забить. Безопаснее будет. :)

Мне его ещё использовать.

shred

dd bs=512 if=/dev/zero of=/dev/mapper/sda seek=$((`blockdev --getsz /dev/sda` - 2049000)) #затереть последний гиг ещё раз, на всякий случай,

напиши поподробнее, пожалуйста..

какой ещё такой всякий случай?

ты же только-что (командой выше — ``dd if=/dev/zero of=/dev/mapper/sda bs=256M``) *уже* записал *точно_такие_же* же данные *туда_же* (в этот же последний гиг, в том числе!).

какие-такие у тебя могут быть основания подозревать что именно последний гиг (почему именно он?) нуждается в повторной операции?

man shred Если уже напортачил rm-ом, то cat /dev/random > /dev/sda

random или urandom в теории даст больше проблем, если твой жесткий будут исследовать на каком-нибудь оборудовании, стоимость работы часа которого сопоставима с полётом на Луну.

Ну а самый надёжный способ - жесткий молоточком как следует, а лучше напильничком или шлифмашинкой до состояния порошка... А потом порошок можешь расплавить/растворить в кислоте/развеять по ветру/etc.

Я что-то подумал, что если bs=256M, то последние 256 метров могут не целиком быть затёрты - tac | string подтвердили мои опасения. Гиг - на всякий случай.

а какая религия, напомните, запрещает использовать cat вместо dd?

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

Ты так говоришь, будто единственное, что может помешать что-либо сделать - это религия.

просто с этой сектой я сталкиваюсь уже тысячу раз. вы правы, это не религия, это просто секта какая-то... я уже лет 15 вместо dd использую cat там, где это возможно... И Я ЩАСЛИВ. уверуйте, и обретёте счастье (и избавитесь от хвостов и велосипедов)

Ты слишком много значения придаёшь инструментам. О БОЖЕ, НЕТ! ОН ЗАБИВАЕТ ГВОЗДИ МОЛОТКОМ, КОГДА ХВАТИЛО БЫ И РУК!

я только спросил, как секта называется...

Можно было ещё /dev/urandom использовать для большей надёжности. Если кому-то попадёт в руки диск, теоретически что-то можно восстановить в случае /dev/zero исследуя остаточную намагниченность и т.п. Рандомные данные это усложнят.

http://serverfault.com/questions/6440/is-there-an-alternative-to-dev-urandom

Он то и делает, только через задницу (но быстрее, т.к. urandom тормоз).

Нет, у меня от этого брат умер.

Я что-то подумал, что если bs=256M, то последние 256 метров могут не целиком быть затёрты - tac | string подтвердили мои опасения. Гиг - на всякий случай.

нет.. давай здесь подробнее разберём.

это очень важный момент.

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

(даже в ситуации когда размер накопителя НЕ кратен 256 Мибибайтам).

****************************** начало ******************************

создаём образ, набитый непонятными байтами. размер образа: 1000000000 байт.

(заметим что 1000000000 НЕ делится нацело на число 256*1024*1024)

[regular-user@localhost ~]$ cd ~/Desktop/
[regular-user@localhost Desktop]$ truncate -s 1000000000 test.img
[regular-user@localhost Desktop]$ sudo losetup /dev/loop0 test.img
[regular-user@localhost Desktop]$ 
[regular-user@localhost Desktop]$ 
[regular-user@localhost Desktop]$ sudo dd if=/dev/urandom of=/dev/loop0
dd: writing to ‘/dev/loop0’: No space left on device
1953126+0 records in
1953125+0 records out
1000000000 bytes (1.0 GB) copied, 80.0954 s, 12.5 MB/s
[regular-user@localhost Desktop]$ 

проверим что находится внутри хвоста образа:

[regular-user@localhost Desktop]$ 
[regular-user@localhost Desktop]$ sudo hexdump -C /dev/loop0 | tail
3b9ac970  1e e0 65 56 05 dc 68 07  bb 89 4c f8 5e 3e 47 61  |..eV..h...L.^>Ga|
3b9ac980  6a 7b 11 ce e1 96 13 46  c6 23 13 f3 a7 05 05 80  |j{.....F.#......|
3b9ac990  06 48 68 76 f5 3a 1a bf  45 19 52 9a 05 dc df ee  |.Hhv.:..E.R.....|
3b9ac9a0  48 b4 ac a4 f2 bd 53 e6  43 5f 91 cb 2d 9b 3a c2  |H.....S.C_..-.:.|
3b9ac9b0  23 e0 e8 c8 ad c6 b4 b6  80 e8 a5 b5 c0 1d 36 cb  |#.............6.|
3b9ac9c0  29 38 48 6a b1 2b dd ba  82 5d 74 e4 71 a5 45 ff  |)8Hj.+...]t.q.E.|
3b9ac9d0  8e 50 39 e5 e9 64 05 a8  da 22 35 88 2b 46 9f 17  |.P9..d..."5.+F..|
3b9ac9e0  fb e4 9b 58 27 96 18 00  15 1c 44 f1 03 89 8c 93  |...X'.....D.....|
3b9ac9f0  1a 27 d5 3a e6 0a ab 36  81 d0 27 73 8b 91 08 72  |.'.:...6..'s...r|
3b9aca00
[regular-user@localhost Desktop]$ 

а теперь ,ВНИМАНИЕ(!), затираем образ блоками по 256Мибибайт (как ты это и делал)

[regular-user@localhost Desktop]$ 
[regular-user@localhost Desktop]$ sudo dd if=/dev/zero of=/dev/loop0 bs=256M
[sudo] password for regular-user: 
dd: error writing ‘/dev/loop0’: No space left on device
4+0 records in
3+0 records out
1000000000 bytes (1.0 GB) copied, 9.14437 s, 109 MB/s
[regular-user@localhost Desktop]$ 

проверим.. есть ли *хоть_один_байт*, который не затёрся (например вконце? или ещё где?)

[regular-user@localhost Desktop]$ 
[regular-user@localhost Desktop]$ sudo hexdump -C /dev/loop0
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
3b9aca00
[regular-user@localhost Desktop]$ 

всё байты оказались успешно затёртыми(!), не смотря на то что последний 256Мибибайтный-блок не смог успешно записаться.

****************************** конец ******************************

Valdor> Я что-то подумал, что если bs=256M, то последние 256 метров могут не целиком быть затёрты - tac | string подтвердили мои опасения. Гиг - на всякий случай.

user_id_68054>я щаз ниже приведу тебе свой эксперимент, показывающий что последний блок всёравно затерается.

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

Шапка треда

нельзя экономить на безопасности

нее.. я не понял.. :-)

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

что именно в моём эксперименте(*) я сделал не так?

1Гигобайт — слишком мало?

устройство /dev/loop0 — ведёт себя не так как настоящий диск?

недозапись последнего блока — имеет вероятностную характеристику? (нужно проделать эксперимент много раз, а не только 1 раз?)

«Wipe Free Space» можно заюзать, чтобы затереть свободное место. http://wipefreespace.sourceforge.net/

Я её для виртуалок использую, чтобы образы дисков гигабайты лишние не жрали.

У всех современных винтов есть функция security erase. Одно «но», диск нужно лочить security-режимом, что при кривых руках и/или некошерном уровне осадков в Занзибаре может привести к окирпичиванию. Хотя я лично не один десяток повайпал, и ничего.

Некоторые особо упоротые венодры ноутбуков любят включать security-режим по-дефолту с хрен-знает каким паролем, задаваемым фирмварей, что потом выливается в сотни лулзов в случае его кончины или замены жесткого диска.

Можешь взять на заметку.