Pull to refresh

Comments 119

Маны созданы для другого, хотя разделы EXAMPLE было бы неплохо делать поприличнее. Некоторые программы имеют шикарные маны, а у некоторых они вовсе отсутствуют.

Данная статья определенно хорошо описала dd со многих сторон. Хотя я бы побольше внимания уделил использованию dd совместно с pipeline.

И тем не менее — спасибо автору.
Я понимаю. Но очень часто мне нужно какой-то флаг быстренько, смысл помню, а синтаксис — нет. А приходится листать целую простыню. Хотя цепкость английских слов глазами у меня неплохая, но делать так часто бывает лень и я просто гуглю (извините меня).

И чем больше таких статей — там больше простые смертные узнают о прелести таких мелких, но мощный утилит. Спасибо автору ещё раз.
Если я забываю какой-то флаг, но помню про что он, то я делаю что-то типа
man blabla |grep -i -C 2 «ключевое слово нужного флага»
В мане есть встроенный поиск: /blabla для поиска «blabla», а следующее совпадение — N.
Странно, у меня N — предыдущее совпадение. Следующее совпадение — n.
Извиняюсь, не знал что с шифтом обратно ищет. Имел ввиду просто клавишу )
Это не в man а в less. Поставите другой PAGER будут другие шорткаты.
В отсутсвии примеров основная проблема, ещё неплохо бы стандартизировать "--usage", а то у одной программы он выводит понятную справку, у другой — бессмысленный набор аргументов «abcdeXYZ», у третьей его вообще нет.
в официальном man'е не хватает разве что real life примеров, а все опции описаны достаточно внятно
Очередную Вашу статью добавил в избранное. На днях как раз требовалось создать образ диска.
Применив фантазию, с dd можно вообще много чего делать. Первое, что приходит на ум — дополнить файл нулями до нужной длины (нужно при создании образов разделов прошивок, например):

dd if=/dev/zero of=new_file bs=x count=y
dd if=old_file of=new_file bs=x count=y notrail

Т.е. создаем файл-болванку нужного размера, затем начало заменяем своими даными. Параметр notrail запрещает обрезать файл после выполнения операции.
А параметр seek задать не проще? Смысл 2 файла держать-то?
Не всегда проще. Например, в автоматических сборках, когда оригинальный файл тоже нужно для чего-то оставить.
Еще dd'ом удобно вырезать части файла:

dd if=file.bin of=cut bs=1 skip=<оффсет> count=<размер>
… или даже патчить программки:

printf x | dd bs=1 seek=0xdeadbabe count=1 conv=notrunc of=./someapp
+ есть еще одно важное применение dd
$ dd if=/dev/random count=1 > secret.key
хотя я предпочитаю
$ head -c 512 > secret.key
random страшная штука, если её использовать неправильно) Чёрт знает, что она нагенерить может.
для этого надо пропускать через uuencode
Ещё dd можно забивать нулями и рандомами диски перед продажей или утилизацией, пару раз прогнал, удалил, форматнул и информацию уже не восстановить)
Да, я ведь об этом написал :) Реально видел статью, авторы которой на барахолке набрали винтов и восстановили данные. Писали даже, что нашли среди них винт со старого банкомата, в котором хранились номера кредитных карточек. Слабо верится, но если списывать на то, что это было давно — все возможно.
Простите, вечер, читаю через строчку)
Находили финансовые данные, в гигантском количестве порнуху, один мужик даже нашёл данные об испытаниях секретных американских ракет)
ещё удобный способ гонять через сеть образы оптимальным образом:
принимающая:
nc -l 1234 | dd of=/tmp/image.img bs=4096
отдающая:
dd if=/dev/sda bs=4096 | nc 1.2.3.4 1234

В отличии от ssh получается более эффективное использование сети.
В отличие от ssh требует постоянного поднятия слушающей стороны.
SSH же работает не переставая, к тому же обеспечивает уровень шифрования и предоставляет возможность указать конечную точку прямо с передающей стороны.
Да, можно и так, не только сети будет легче, еще и процу, спасибо за комментарий. Просто ssh во первых обеспечит шифрование, во вторых — легче автоматизировать.
Да и безопасность ниже, если интерфейс не изолирован: какое нибудь чудо присосется к порту, на котором слушает nc, и тапки: может залить столько, сколько на винт вместится.
Мне кажется можно и проще. По крайней мере с просто файликом прокатило
out: nc localhost 12345 < /any/file
in: nc -l 12345 > any_file.img
Ага, я тоже частенько неткатом файлы передаю.
В отличии от ssh получается более эффективное использование сети

