Infrastructure engineer
0,0
рейтинг
11 апреля 2011 в 23:11

Администрирование → Команда dd и все, что с ней связано

*nix*

В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.

Начну с небольшого примера, наглядно иллюстрирующего основные параметры команды:

# dd if=/dev/urandom of=/dev/null bs=100M count=5

Параметры:
  • if: указывает на источник, т.е. на то, откуда копируем. Указывается файл, который может быть как обычным файлом, так и файлом устройства.
  • of: указывает на файл назначения. То же самое, писать можем как в обычный файл, так и напрямую в устройство.
  • bs: количество байт, которые будут записаны за раз. Можно представлять этот аргумент как размер куска данные, которые будут записаны или прочитаны, а количество кусков регулируется уже следующим параметром.
  • count: как раз то число, которое указывает: сколько кусочков будет скопировано.

Таким образом, описанная команда читает 5*100 мегабайт из устройства /dev/urandom в устройство /dev/null. Придавая этой команде смысловую нагрузку получается, что система сгенерирует 500 мегабайт случайных значений и запишет их в null устройство. Конечно, единственное, что сделает эта команда: нагрузит процессор на несколько секунд. Рассмотрим примеры из практики:

Создание образа диска:

# dd if=/dev/cdrom of=image.iso

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

# dd if=/dev/cdrom of=image.iso conv=noerror

Параметр «conv» позволяет подключать несколько фильтров, применимых к потоку данных. Фильтр «noerror» как раз отключает остановку работы программы, когда наткнется на ошибку чтения. Таким образом, некоторые данные с диска все же можно будет прочитать. Точно таким образом я спас данные со своей флешки Corsair, которую погнули: подобрал подходящее положение, когда контакт есть, и сделал дамп файловой системы.
Подключить, кстати, такие образы можно при помощи команды mount с ключем "-o loop":

# mount -o loop image.iso /mnt/image

Если что-то не получается, процесс разбивается на 2 уровня:

# losetup -e /dev/loop0 image.iso
# mount /dev/loop0 /mnt/image


Если и так не работает, значит файловая система образа полетела.

Работа с носителями информации

Очень простое, хоть и не оптимальное решение клонирования жесткого диска:

# dd if=/dev/sda of=/dev/sdb bs=4096

Все то же побайтовой копирование с размером буфера 4 Кб. Минус способа в том, что при любой заполненности разделов копироваться будут все биты, что не выгодно при копировании разделов с маленькой заполненностью. Чтобы уменьшить время копирования при манипуляции с большими объемами данных, можно просто перенести MBR на новый носитель (я ниже опишу как), перечитать таблицу разделов ядра (при помощи того же fdisk), создать файловые системы и просто скопировать файлы (не забыв сохранить права доступа к файлам).

Как вариант, можно даже по расписанию делать бекап раздела по сети. Разрулив ключи ssh будет работать такая схема:

# dd if=/dev/DEVICE | ssh user@host «dd of=/home/user/DEVICE.img».

Когда-то читал исследование, согласно которому очень большая доля жестких дисков на барахолке подвергается восстановлению данных без привлечения чего-то специализированного, и содержит конфиденциальную информацию. Чтобы на носителе ничего нельзя было восстановить — можно забить его нулями:

# dd if=/dev/zero of=/dev/DEVICE

Думаю, понятно на что нужно заменить DEVICE. После проведения лекций по Linux, я очень тщательно стал следить за тем, что пишу.
Проверить можно тем же dd, но преобразовав данные в hex:

# dd if=/dev/sda | hexdump -C

Должны посыпаться нули.

Операции с MBR

MBR расположена в первых 512 байтах жесткого диска, и состоит из таблицы разделов, загрузчика и пары доп. байт. Иногда, ее приходится бекапить, восстанавливать и т.д. Бекап выполняется так:

# dd if=/dev/sda of=mbr.img bs=512 count=1

Восстановить можно проще:

# dd if=mbr.img of=/dev/sda

Причины этих махинаций с MBR могут быть разные, однако хочу рассказать одну особенность, взятую из опыта: после восстановления давней копии MBR, где один из разделов был ext3, а позже стал FAT и использовался Windows, раздел перестал видиться виндой. Причина — ID раздела, который хранится в MBR. Если UNIX монтирует файловые системы согласно суперблоку, то винды ориентируются на ID разделов из MBR. Поэтому всегда нужно проверять ID разделов при помощи fdisk, особенно если на компьютере есть винды.

Генерация файлов

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

# dd if=/dev/zero of=image.crypted bs=1M count=1000

Создался файл размером почти в гигабайт. Теперь нужно сделать этот файл блочным устройством и, при этом, пропустить его через механизм шифрования ядра linux. Я выберу алгоритм blowfish. Подгрузка модулей:

