Дд делает какую-либо проверку?

16

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

На этот ответ Жиль говорит

Если [dd] успешно завершен, резервное копирование выполнено правильно, исключая аппаратную ошибку…

Что это означает? Есть ли ddкакая-то встроенная проверка?

Если бы вместо этого я использовал rsync, я также запускаю второй проход --checksum, чтобы проверить. Оправдана ли такая паранойя?

dd verification integrity

— Sparhawk
источник

Определите «целостность безопасна».

— Турбьёрн Равн Андерсен

@ ThorbjørnRavnAndersen Я имею в виду, что копия идентична оригиналу.

— Ястреб

Если у вас есть только плоские файлы, традиционным способом копирования файлов является использование tar или cpio. У GNU tar есть флаг проверки: gnu.org/software/tar/manual/html_section/tar_81.html . Эти дни rsync, вероятно, будут самыми простыми.

— Турбьерн Равн Андерсен

1

«Запрет аппаратного сбоя» означает, что он не выполняет никакой проверки. Если это так, он может обнаружить сбой оборудования.

— Бармар

20

ddили любое другое приложение не имеет «какой-то встроенной проверки» в том смысле, о котором вы, вероятно, думаете: оно не считывает данные с носителя данных для сравнения с тем, что было написано. Это работа операционной системы.

На самом деле невозможно выполнить проверку на чтение оборудования из приложения. Это будет работать в некоторых сценариях, но в большинстве случаев это ничего не даст. Приложение может прочитать то, что оно только что написало, если оно пишет непосредственно на носитель , но это, как правило, считывает обратно из кеша в памяти, что не даст никакой полезной уверенности. В этом примере вы процитировать , ddпишет в трубу, и в этом случае он не имеет никакого контроля над тем, что происходит с данными далее вниз по линии. В вашем примере rsync, второй проходrsync --checksum Это бессмысленно: теоретически это может привести к ошибке, но на практике, если ошибка действительно случится, то второй проход, вероятно, не сообщит ничего плохого, поэтому вы тратите усилия на то, что на самом деле не дает полезной уверенности.

Тем не менее, приложения действительно проверить , что происходит с данными, в том смысле , что они проверяют , что операционная система взяла на себя ответственность за данные. Все системные вызовы возвращают статус ошибки. Если системный вызов возвращает статус ошибки, приложение должно распространить эту ошибку пользователю, как правило, отображая сообщение об ошибке и возвращая ненулевой статус выхода.

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

В цепочке копирования данных могут возникнуть два вида ошибок.

Коррупция: немного переворачивается во время передачи. Невозможно проверить это на уровне приложения, потому что, если это произойдет, это происходит из-за программной ошибки или аппаратной ошибки, которая с большой вероятностью может вызвать такое же повреждение при чтении. Единственный полезный способ убедиться, что такого повреждения не произошло, - это физически отключить носитель и повторить попытку, желательно на другом компьютере, если проблема связана с ОЗУ.
Усечение: все скопированные данные были скопированы правильно, но некоторые данные не были скопированы вообще. Это один является проверка стоит иногда, в зависимости от сложности команды. Вам не нужно читать данные, чтобы сделать это: просто проверьте размер.

— Жиль "ТАК - прекрати быть злым"
источник

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

— садовник

2

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

— Джошуа

1

Спасибо за ответ (+1). Я, вероятно, должен упомянуть, что я использую довольно простой dd if=/dev/sdc of=/dev/sdb bs=4M, так что я понимаю, что проблемы игнорирования ошибок и скорости (более или менее, по сравнению с cat) спорны. Вы говорите, чтобы просто проверить размер путем монтажа тогда df?

— Sparhawk

4

Нет, ddне делает явной проверки. Если вы хотите / нуждаетесь в криминалистически проверенной копии вашего диска или любой его части, используйте dcflddулучшенную версию, ddразработанную Лабораторией компьютерной криминалистики Министерства обороны США.

— fpmurphy
источник

4

Единственный способ быть «уверенным» - это выполнить дополнительный этап чтения и сравнения (после удаления кэшей).

Кроме того, ddобнаруживает ошибки чтения и записи таким же образом, как и все другие программы ... это работает, если диски (и другие задействованные компоненты) сообщают об ошибках; для дисков, которые принимают данные без вывода сообщений без их записи, вам не повезло.

Оправдана ли такая паранойя?

Если вы не можете доверять своему оборудованию, чтобы быть надежным, все становится сложнее

— frostschutz
источник

Это сложнее , как в отношении чтения и сравнения, так и в отношении ddобнаружения ошибок.

— Жиль "ТАК - перестань быть злым"

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

— frostschutz

Эти проблемы коррупции могут оправдать проверку данных, полученных с использованием dd. Реальное решение состоит в том, чтобы использовать что-либо, кроме того, что ddтихое повреждение данных является специальностью dd.

— Жиль "ТАК - перестань быть злым"

2

@ Жиль, или просто не говорите ddигнорировать ошибки. Вы не можете точно обвинить программу в том, что она сделала именно то, что вы просили.

— Mark

@ Mark А как, молись, тебе сказать, чтобы ddне игнорировать ошибки? И нет, conv=noerrorэто не правильный ответ. Смотрите ответ frostschutz для примера. Я сделать винить дизайн ddдля изготовления , игнорируя ошибки режима по умолчанию, и один , который не может быть выключен , не зная его внутреннюю механику очень точно.

— Жиль "ТАК - перестань быть злым"

2

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

Обычно я использую хэш md5 или sha1 для проверки целостности данных, перечитывая источник и место назначения, например:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

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

— Ярослав Войтович
источник

Достаточно размонтировать / смонтировать файловую систему, чтобы заставить операционную систему записывать кэш файловой системы на устройство.

— miracle173

miracle173, но даже после синхронизации ОС не сохраняет в кэше то, что написала? так что я не уверен, что размонтирование очистит весь кэш от оперативной памяти.

— Мэтт

1

От man dd:

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

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

ddпроверяет совпадение размеров блоков ввода / вывода при каждом копировании блока. Если они этого не делают, он обрабатывает ошибку с предупреждением или фатальной ошибкой (переопределяется с помощью noerror). Вот почему ddработает практически все время.

Тем не менее, он не заменяет проверку целостности вашего диска вручную. Если информация для вас ценна, то да, ваша паранойя оправдана . Запустите ручную проверку, как только ddзакончите.

— iangolden
источник

ddне работает практически все время: с bsпараметром игнорирует некоторые ошибки .

— Жиль "ТАК - перестань быть злым"