В чём же? У него даже вон сжатие траффика есть.
Можно еще сжимать данные перед отправкой, если ресурсы позволяют.
Это даже более положительно влияет на пропускную способность сети.

sudo dd if=/dev/SYS/root bs=6M | pigz -c | `ssh host «cat > ~/root.img.gz»

8-ядерная машинка с raid 10 отдает данные диска в темпе 140 — 180 Мб/c
прикольно, жаль pigz нет по дефолту во многих дистрибах. с таким же успехом (если ресурсов много) можно так делать:
nc -l 1234 | bzip2 -d|dd of=/tmp/image.img bs=4096
dd if=/dev/sda bs=4096| bzip2 -9 | nc 1.2.3.4 1234
А еще dd может отображать, сколько данных уже прочитано/записано, для этого нужно отправить процессу сигнал USR1.
Использовал dd для создания загрузочной флешки. Спасибо за статью, самое место ей в избранном.
Спасибо за статью! Однозначно в избранное.
Сегодня завесил комп коммандой (оперативки свободной не было):
dd if=/dev/null of=~/null bs=1024M count=10
Спасибо! Буду вникать. А то пробовал когда-то переехать с одного веника на другой с помощью dd. Так и не разобрался с параметрами и в итоге у меня остаток свободного места на новом винте забивался нулями. Я тогда обошелся cp с кучей параметров, чтобы сохранились права доступа и симлинки.
для этого лучше использовать dump/restore
dd тоже не плохо работает.
Только сначала создать новый диск, потом при помощи dd перенести старый, потом resize2fs или аналогичное по вкусу.

Или gparted в качестве оболочки над этих хозяйством воспользоваться.

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

Насчет lvm согласен. Вчера ставил KDE4, перед установкой сделал snapshot. Не понравилось — откатился.
Я тогда обошелся cp с кучей параметров, чтобы сохранились права доступа и симлинки

rsync не лучше ли примитивного cp?
Чтобы на носителе ничего нельзя было восстановить — можно забить его нулями

это не совсем верно — после нулей данные все равно восстановимы на специальных стендах, хотя это и сильно усложняет работу барахольщикам. лучше использовать urandom как источник :)
Согласен. Я слишком громко сказал «ничего нельзя было восстановить». В этом случае я имел ввиду спец. софт, которые народ качает с торрентов.
Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 1994 год, за 17 лет, уверен, многое изменилось.
Читал давно, написал по памяти, может где-то неточность допустил, но в книгу лезть уже нет сил…
Это похоже на давно поддерживаемый специалистами миф. Некоторые исследователи что-то там писали про восстановление битов с затёртой нулями области диска при помощи электронного микроскопа, но не припомню, чтобы при этом достигли хоть сколько-нибудь существенных результатов, и уж тем более, чтобы эти результаты могли быть применимы к большинству моделей дисков.
Это тот самый миф о остаточной намагниченности? Читал теория, впринципе она имеет право на существоване, но что-то никак не найду отчёта о реальном применении. Очень хотелось бы увидеть такой стенд))
Стирать проще, а далее нет предела фантазии — от молотка до фугасов)
Алгоритм Содержание алгоритма Примечания
Руководство по защите информации МО США (NISPOM)
DoD 5220.22-M, 1995г. Количество циклов записи — 3.
Цикл 1 — запись произвольного кода.
Цикл 2 — запись инвертированного кода.
Цикл 3 — запись случайных кодов. NISPOM запрещает использование этого алгоритма для уничтожения данных с грифом: «СОВ.СЕКРЕТНО»
Альтернативные способы (в соответствии с NISPOМ):
-размагничивание;
-физическое разрушение
Стандарт VISR, 1999г.
(Германия) Количество циклов записи — 3.
Цикл 1 — запись нулей.
Цикл 2 — запись единиц.
Цикл 3 — запись кода с чередованием нулей и единиц.
ГОСТ Р50739-95г.
(Россия) Для классов защиты данных 1..3
Количество циклов записи — 2.
Цикл 1 — запись нулей.
Цикл 2 — запись случайных кодов.
Для классов защиты данных 4..6.
Один цикл записи нулей.
Алгоритм Брюса Шнейера
(Bruce Schneier) Количество циклов записи — 7.
Цикл 1- запись единиц.
Цикл 2 — запись нулей.
Циклы 3..7 — запись случайных кодов
Алгоритм Питера Гутманна
(Peter Gutman) Количество циклов — 35.
Циклы 1..4 — запись произвольного кода.
Циклы 5..6 — запись кодов 55h, AАh.
Циклы 7..9 — запись кодов 92h, 49h, 24h.
Циклы 10..25 — последовательная запись кодов от 00, 11h, 22h и т.д. до FFh.
Циклы 26..28 — аналогично циклам 7..9.
Циклы 29..31 — запись кода 6Dh, B6h.
Циклы 32..35 — аналогично циклам 1..4.

Подробнее
Кроме того, в настоящее время проводятся исследования возможность с помощью МСМ восстанавливать информацию с жестких дисков. Теоретически такая возможность доказана, однако на практике вызывает ряд трудностей. Во-первых, размер одного «скана» составляет обычно 10х10 мкм, в микроскопах с более сложными конструкциями сканера — до 100х100мкм. Поэтому после получения серии данных по магнитному рельефу различных участков диска эти данные необходимо «сшить» для получения полного изображения. Во-вторых, перед записью на диск данные подвергаются специальному преобразованию (RLL-кодирование). Вариантов такого кодирования существует очень много, и в жестких дисках разных моделей даже одного производителя они могут отличаться. Поэтому задача извлечения информации из полученного магнитного рельефа поверхности также не отличается простотой. Тем не менее, разработав специальное программное обеспечение и используя высокие вычислительные мощности современных компьютеров, такую задачу вполне возможно решить.
Возможности магнитного силового микроскопа могут применяться и для несанкционированного получения информации. Траектория движения записывающей головки жесткого диска никогда точно не совпадает с дорожкой (рис. 10). Поэтому между дорожками остаются остатки от предыдущих циклов записи. Для нормальной работы жесткого диска это не имеет значения, так как у современных винчестеров ширина головки считывания меньше ширины головки записи. Однако по магнитному рельефу поверхности, полученному с помощью магнитно-силового микроскопа можно восстановить уничтоженные данные, в том числе и если на место уничтожаемых данных записана новая (несекретная или просто случайная) информация. Поэтому для гарантированного уничтожения секретных данных используются специальные устройства.

Ссылки там и тут
Но цена вопроса должна быть космической ИМХО.
Вот-вот, именно цена вопроса. О реальных случаях использования МСМ кто-то слышал?
после нулей данные все равно восстановимы на специальных стендах

Хоть один пруф покажете? Или «слышал звон»?
Если у вас нет паранои, это ещё не значит, что одной перезаписи всегда достаточно.
Паранойя порой есть. Но неуверенности в том, что одной перезаписи нулями или рандомом недостаточно — в 99,9% случаев нет.
Подобными вещами на уровне атомов будут заниматься разве что какие-то секретные службы в интересах госбезопасности и т.п. Но никак не рядовые полицаи или даже ФБР/ФСБ.
да, одна бабка сказала. чтобы поднять инфу после нулей, достаточно осциллографаи немного удачи.
А как быть с директориями? Монтировать как устройство? Есть пути проще?
используйте криптоконтейнеры.
попробуйте штатную утилиту shred, её вполне достаточно, чтобы и имена файлов привести в негодный вид или затереть лишь конкретную директорию со всем содержимым
Я как-то снимал образ с ноута перед установкой на него Убунты. Раздел с виндой и данными был 150 Гб, я перегонял его на десктоп через dd | gzip | nc, для чего загрузился с LiveCD. Предварительно я прошелся sdelete -z (занулил свободное место), в итоге получился архив 16 Гб.

Это был первый опыт реального использования и dd и nc, и я очень боялся где-то ошибиться и все испортить; но других средств под рукой не было. В результате все получилось, и я проникся крутостью Unix-way неимоверно. :)

Через некоторое время мне понадобилась пара небольших файликов из этого образа. Я стал думать, как бы их так вытащить, не разворачивая его целиком на физический носитель. Так ничего и не придумал.
В Вашем случае помог бы squashfs. Как минимум — добрались бы прозрачно до несжатого образа, а там уже можно fdisk-ом посмотреть расположение разделов и смонтировать раздел через loopback.
Как помог бы? Там был один раздел и на нем NTFS. Проблема в том (как я потом осознал), что к пожатому gzip-ом разделу произвольный доступ не возможен, только последовательный.
Я предлагал использовать squashfs вместо gzip. Тогда можно было бы его смонтировать и получить нормальный доступ к несжатому образу. В том числе и с произвольным доступом.
Хорошо, а как это можно сделать? Так чтобы «на лету». А то свободных 150 Гб нет, на другой машине XP (нормальный порт nc пришлось поискать).
Спасибо. Но вы наверное не заметили, что образ сжатый.
Да, не заметил. :)
Это непаханное поле, похоже. Весьма пригодился бы некий модуль ядра для работы со сжатыми образами.
Оно, конечно, не dd, и общего, если только, название, но мне как-то очень помогло — ddrescue
Да, штука удобная, с её помощью выцеплял файлы с битого винта. Один минус — не может рекурсивно файлы копировать, для этой цели я простой скрипт написал, может, пригодится кому.
Другой вариант — использовать find, при необходимости создавая подкаталоги перед попыткой копирования файла, если их ещё нет.
Я знаю, что есть GNUшная ddrescue и dd_rescue, но отличия у них минимальные, нет?
Можете добавить:
dd часто используется для создания «self-extracted» архивов и инсталяторов на Unix платформах. Чтоб не быть голословным упомяну хотя бы один из фреймворков, который точно так делает — InstallAnyware.
Идея там такая — инсталятор представляет собой sh скрипт, к которому паровозом пприкреплен бинарники собственно инсталятора и прочие необходимые артифакты (например JRE). Скрипт по прописанному в нём смещению отрезает куски с помощью как раз-таки команды dd, а потом запускает инсталятор.
SFX архивы обычно представляют собой шелл-скрипт с приклеенным в конце сжатым tar архивом, извлекается это обычно путём общепления хвоста в отдельный файл, но не припомню, чтобы для этого использовался dd, скорее head/tail
В InstallAnyware точно используется dd. Просто у них файл нужно нарезать на несколько кусков.
куски объединяются элементарно cat'ом, а делятся — split'ом
Ну не я эти скрипты писал. Насколько я помню, они достают из середины JRE и распаковывают его в темп. Потом достают инсталятор и запускают егос этим JRE.
Я не утверждаю, что это нельзя сделать иначе, это просто ещё один пример использования dd. Где-то ещё я видел подобное.
слабо представляю, что можно достать из «середины JRE» ;-)
Из середины файла достаётся JRE, а не из середины JRE.
познакомился с dd когда лет 10-15ть назад на школьный комп, параллельно с виндой 98 воткнул линукс, и оставил виндовый загрузчик живым и невредимым. как раз через dd if=/dev/sda of=loader.bin bs=512 count=1 брался МБР и прописывался в винде, как вариант загрузки :)
Из экзотики. Использовал dd для эмуляции дискового кэша. Необходимо было организовать резервное копирование некой базы данных на Oracle посредством стороннего пакета, который не умел открывать копируемые файлы в режиме конкурентного ввода-вывода. Но Oracle на JFS2 свои файлы в этом режиме как раз и открывал. Чтобы утилита резервного копирования могла эти файлы в принципе прочитать без гашения Oracle, файловые системы были подмонтированы с опцией -cio, что как раз и означало отключение кэширования данных при чтении. В результате утилита тихонько доила данные блоками по 128 килобайт (и это значение параметрами не менялось), а ось для каждого блока снимала с системы хранения свой блок, уже многомегабайтовый, и все это мимо кэша!

Понятно, что все работало, но ме-е-е-е-дленно!!! Размер базы был несколько терабайт. Родной оракловый rman проблем с производительностью понятно не имел, но использовать его настоятельно не рекомендовалось. Утилита резервного копирования была предписана корпоративным стандартом. В компании был не только Oracle, но и много всего интересного. Эта неназываемая утилита за много зеленых денег имела агенты для всего. Персонал на местах был обучен работать с нею. В общем вилы :)

Вот тут-то на сцену и вышел dd!!! Настроили агент резервного копирования, чтобы он файлы прогонял через

dd bs=<размер блока системы хранения> if=$

Профит!!!
А что за утилита для резервного копирования, если не секрет? Tivoli, Veritas или что-то ещё?
А мы через pipe-файл прогоняли — так удобнее и шустрее
я на макбуке чтоб не городить отдельный свап-раздел для Linux делал
dd if=/dev/zero of=/swap bs=1024 count=1048576
mkswap /swap
swapon /swap
chmod 600 /swap
Было бы неплохо в статье расшифровать названия параметров (if = input file, of = output file). А то без понимания этого их можно легко перепутать и устроить катастрофу.
Не упомянута ещё одна полезная особенность — возможность создания так называемого sparse-файла. Это файл, который создаётся с заданным размером, но при этом физически не занимает пространтсво на винчестере, пока в него не будут записаны данные.
Плюс этого в том, что файл любого размера создаётся мгновенно. Пример:
dd if=/dev/null of=bigfile bs=1M seek=1024
Эта команда мгновенно создаст файл размером в 1GiB.
Не совсем так. Без параметра count команда будет работать, пока не закончится место на диске. Но ход мыслей верный, вместо используемой в статье команды:
dd if=/dev/zero of=image.crypted bs=1M count=1000
можно выполнить такую:
dd if=/dev/zero of=image.crypted bs=1M count=0 seek=1000
Неа :) Там читерство в качестве input file не /dev/zero, а /dev/null
А, ну тогда да… Файл /dev/null сразу «закончится».
Отличная статья! Как раз то что я недопонимал в dd ) простым понятным языком )
UFO landed and left these words here
Native unix утилиты вообще рулят. Статья хорошая, но было бы интересней, если было бы больше экзотики (я про нестандартные подходы и решения с помощью dd, но безусловно автор молодец и одним ХОРОШИМ введением стало больше). А так, плюс. Не зря на первых страницах Эви Нэмит упоминает dd и отсылает читателя к man dd.
head -c делает то же самое, что и dd, только изначально с нормальным размером блока и по unix-way'но поддерживает stdin/stdout.

DD — замшелое дерьмо мамонта с неunix-way-ными аргументами.
UFO landed and left these words here
seek и skip нужны очень редко.
Для восстановления данных с плохих дисков лучше юзать dd-rescue или аналогичное, а не голый dd.
Зашел только что на википедию и увидел такой текст:

Распаковать ISO-образ «image.iso» в папку «/home/root/exISO»:
dd if=image.iso of=/home/root/exISO/

Я чего-то не понимаю, или это ошибка?
Чтобы распаковывать образы, dd должна иметь представление о файловых системах (в данном случае CDFS), но это совсем не входит в её компетенцию. Вероятно, совет принципиально неверный.
$ dd if=image.iso of=image/
dd: открытие `image/': Это каталог

