Снова о бекапировании с помощью dd

Не-не, я не о них, с ними понятно. Вопрос в другом:

Первый dd можно заменить на pv,

Если понимать это выражение буквально, то pv никак не может заменить dd, это совершенно разные вещи.

второй [dd ]на cat,

то же самое и о них.

Может вы что хотели сказать что-то другое?

Напишите, плиз, полностью всю строку команды

полностью всю строку команды

pv /dev/sda1 | zstd --compress --threads=$(nproc) | ssh backup.mynet "cat > /opt/backup/sda1.img.zst"

бекапь разделы с r image drive да и усе

dd это отрыжка 60-х. Лучше его не использовать. По дефолту он тупо портит данные. Если решишься — прочитай man dd. Два раза. Лучше просто пиши gzip /dev/sda. Если нужен прогресс — pv.

Некоторые нубы думают, что dd делает что-то особое и тиражируют это миф. Он копирует файл ровно так же, как cat или cp. Но если read отдаёт не все байты (например в пайпе), то он их добивает нулями. Это бред собачий, но он так работает.

Вот те раз! Я только собрался наклепать бекапов со своих дисков (пока целиком, не отдельные разделы), надеясь, что все вопросы мы уладили, а тут такая подсечка... :-(

Legioner
При чем тут миф, причем тут портит?
dd - да, древнейшая примитивная утилита, выполняющая обычное чтение блоков диска.
Но ведь другого от нее никто и не требует!
И делает она это отлично. Поэтому что значит «портит»?
А если dd наткнется на битый блок, то начет по нему елозить, но это уже другая история, надо применять другие методы, но мы это здесь не рассматриваем..

Лучше просто пиши gzip /dev/sda. Если нужен прогресс — pv.

А можно всю строку целиком? Мне эти намеки не совсем понятны.


No

pv /dev/sda1 | zstd --compress --threads=$(nproc) | ssh backup.mynet "cat > /opt/backup/sda1.img.zst"

smilessss

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

Насколько я помню, это решается нестандартным флагом iflag=fullblock.

Обычно с обычными файлами ОС отдаёт запрошенный размер в read. Но есть ситуации, когда и это не соблюдается. А если это не обычный файл, а что-то вроде /dev/random или pipe, то там такое встретить очень реально. Лично у меня был скрипт вроде ssh host "dd if=/dev/sda" | dd of=/dev/sda, на котором это и проявилось. Благо dd хоть предупреждения в таких случаях печатает, по крайней мере та версия, что в центоси. После этого я внимательно прочитал man и теперь стараюсь просто избегать его, слишком много нелогичных вещей. Флаги вроде sync, уверен, что все, его использующие, думают, что он вызывает fsync, чтобы не терялись данные, а на самом деле этот флаг тупо нулями что-то там забивает или пробелами (лол).

Если dd читает неполный блок, то забивает его нулями.

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

Лично у меня был скрипт ... на котором это и проявилось.

Может, это версия dd была косячная?

Не понимаю... 100 лет пользовались dd, таких жалоб вроде не наблюдалось, и вдруг на тебе - открытие в 21 веке?

Ну допустим, если dd так плоха и непредсказуема, тогда что?

Ну и хорошо, есть какая-то определенность, и в случае чего видно, где кончается файл.

О чём ты? Файл кончается там, где он кончается. А нули могут в середине появиться.

А другие утилиты не забивают - значит, оставляют всякий мусор - ну и зачем на него любоваться?

А нормальные утилиты ничего не оставляют.

Может, это версия dd была косячная?

Она косячная by design. Любая.

Не понимаю… 100 лет пользовались dd, таких жалоб вроде не наблюдалось, и вдруг на тебе - открытие в 21 веке?

Умные люди давно уже всё открыли. Я потом почитал по этой теме.

Ну допустим, если dd так плоха и непредсказуема, тогда что?

Используй cp/cat/head/tail/прочие стандартные утилиты. Можно pv, если нужен прогресс. Ну или используй dd, но, как я уже сказал, прочитай ман пару раз от начала до конца, благо он не слишком большой и осознай, что его опции делают. Потому, что по умолчанию он настроен так, чтобы портить данные в нетривиальных случаях.

Ну и ну... Всю жизнь учись, а....

Используй cp/cat/head. Можно pv, если нужен прогресс.

А они что какие-то особенные, получают инфу с диска не через системный read, а лезут к диску напрямую, что ли?

Привет

Привет

Legioner всезнающий, так давайте продолжим обсуждение.
А то у меня все бекапы стали, жду ваших указаний.

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

Legioner
Увы, я не понимаю этот гиковский слэнг «юзерспейс», можно по-русски?

И если cp/cat/head работает также, как и dd через read или mmap, то чем они лучше, чем dd ?

И все эти рассуждения безусловно было интересно послушать, но это лишь теория.
А можете перейти от теории к практике и выложить конкретные примеры применения ваших надежных cp/cat/head для копирования дисков и отдельных разделов?
Сам я их нарисовать не сумею, а если даже что-то нарисую, то не буду уверен в их корректности.

Иначе эта теория так и останется теорией, а мне к сожалению придется по-прежнему пользоваться хоть и к ущербной, но зато понятной для понимания командой:

dd status=progress if=/dev/sda bs=64k | gzip -c | ssh chukcha@192.168.1.100 "dd of=sda.img.gzip bs=64k"

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

Ты в этом уверен? Прямо вот если сделать dd if=file, то при частичном чтении забьёт нулями?

Лично у меня был скрипт вроде ssh host "dd if=/dev/sda" | dd of=/dev/sda, на котором это и проявилось.

ssh ориентирован на обмен текстом, и при некоторых включенных параметрах может портить бинарные данные. Этот момент ты проверял?

i-rinat
Извиняюсь, что вклиниваюсь вашу дискуссию, но кмк, ssh тут лучше не рассматривать, поскольку это самостоятельная тема, и при бекапировании она не обязательно используется.

Например, «моя» строка при наличии двух жестких дисков может использоваться, например, как-то так, без ssh:

dd if=/dev/sda bs=64K | bzip2 sda.img.gz

dd if=/dev/sda  bs=64K | gzip -c > /mnt/sdb/sda.img.gz

Мдаа... Сначала обругали dd, потом изобразили НьюВасюки на cp/cat/head.
А когда задал уточняющие вопросы и попросил проверенные конкретные примеры на них, так сразу тишина в студии.

Ну и фиг с ними. Буду бекапировать на dd, там зато хоть все ясно.

Ты в этом уверен? Прямо вот если сделать dd if=file, то при частичном чтении забьёт нулями?

Я это наблюдал. Как воспроизвести - не знаю.

ssh ориентирован на обмен текстом, и при некоторых включенных параметрах может портить бинарные данные. Этот момент ты проверял?

dd писал предупреждения про partial read. С флагом fullblock предупреждений не было и контрольные суммы совпали.

Лучше попробуй zstd, уж вместо bzip2 точно.

Использовал ли ты conv=sync в том случае?

(кстати, gzip увы, однопоточный, так что лучше 7zip)

http://www.zlib.net/pigz/

Нет, сначала я не использовал никаких флагов, потом добавил iflag=fullblock

Основной цикл в dd состоит из чтения данных и записи данных. Если не добавлять никаких флагов в опцию преобразования данных (conv), то dd будет записывать ровно столько, сколько прочитал. Так что если при чтении 16384 байт ядро решило вернуть, скажем, 8192, то записано в of будет именно 8192 байт, а не 16384. Ядро гарантирует, что позиция во входном файле передвинется тоже на 8192 байта, поэтому следующее чтение ничего не пропустит.

Так что у тебя что-то не то с воспоминаниями. Возможно, ты добавлял в опции conv=sync. С ним как раз при частичном чтении и будет забивание остатка нулями.

i-rinat, Legioner

Мои знания по сравнении с вашими весьма скромны, тем не менее пришел в к такому же выводу, что и i-rinat -

Так что у тебя что-то не то с воспоминаниями.

Почему так думаю - потому что у Легионера есть одна очень сомнительная фраза.
Я ее сразу заметил но из скромности промолчал.
Вот она: когда я его спросил -

А другие утилиты не забивают - значит, оставляют всякий мусор - ну и зачем на него любоваться?

то Легионер ответил так:

А нормальные утилиты ничего не оставляют.

Давайте рассмотрим этот момент подробнее.

Допустим, dd натыкается на частично читаемый блок.
Исправную часть блока dd читает, а не читаемую, как описано в мане и также считает Легионер, заполняет нулями. И это по его мнению плохо.
А в случае использования cp, cat и пр. по его мнению они, как «нормальные утилиты», ничего не оставляют.

Но в таком случае придется признать, что выходной файл будет короче как раз на эту нечитаемую часть!

А это уже ни в какие ворота не лезет!!!

Потому что если читаемые блоки представляет собой plain текстовый файл, то пропадет кусок текста, с чем как-то можно примирится, остальной текст-то прочитался

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

И наоборот, в случае dd произойдет заполнение нечитаемого места нулями, но размер файла не изменится, что чрезвычайно важно для работоспособности бинарника.

Более того! Может даже так случайно получится, что нечитаемая область бинарника окажется тоже текстом (например, это его меню или хелп), то только они будут испорчены, а само приложение-бинарник будет работоcпособным! :-)

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

Так что считаю, что в этом Legioner, вы ошибаетесь с точностью до наоборот -

dd это отрыжка 60-х. Лучше его не использовать. По дефолту он тупо портит данные.
Лучше просто пиши gzip /dev/sda. Если нужен прогресс — pv.

Уффф... Извините за многословие, но короче не получилось.

Легионер, вы говорили, что в описываемых недостатках dd знающие люди уже давно уже знают.
Что это за люди, где об этом написано?
Пожалуйста, вещественные доказательства студию.

i-rinat, Legioner

Прошло 3 дня...

Ни возражений. ни доказательств, - ничего. Полная тишина в студии.
А молчание - знак согласия.

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

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

Затем что у меня были случаи неожиданной неработоспособности снятых образов.
После прочтения вот этого поста i-rinat мне стало понятно почему.
Для порчи образа достаточно хотя бы одного сбойного блока.

В нормальных операционных системах для бэкапа придуманы dump/restore.

Ни возражений. ни доказательств, - ничего. Полная тишина в студии.
А молчание - знак согласия.

А с чего им волноваться то, это ведь твои данные могут пропасть, а не их.