# modprobe cryptoloop
# modprobe blowfish


Ассоциация образа с блочным устройством со включенным шифрованием:

# losetup -e blowfish /dev/loop0 image.crypted

Команда запросит ввести пароль, который и будет ключем к образу. Если ключ введен не правильно, система не смонтируется. Можно будет заново создать данные в образе, используя новый ключ, но к старым данным доступа не будет.
Создаем файловую систему и монтируем:

# mkfs.ext2 /dev/loop0
# mount /dev/loop0 /mnt/image


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

# umount /dev/loop0
# losetup -d /dev/loop0


Теперь шифрованный образ готов.

Основные идеи я расписал, однако множество задач, которые можно решить при помощи маленькой программки, имя которой состоит из двух букв, намного шире. Программа «dd» — яркий пример того, что IT'шники называют «UNIX way»: одна программа — часть механизма, выполняет исключительно свою задачу, и выполняет ее хорошо. В руках человека, который знает свое дело, которому свойственен не стандартный подход к решению задачи, такие маленькие программки помогут быстро и эффективно решать комплексные задачи, которые, на первый взгляд, должны решать крупные специализированные пакеты.
Дмитрий Щербаков @Vorb
карма
132,2
рейтинг 0,0
Infrastructure engineer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (118)

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

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

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

        И чем больше таких статей — там больше простые смертные узнают о прелести таких мелких, но мощный утилит. Спасибо автору ещё раз.
        • –7
          приходиться*
        • +1
          Если я забываю какой-то флаг, но помню про что он, то я делаю что-то типа
          man blabla |grep -i -C 2 «ключевое слово нужного флага»
          • +3
            В мане есть встроенный поиск: /blabla для поиска «blabla», а следующее совпадение — N.
            • +3
              Странно, у меня N — предыдущее совпадение. Следующее совпадение — n.
              • +1
                Извиняюсь, не знал что с шифтом обратно ищет. Имел ввиду просто клавишу )
            • 0
              Это не в man а в less. Поставите другой PAGER будут другие шорткаты.
      • 0
        Тут еще подробнее с примерами.
      • 0
        В отсутсвии примеров основная проблема, ещё неплохо бы стандартизировать "--usage", а то у одной программы он выводит понятную справку, у другой — бессмысленный набор аргументов «abcdeXYZ», у третьей его вообще нет.
    • +4
      в официальном man'е не хватает разве что real life примеров, а все опции описаны достаточно внятно
  • +5
    Очередную Вашу статью добавил в избранное. На днях как раз требовалось создать образ диска.
  • +9
    Применив фантазию, с 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 запрещает обрезать файл после выполнения операции.
    • 0
      А параметр seek задать не проще? Смысл 2 файла держать-то?
      • 0
        Не всегда проще. Например, в автоматических сборках, когда оригинальный файл тоже нужно для чего-то оставить.
    • 0
      Еще dd'ом удобно вырезать части файла:

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

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

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

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

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

      8-ядерная машинка с raid 10 отдает данные диска в темпе 140 — 180 Мб/c
      • 0
        прикольно, жаль pigz нет по дефолту во многих дистрибах. с таким же успехом (если ресурсов много) можно так делать:
        • 0
          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
  • +9
    А еще dd может отображать, сколько данных уже прочитано/записано, для этого нужно отправить процессу сигнал USR1.
  • +2
    Использовал dd для создания загрузочной флешки. Спасибо за статью, самое место ей в избранном.
  • +1
    Спасибо за статью! Однозначно в избранное.
  • 0
    Сегодня завесил комп коммандой (оперативки свободной не было):
    dd if=/dev/null of=~/null bs=1024M count=10
    • +3
      поднастройте ulimit, чтобы такого не возникало впринципе ;)
      lopsa.org/node/1755
    • +2
      веселее так:
      dd if=/dev/zero of=/dev/null
  • 0
    Спасибо! Буду вникать. А то пробовал когда-то переехать с одного веника на другой с помощью dd. Так и не разобрался с параметрами и в итоге у меня остаток свободного места на новом винте забивался нулями. Я тогда обошелся cp с кучей параметров, чтобы сохранились права доступа и симлинки.
    • 0
      для этого лучше использовать dump/restore
    • 0
      Для этого есть cp -a.
      • 0
        dd тоже не плохо работает.
        Только сначала создать новый диск, потом при помощи dd перенести старый, потом resize2fs или аналогичное по вкусу.

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

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

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

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

    это не совсем верно — после нулей данные все равно восстановимы на специальных стендах, хотя это и сильно усложняет работу барахольщикам. лучше использовать urandom как источник :)
    • +1
      Согласен. Я слишком громко сказал «ничего нельзя было восстановить». В этом случае я имел ввиду спец. софт, которые народ качает с торрентов.
      Если говорить более серьезно, то даже Б. Шнайер в своей книге упоминал об этом. Он говорил о том, что данные на диске нужно перезаписывать несколько раз: единицами, нулями, затем случайными данными, сгенерированные криптографически стойким алгоритмом. И то он там же пишет о том, что с использованием каких-то микроскопов даже этот метод окажется не эффективным. Книга за 1994 год, за 17 лет, уверен, многое изменилось.
      Читал давно, написал по памяти, может где-то неточность допустил, но в книгу лезть уже нет сил…
      • 0
        Это похоже на давно поддерживаемый специалистами миф. Некоторые исследователи что-то там писали про восстановление битов с затёртой нулями области диска при помощи электронного микроскопа, но не припомню, чтобы при этом достигли хоть сколько-нибудь существенных результатов, и уж тем более, чтобы эти результаты могли быть применимы к большинству моделей дисков.
        • +1
          Это тот самый миф о остаточной намагниченности? Читал теория, впринципе она имеет право на существоване, но что-то никак не найду отчёта о реальном применении. Очень хотелось бы увидеть такой стенд))
          • 0
            Стирать проще, а далее нет предела фантазии — от молотка до фугасов)
            Алгоритм Содержание алгоритма Примечания
            Руководство по защите информации МО США (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). Поэтому между дорожками остаются остатки от предыдущих циклов записи. Для нормальной работы жесткого диска это не имеет значения, так как у современных винчестеров ширина головки считывания меньше ширины головки записи. Однако по магнитному рельефу поверхности, полученному с помощью магнитно-силового микроскопа можно восстановить уничтоженные данные, в том числе и если на место уничтожаемых данных записана новая (несекретная или просто случайная) информация. Поэтому для гарантированного уничтожения секретных данных используются специальные устройства.

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

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

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

    Через некоторое время мне понадобилась пара небольших файликов из этого образа. Я стал думать, как бы их так вытащить, не разворачивая его целиком на физический носитель. Так ничего и не придумал.
    • 0
      В Вашем случае помог бы squashfs. Как минимум — добрались бы прозрачно до несжатого образа, а там уже можно fdisk-ом посмотреть расположение разделов и смонтировать раздел через loopback.
      • 0
        Как помог бы? Там был один раздел и на нем NTFS. Проблема в том (как я потом осознал), что к пожатому gzip-ом разделу произвольный доступ не возможен, только последовательный.
        • 0
          Я предлагал использовать squashfs вместо gzip. Тогда можно было бы его смонтировать и получить нормальный доступ к несжатому образу. В том числе и с произвольным доступом.
          • 0
            Хорошо, а как это можно сделать? Так чтобы «на лету». А то свободных 150 Гб нет, на другой машине XP (нормальный порт nc пришлось поискать).
            • 0
              Увы, не знаю.
    • +1
      как бы их так вытащить, не разворачивая его целиком на физический носитель

      kpartx: a tool for mounting partitions within an image file
      Mounting Disk Images: Linux
      • 0
        Спасибо. Но вы наверное не заметили, что образ сжатый.
        • 0
          Да, не заметил. :)
          Это непаханное поле, похоже. Весьма пригодился бы некий модуль ядра для работы со сжатыми образами.
  • +1
    Оно, конечно, не dd, и общего, если только, название, но мне как-то очень помогло — ddrescue
    • +1
      Да, штука удобная, с её помощью выцеплял файлы с битого винта. Один минус — не может рекурсивно файлы копировать, для этой цели я простой скрипт написал, может, пригодится кому.
      Другой вариант — использовать find, при необходимости создавая подкаталоги перед попыткой копирования файла, если их ещё нет.
  • +1
    Можете добавить:
    dd часто используется для создания «self-extracted» архивов и инсталяторов на Unix платформах. Чтоб не быть голословным упомяну хотя бы один из фреймворков, который точно так делает — InstallAnyware.
    Идея там такая — инсталятор представляет собой sh скрипт, к которому паровозом пприкреплен бинарники собственно инсталятора и прочие необходимые артифакты (например JRE). Скрипт по прописанному в нём смещению отрезает куски с помощью как раз-таки команды dd, а потом запускает инсталятор.
    • 0
      SFX архивы обычно представляют собой шелл-скрипт с приклеенным в конце сжатым tar архивом, извлекается это обычно путём общепления хвоста в отдельный файл, но не припомню, чтобы для этого использовался dd, скорее head/tail
      • 0
        В InstallAnyware точно используется dd. Просто у них файл нужно нарезать на несколько кусков.
        • 0
          куски объединяются элементарно cat'ом, а делятся — split'ом
          • 0
            Ну не я эти скрипты писал. Насколько я помню, они достают из середины JRE и распаковывают его в темп. Потом достают инсталятор и запускают егос этим JRE.
            Я не утверждаю, что это нельзя сделать иначе, это просто ещё один пример использования dd. Где-то ещё я видел подобное.
            • 0
              слабо представляю, что можно достать из «середины JRE» ;-)
              • 0
                Из середины файла достаётся JRE, а не из середины JRE.
  • +6
    dd работает побайтово, а не побитово
  • 0
    познакомился с dd когда лет 10-15ть назад на школьный комп, параллельно с виндой 98 воткнул линукс, и оставил виндовый загрузчик живым и невредимым. как раз через dd if=/dev/sda of=loader.bin bs=512 count=1 брался МБР и прописывался в винде, как вариант загрузки :)
  • 0
    Из экзотики. Использовал dd для эмуляции дискового кэша. Необходимо было организовать резервное копирование некой базы данных на Oracle посредством стороннего пакета, который не умел открывать копируемые файлы в режиме конкурентного ввода-вывода. Но Oracle на JFS2 свои файлы в этом режиме как раз и открывал. Чтобы утилита резервного копирования могла эти файлы в принципе прочитать без гашения Oracle, файловые системы были подмонтированы с опцией -cio, что как раз и означало отключение кэширования данных при чтении. В результате утилита тихонько доила данные блоками по 128 килобайт (и это значение параметрами не менялось), а ось для каждого блока снимала с системы хранения свой блок, уже многомегабайтовый, и все это мимо кэша!

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

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

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

    Профит!!!
    • 0
      А что за утилита для резервного копирования, если не секрет? Tivoli, Veritas или что-то ещё?
    • 0
      А мы через pipe-файл прогоняли — так удобнее и шустрее
  • +2
    я на макбуке чтоб не городить отдельный свап-раздел для Linux делал
    dd if=/dev/zero of=/swap bs=1024 count=1048576
    mkswap /swap
    swapon /swap
    chmod 600 /swap
  • +4
    Было бы неплохо в статье расшифровать названия параметров (if = input file, of = output file). А то без понимания этого их можно легко перепутать и устроить катастрофу.
  • +3
    Не упомянута ещё одна полезная особенность — возможность создания так называемого sparse-файла. Это файл, который создаётся с заданным размером, но при этом физически не занимает пространтсво на винчестере, пока в него не будут записаны данные.
    Плюс этого в том, что файл любого размера создаётся мгновенно. Пример:
    dd if=/dev/null of=bigfile bs=1M seek=1024
    Эта команда мгновенно создаст файл размером в 1GiB.
    • 0
      Не совсем так. Без параметра 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
      • 0
        Неа :) Там читерство в качестве input file не /dev/zero, а /dev/null
        • 0
          А, ну тогда да… Файл /dev/null сразу «закончится».
  • 0
    Отличная статья! Как раз то что я недопонимал в dd ) простым понятным языком )
  • 0
    Вы не забыли добавить к conv=noerror параметр sync?
  • 0
    Native unix утилиты вообще рулят. Статья хорошая, но было бы интересней, если было бы больше экзотики (я про нестандартные подходы и решения с помощью dd, но безусловно автор молодец и одним ХОРОШИМ введением стало больше). А так, плюс. Не зря на первых страницах Эви Нэмит упоминает dd и отсылает читателя к man dd.
  • –3
    head -c делает то же самое, что и dd, только изначально с нормальным размером блока и по unix-way'но поддерживает stdin/stdout.

    DD — замшелое дерьмо мамонта с неunix-way-ными аргументами.
    • 0
      head -c — это, конечно, интересная идея. Только нет там seek, skip и проч. — равно как и bs, без которого грустно.
      • 0
        seek и skip нужны очень редко.
        Для восстановления данных с плохих дисков лучше юзать dd-rescue или аналогичное, а не голый dd.
  • 0
    Зашел только что на википедию и увидел такой текст:

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

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

      Всё-таки там ошибка.
  • +3
    Думаю тут к месту будет ссылка на хорошую подробную статью по dd dd: Команда, которая не похожа на другие
    • 0
      Да, интересно почитать, спасибо.
  • 0
    Спасибо за статью! добавил в меморайз.

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

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

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

    • 0
      Оказывается в OS X и FreeBSD если нажать при запущенным dd ctrl+t то он пошлет SIGINFO и будет показывать прогресс бар.
    • 0
      У GNU dd некоторое время назад для этого появился специальный ключик status=progress
  • 0
    Как сделать так, чтобы результат mknod или losetup сохранялся после перезагрузки системы, т.е. чтобы в /dev/ всегда висело наше устройство, ассоциированное с нашим образом

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.