Всё-таки там ошибка.
Да, интересно почитать, спасибо.
Спасибо за статью! добавил в меморайз.

Кстати, с помощью dd можно даже проверку на бэды орагнизовать. Но лучше использовать другие утилиты — например, dd_rescue
Ещё очень важный хинт:
когда идёт копирование большого объёма данных, бывает очень интересно «а сколько же там осталось?»
Для этого нам поможет команда kill -USR1 , где PID — ID процесса DD, в окне с dd получим текущий прогресс.
На случай если это прочитает кто то еще отмечу — в FreeBSD нужно использовать pkill -INFO dd в соседнем терминале или Ctrl+T в том терминале в котором работает dd.

Я этим pkill -USR1 dd закрыл на половине процесса копирование трёхтерабайтного винта.
Для dd можно сделать progres bar утилитой pv

dd if=/dev/zero |pv|dd of=/dev/null

Оказывается в OS X и FreeBSD если нажать при запущенным dd ctrl+t то он пошлет SIGINFO и будет показывать прогресс бар.
У GNU dd некоторое время назад для этого появился специальный ключик status=progress
Как сделать так, чтобы результат mknod или losetup сохранялся после перезагрузки системы, т.е. чтобы в /dev/ всегда висело наше устройство, ассоциированное с нашим образом
в случаи использования файла в качестве контейнера для файловой системы:
dd if=/dev/zero of=/test/somefile bs=100 count=1M
mkfs.ext4 /test/somefile
нужно ли создавать таблицу разделов внутри контейнера?
да, так будет работать, но — создавать или не создавать вот в чем вопрос?

Sign up to leave a comment.

Articles