Комментарии 119
Вот бы маны были так написаны…
люто, бешено плюсую.
Маны созданы для другого, хотя разделы EXAMPLE было бы неплохо делать поприличнее. Некоторые программы имеют шикарные маны, а у некоторых они вовсе отсутствуют.
Данная статья определенно хорошо описала dd со многих сторон. Хотя я бы побольше внимания уделил использованию dd совместно с pipeline.
И тем не менее — спасибо автору.
Данная статья определенно хорошо описала dd со многих сторон. Хотя я бы побольше внимания уделил использованию dd совместно с pipeline.
И тем не менее — спасибо автору.
Я понимаю. Но очень часто мне нужно какой-то флаг быстренько, смысл помню, а синтаксис — нет. А приходится листать целую простыню. Хотя цепкость английских слов глазами у меня неплохая, но делать так часто бывает лень и я просто гуглю (извините меня).
И чем больше таких статей — там больше простые смертные узнают о прелести таких мелких, но мощный утилит. Спасибо автору ещё раз.
И чем больше таких статей — там больше простые смертные узнают о прелести таких мелких, но мощный утилит. Спасибо автору ещё раз.
Тут еще подробнее с примерами.
В отсутсвии примеров основная проблема, ещё неплохо бы стандартизировать "--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 запрещает обрезать файл после выполнения операции.
dd if=/dev/zero of=new_file bs=x count=y
dd if=old_file of=new_file bs=x count=y notrail
Т.е. создаем файл-болванку нужного размера, затем начало заменяем своими даными. Параметр notrail запрещает обрезать файл после выполнения операции.
Написано отлично! Супер!
+ есть еще одно важное применение dd
$ dd if=/dev/random count=1 > secret.key
хотя я предпочитаю
$ head -c 512 > secret.key
$ dd if=/dev/random count=1 > secret.key
хотя я предпочитаю
$ head -c 512 > secret.key
Ещё dd можно забивать нулями и рандомами диски перед продажей или утилизацией, пару раз прогнал, удалил, форматнул и информацию уже не восстановить)
ещё удобный способ гонять через сеть образы оптимальным образом:
принимающая:
nc -l 1234 | dd of=/tmp/image.img bs=4096
отдающая:
dd if=/dev/sda bs=4096 | nc 1.2.3.4 1234
В отличии от ssh получается более эффективное использование сети.
принимающая:
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 же работает не переставая, к тому же обеспечивает уровень шифрования и предоставляет возможность указать конечную точку прямо с передающей стороны.
Да, можно и так, не только сети будет легче, еще и процу, спасибо за комментарий. Просто ssh во первых обеспечит шифрование, во вторых — легче автоматизировать.
Да и безопасность ниже, если интерфейс не изолирован: какое нибудь чудо присосется к порту, на котором слушает nc, и тапки: может залить столько, сколько на винт вместится.
Да и безопасность ниже, если интерфейс не изолирован: какое нибудь чудо присосется к порту, на котором слушает nc, и тапки: может залить столько, сколько на винт вместится.
ssh -c arcfour
Мне кажется можно и проще. По крайней мере с просто файликом прокатило
out:
in:
out:
nc localhost 12345 < /any/filein:
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
Это даже более положительно влияет на пропускную способность сети.
sudo dd if=/dev/SYS/root bs=6M | pigz -c | `ssh host «cat > ~/root.img.gz»
8-ядерная машинка с raid 10 отдает данные диска в темпе 140 — 180 Мб/c
А еще dd может отображать, сколько данных уже прочитано/записано, для этого нужно отправить процессу сигнал USR1.
Использовал dd для создания загрузочной флешки. Спасибо за статью, самое место ей в избранном.
Спасибо за статью! Однозначно в избранное.
Сегодня завесил комп коммандой (оперативки свободной не было):
dd if=/dev/null of=~/null bs=1024M count=10поднастройте ulimit, чтобы такого не возникало впринципе ;)
lopsa.org/node/1755
lopsa.org/node/1755
веселее так:
dd if=/dev/zero of=/dev/null
dd if=/dev/zero of=/dev/null
Спасибо! Буду вникать. А то пробовал когда-то переехать с одного веника на другой с помощью dd. Так и не разобрался с параметрами и в итоге у меня остаток свободного места на новом винте забивался нулями. Я тогда обошелся cp с кучей параметров, чтобы сохранились права доступа и симлинки.
для этого лучше использовать dump/restore
Для этого есть cp -a.
dd тоже не плохо работает.
Только сначала создать новый диск, потом при помощи dd перенести старый, потом resize2fs или аналогичное по вкусу.
Или gparted в качестве оболочки над этих хозяйством воспользоваться.
Кстати, если использовать lvm, то переезжать между дисками сильно проще, даже перезагружаться не надо.
Только сначала создать новый диск, потом при помощи dd перенести старый, потом resize2fs или аналогичное по вкусу.
Или gparted в качестве оболочки над этих хозяйством воспользоваться.
Кстати, если использовать lvm, то переезжать между дисками сильно проще, даже перезагружаться не надо.
Я тогда обошелся cp с кучей параметров, чтобы сохранились права доступа и симлинки
rsync не лучше ли примитивного cp?
Clonezilla на такие случаи есть.
Чтобы на носителе ничего нельзя было восстановить — можно забить его нулями
это не совсем верно — после нулей данные все равно восстановимы на специальных стендах, хотя это и сильно усложняет работу барахольщикам. лучше использовать urandom как источник :)
Согласен. Я слишком громко сказал «ничего нельзя было восстановить». В этом случае я имел ввиду спец. софт, которые народ качает с торрентов.
Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 1994 год, за 17 лет, уверен, многое изменилось.
Читал давно, написал по памяти, может где-то неточность допустил, но в книгу лезть уже нет сил…
Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 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). Поэтому между дорожками остаются остатки от предыдущих циклов записи. Для нормальной работы жесткого диска это не имеет значения, так как у современных винчестеров ширина головки считывания меньше ширины головки записи. Однако по магнитному рельефу поверхности, полученному с помощью магнитно-силового микроскопа можно восстановить уничтоженные данные, в том числе и если на место уничтожаемых данных записана новая (несекретная или просто случайная) информация. Поэтому для гарантированного уничтожения секретных данных используются специальные устройства.
Ссылки там и тут
Но цена вопроса должна быть космической ИМХО.
Вот-вот, именно цена вопроса. О реальных случаях использования МСМ кто-то слышал?
Зеленоград занимался. Вот их патент (публикация 2002г) Но название сайта www.nanoworld.org (Российское общество сканирующей зондовой микроскопии и нанотехнологии) каг-бэ намекает.
после нулей данные все равно восстановимы на специальных стендах
Хоть один пруф покажете? Или «слышал звон»?
А как быть с директориями? Монтировать как устройство? Есть пути проще?
Я как-то снимал образ с ноута перед установкой на него Убунты. Раздел с виндой и данными был 150 Гб, я перегонял его на десктоп через dd | gzip | nc, для чего загрузился с LiveCD. Предварительно я прошелся sdelete -z (занулил свободное место), в итоге получился архив 16 Гб.
Это был первый опыт реального использования и dd и nc, и я очень боялся где-то ошибиться и все испортить; но других средств под рукой не было. В результате все получилось, и я проникся крутостью Unix-way неимоверно. :)
Через некоторое время мне понадобилась пара небольших файликов из этого образа. Я стал думать, как бы их так вытащить, не разворачивая его целиком на физический носитель. Так ничего и не придумал.
Это был первый опыт реального использования и dd и nc, и я очень боялся где-то ошибиться и все испортить; но других средств под рукой не было. В результате все получилось, и я проникся крутостью Unix-way неимоверно. :)
Через некоторое время мне понадобилась пара небольших файликов из этого образа. Я стал думать, как бы их так вытащить, не разворачивая его целиком на физический носитель. Так ничего и не придумал.
В Вашем случае помог бы squashfs. Как минимум — добрались бы прозрачно до несжатого образа, а там уже можно fdisk-ом посмотреть расположение разделов и смонтировать раздел через loopback.
Как помог бы? Там был один раздел и на нем NTFS. Проблема в том (как я потом осознал), что к пожатому gzip-ом разделу произвольный доступ не возможен, только последовательный.
как бы их так вытащить, не разворачивая его целиком на физический носитель
kpartx: a tool for mounting partitions within an image file
Mounting Disk Images: Linux
Оно, конечно, не dd, и общего, если только, название, но мне как-то очень помогло — ddrescue
Да, штука удобная, с её помощью выцеплял файлы с битого винта. Один минус — не может рекурсивно файлы копировать, для этой цели я простой скрипт написал, может, пригодится кому.
Другой вариант — использовать find, при необходимости создавая подкаталоги перед попыткой копирования файла, если их ещё нет.
Другой вариант — использовать find, при необходимости создавая подкаталоги перед попыткой копирования файла, если их ещё нет.
Это немного другое, я имел в виду — www.gnu.org/software/ddrescue/ddrescue.html
Я знаю, что есть GNUшная ddrescue и dd_rescue, но отличия у них минимальные, нет?
Можете добавить:
dd часто используется для создания «self-extracted» архивов и инсталяторов на Unix платформах. Чтоб не быть голословным упомяну хотя бы один из фреймворков, который точно так делает — InstallAnyware.
Идея там такая — инсталятор представляет собой sh скрипт, к которому паровозом пприкреплен бинарники собственно инсталятора и прочие необходимые артифакты (например JRE). Скрипт по прописанному в нём смещению отрезает куски с помощью как раз-таки команды dd, а потом запускает инсталятор.
dd часто используется для создания «self-extracted» архивов и инсталяторов на Unix платформах. Чтоб не быть голословным упомяну хотя бы один из фреймворков, который точно так делает — InstallAnyware.
Идея там такая — инсталятор представляет собой sh скрипт, к которому паровозом пприкреплен бинарники собственно инсталятора и прочие необходимые артифакты (например JRE). Скрипт по прописанному в нём смещению отрезает куски с помощью как раз-таки команды dd, а потом запускает инсталятор.
SFX архивы обычно представляют собой шелл-скрипт с приклеенным в конце сжатым tar архивом, извлекается это обычно путём общепления хвоста в отдельный файл, но не припомню, чтобы для этого использовался dd, скорее head/tail
В InstallAnyware точно используется dd. Просто у них файл нужно нарезать на несколько кусков.
куски объединяются элементарно cat'ом, а делятся — split'ом
dd работает побайтово, а не побитово
познакомился с 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!!! Настроили агент резервного копирования, чтобы он файлы прогонял через
Профит!!!
Понятно, что все работало, но ме-е-е-е-дленно!!! Размер базы был несколько терабайт. Родной оракловый rman проблем с производительностью понятно не имел, но использовать его настоятельно не рекомендовалось. Утилита резервного копирования была предписана корпоративным стандартом. В компании был не только Oracle, но и много всего интересного. Эта неназываемая утилита за много зеленых денег имела агенты для всего. Персонал на местах был обучен работать с нею. В общем вилы :)
Вот тут-то на сцену и вышел dd!!! Настроили агент резервного копирования, чтобы он файлы прогонял через
dd bs=<размер блока системы хранения> if=$Профит!!!
я на макбуке чтоб не городить отдельный свап-раздел для Linux делал
dd if=/dev/zero of=/swap bs=1024 count=1048576
mkswap /swap
swapon /swap
chmod 600 /swap
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.
Плюс этого в том, что файл любого размера создаётся мгновенно. Пример:
dd if=/dev/null of=bigfile bs=1M seek=1024
Эта команда мгновенно создаст файл размером в 1GiB.
Отличная статья! Как раз то что я недопонимал в dd ) простым понятным языком )
НЛО прилетело и опубликовало эту надпись здесь
Native unix утилиты вообще рулят. Статья хорошая, но было бы интересней, если было бы больше экзотики (я про нестандартные подходы и решения с помощью dd, но безусловно автор молодец и одним ХОРОШИМ введением стало больше). А так, плюс. Не зря на первых страницах Эви Нэмит упоминает dd и отсылает читателя к man dd.
head -c делает то же самое, что и dd, только изначально с нормальным размером блока и по unix-way'но поддерживает stdin/stdout.
DD — замшелое дерьмо мамонта с неunix-way-ными аргументами.
DD — замшелое дерьмо мамонта с неunix-way-ными аргументами.
Зашел только что на википедию и увидел такой текст:
Распаковать ISO-образ «image.iso» в папку «/home/root/exISO»:
dd if=image.iso of=/home/root/exISO/
Я чего-то не понимаю, или это ошибка?
Распаковать ISO-образ «image.iso» в папку «/home/root/exISO»:
dd if=image.iso of=/home/root/exISO/
Я чего-то не понимаю, или это ошибка?
Думаю тут к месту будет ссылка на хорошую подробную статью по dd dd: Команда, которая не похожа на другие
Спасибо за статью! добавил в меморайз.
Кстати, с помощью dd можно даже проверку на бэды орагнизовать. Но лучше использовать другие утилиты — например, dd_rescue
Кстати, с помощью dd можно даже проверку на бэды орагнизовать. Но лучше использовать другие утилиты — например, dd_rescue
И ни слова про отличия GNU dd и BSD dd.
Ещё очень важный хинт:
когда идёт копирование большого объёма данных, бывает очень интересно «а сколько же там осталось?»
Для этого нам поможет команда kill -USR1 , где PID — ID процесса DD, в окне с dd получим текущий прогресс.
когда идёт копирование большого объёма данных, бывает очень интересно «а сколько же там осталось?»
Для этого нам поможет команда kill -USR1 , где PID — ID процесса DD, в окне с dd получим текущий прогресс.
Спасибо, полезная шпаргалка.
Для dd можно сделать progres bar утилитой pv
dd if=/dev/zero |pv|dd of=/dev/null
dd if=/dev/zero |pv|dd of=/dev/null
Как сделать так, чтобы результат mknod или losetup сохранялся после перезагрузки системы, т.е. чтобы в /dev/ всегда висело наше устройство, ассоциированное с нашим образом
в случаи использования файла в качестве контейнера для файловой системы:
да, так будет работать, но — создавать или не создавать вот в чем вопрос?
dd if=/dev/zero of=/test/somefile bs=100 count=1Mнужно ли создавать таблицу разделов внутри контейнера?
mkfs.ext4 /test/somefile
да, так будет работать, но — создавать или не создавать вот в чем вопрос?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Команда dd и все, что с ней связано