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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

От man dd:

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

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

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

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