GNU ddrescue & NTFS, проверка на идентичность.

Клонировал как-то слегка проблемный диск (оффтопик уже до конца не загружался) целиком (включая раздел восстановления) примерно так: https://wiki.archlinux.org/index.php/Disk_cloning#Using_ddrescue

На склонированном диске система запустилась нормально.

dd/ddrescue именно так и делает - переносит байт в байт.
только ddrescue заточен под вычитывание данных с проблемных hdd.

Пользуйся GNU ddrescue. На ФС ему наплевать. На всякий случай отмечу, что dd и ddrescue разные программы, общего у них только название и работа с блочными устройствами. А ещё существует dd_rescue, не перепутай. На хабре есть статья с кратким описанием различий таких утилит.

Принял, благодарю за информацию.

Винт потенциально проблемный, прогон Victoria ранее указывал на один UNCHCK сектор, а они, как правило, не одиноки.

Я неспроста указал на приставку GNU, спасибо за информацию. Остался один вопрос, так как количество SATA Power/Molex разъемов ограничено, похоже придется грузиться с USB-флешки. Чтобы минимизировать риски по причине, например, своей криворукости, хотелось бы что - то готовое в формате LiveCD(USB) c GNU ddrescue, rsync на борту. Что - то минимальное и надежное.

Алсо, в инструкциях пишут что понадобится физ. разъем как минимум в 1.5 раза больше чем тот с которого клонируем, кхм, как то странно...

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

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

Лучше начать с ntfsclone — она читает только занятую данными область. Если там все чисто, то ddrescue не понадобится вовсе.

Алсо, в инструкциях пишут что понадобится физ. разъем как минимум в 1.5 раза больше чем тот с которого клонируем, кхм, как то странно…

Зачем? Копирование dd и ddrescue посекторное, сколько на источнике было, столько на приёмник запишется. В моём случае размер дисков был один в один.

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

Тот, что создаёт ssrescue? Его можно скинуть на флешку. Но он нужен для второго прогона, для выполнения которого перезагрузка не нужна, и далее только как история.

Все - таки решил не трогать GNU ddrescue, т.к нашел более простое решение в виде Clonezilla, готовый LiveCD весит всего 200mb. Клонирование там может быть и посредством dd, но по умолчанию используется partclone. Непонятно только как верифицировать клонированный диск, что будет если partclone наткнется на бэд тоже не ясно. Может кто - то сталкивался с сие утилитой ?

До этого момента для верификации я планировал пройтись rsync в тестовом режиме с вычислением сумм для файлов, но, во - первых это долго, во - вторых rsync по - моему нет в составе Clonezilla (хотя, она основана на Debian, наверное все - таки есть). Можно ли быть уверенным что все скопировалось успешно если partclone завершит свою работу ?

Clonezilla включает и ntfsclone и partclone, вот только как понять что все прошло «чисто» не ясно.

как понять что все прошло «чисто»

Для утилит *nix традицией является молчать при успехе и материться при ошибках.
В дополнение можно посмотреть системный журнал — драйверы ругаются на ошибки чтения диска именно туда.

Да, нагуглил упоминание о clone failure если натыкается на бэд и -rescue аргумент для того чтобы продолжил и после этого клонировать. Буду надеяться что мне повезет, ну и rsync прогоню если он там окажется. Спасибо.

От bit rot защиты нет, но это редкость. Кроме того, если старый диск портит данные при чтении, то уже поздно пить боржоми, надо было раньше считать контрольные суммы или даже заготавливать информацию для восстановления по кодам Рида-Соломона по помощи par2 или rar.

Резервных копий именно этого носителя у меня нет, т.к пользовался им не я. В общем, я в достаточном замешательстве. При клонировании, partclone таки нарвался на плохой блок и остановил свою работу. Я, надеясь что это один - два рандомных блока запустил его с --rescue параметром, клонирование завершилось, но при этом было утеряно около 40 блоков. Вот не знаю, насколько это критично. По моим расчетам (диск 512n) это около 20 Кбайт информации, хотя в NTFS информация по 4 Кбайт хранится, по идее каждый блок приводит к потере/искажению целых 4 - ех ? Тогда уже 160 Кбат... Вроде бы мизер, а попадись он на БД или еще какой чувствительный к повреждениям файл... С другой стороны, если до клонирования особых жалоб не было, а диск ведь уже эти блоки имел, может они пришлись на системное/пустое пространство или вообще логические. Запускать GNU ddrescue ведь особого смысла нет ? Стоит проверить на целостность ФС на новом носителе ? Вообще, в теории, можно ли как - то узнать что хранилось на тех блоках, посмотрев что хранится рядом например ? Номера всех блоков есть в логе.

Извините за возможно излишнее беспокойство, bormant, greenman, но мне действительно нужна ваша помощь т.к я не знаю как лучше поступить в этой ситуации...

Запускать GNU ddrescue ведь особого смысла нет ?

Перечитай мой первый ответ. Я клонировал проблемный hdd в два прохода. Повезло, что проблемные секторы оказались не столь важны. Может быть повезёт и тебе.

Не знаю, как работает partclone.

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

https://www.radagast.ca/linux/how-to-find-the-ntfs-filename-associated-with-a...

Спасибо за наводку. Пытаюсь, выходит так себе. Вот список секторов которые partclone не считал:

140658552320 140658551808 140658551296 140658550784 140658550272 140658549760 140658549248 140658548736

158678765568 158678766080 158678766592 158678767104 158678767616 158678768128 158678768640 158678769152

183264505856 183264506368 183264506880 183264507392 183264507904 183264508416 183264508928 183264509440

235490750464 235490750976 235490751488 235490752000 235490752512 235490753024 235490753536 235490754048

fdisk говорит что /dev/sda содержит три раздела:

sda1 (2048-206847)

sda2 (206848-975849471)

sda3 (975849472-976771071)

ntfsinfo говорит что Index Block Size: 4096

В инструкции по линку говорится что нужно высчитать смещение т.к раздел на диске не один, но я так и не понял как это сделать. Попытался поделить каждый сектор из списка на 4096, получился для каждой группы вроде как свой кластер e.g 140658552320/4096 = 34340466.

ntfscluster -c 34340466 /dev/sda2

Выдает кучу строк типа

Inode XXXXX is an extent of inode XXXX

И в конце:

Failed to malloc 4096 bytes: Cannot allocate memory Couldn't read the data runs.

И так для каждой группы, пробовал еще через -s передавать диаппазон e.g 140658550000-140658560000, кончается тем же самым. Обидно что в интернете никаких толковых примеров нет, так пара строк с example в man...

список секторов которые partclone не считал

partclone выдает смещение до сектора или номер сектора?
В первом случае делить нужно на Cluster size, во втором — домножить на размер сектора.
Это смещение от начала раздела или от начала диска?

fdisk говорит что /dev/sda содержит три раздела:

Он там в заголовке еще и размер блока указывает, и units можно явно задать. Вроде как размеры в 512-байтных блоках должны быть. Это чтобы не было путаницы с размерами/смещениями.

ntfsinfo говорит что Index Block Size: 4096

А нужен Cluster size.

partclone выдает смещение до сектора или номер сектора

Дословно писало WARNING: Can't read sector at xxx, lost data.

Никакой информации о ситуациях с бедами кроме рекомендации использовать -rescue аргумент нет, я вообще не ожидал настолько бедной документации. Помню что еще на экране вроде как именно копирование sda2 было. Вообще, я фотографировал когда новые блоки появлялись так как опасался что лога не найду (таки не нашел, он вайпнулся при перезагрузке), конечно не сразу, но раз в пять минут поглядывал на экран и сравнивал номер последнего найденного. Например, когда появились беды первой группы (140658548736-140658552320) на экране было, примерно получается, Current Block: 34450052 и Total block: 110332159. Что здесь имеется в виду под блоком не ясно, но 140658552320/4096 = 34340466 что ± 34450052, и такая тенденция прослеживается с остальными группами (для каждой группы свое фото с Current значением)

Он там в заголовке еще и размер блока указывает, и units можно явно задать. Вроде как размеры в 512-байтных блоках должны быть. Это чтобы не было путаницы с размерами/смещениями.

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

А нужен Cluster size.

Cluster Size: 4096

Sector Size: 512

Тогда похоже, что
в выводе psrtclone — смещения непрочитанных секторов от начала раздела,
8 идущих подряд секторов по 512 байт как раз дают кластер в 4096 байт,
4 группы по 8 секторов как раз дают 4 сбойных кластера.

А какой версии ntfscluster?
Что со свободной памятью?

Если сбойные блоки попробовать вычитать при помощи dd conv=noerror ... в системный журнал упадут ошибки чтения от контроллера диска?

Можно попробовать «помассировать» сбойные участки при помощи mhdd или Victoria (добавить к смещениям начало раздела, и проверить, адресация по LBA в смещениях или блоках). Если повезет, может быть вызван remap с сохранением данных в подменный блок. Если ошибка останется, то данные в этих блоках все равно потеряны.

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

От partclone — утилиты, вычитывающей логическую структуру ФС на разделе, сложно ждать чего-то, другого. С физическими дефектами носителя должно разбираться совсем на другом уровне (контроллер, драйвер ФС, бэдблоки и вот это все). А partclone рассчитан на бэкап/восстановление исправных ФС с исправных носителей.
В такой ситуации не упасть по ошибке чтения вполне разумный и достаточный вариант.

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

fdisk выдал начало раздела в 512-байтных блоках. Если по смещению от начала раздела нужно получить смещение от начала диска, то BlockStartPart+PartStart*512
Если есть подозрение, что для сбойных блоков выдано смещение от начала диска, то наоборот: BlockStartGlob-PartStart*512

В сухом остатке:
Если partclone выводил смещения от начала раздела, то это кластеры:
34_340_466, 38_739_933, 44_742_311, 57_492_859

Если partclone выводил смещения от начала диска (что вряд ли представляется разумным), то с корректировкой на начало раздела (206848*512=105_906_176) это кластеры:
34_314_610, 38_714_077, 44_716_455, 57_467_003

Вопрос про версию ntfscluster актуален.

Пересчет секторов в кластеры можно возложить на ntfscluster при помощи ключа -s:

# ntfscluster -s 140658548736 /dev/sda2
# ntfscluster -s 158678765568 /dev/sda2
# ntfscluster -s 183264505856 /dev/sda2
# ntfscluster -s 235490750464 /dev/sda2

Премногого почитаемый мной bormant, искренне благодарен, вам честь и хвала ! Только с вашей помощью удалось таки разобраться во всем и успокоится. Склоняю голову пред вашими соблаговолением и мудростью ! Извините меня за задержку в ответе, я некоторое время не мог проверить ваши сообщения.

Вопрос про версию ntfscluster актуален.

v2017.3.23AR.3 (libntfs-3g)

Ваши вычисления полностью совпали с моими, каково же было разочарование когда я вновь увидел кучу строк «Inode ... is an extend of inode ...» вместо сколь угодно ожидаемого результата. Но, изрядно утомившись использованием Shift+PU в процессе изучения очередного выхлопа, я решил вывести результаты в лог файл и изучить его средствами nano. Каково же уже было моё удивление, когда в лог файле я увидел ожидаемое «Searching for cluster xxx ...» без вороха строк про ноды, кроме единственной сопоставимой с путем файла. Я понятия не имею, было ли это так задумано изначально, но намек понял и остальные кластеры/сектора сканировал уже выводя результат в лог файл. Итого, я на всякий случай проверил и те и те кластеры, также все сектора.

Один кластер выдался на файл IDE от Embarcadero, один на mp3 файл из медиатеки (кстати уже очень рядом с относительно важными файлами), еще один на некий WimProvider.dll из AppData, тройка выпала на своп (pagefile.sys), остальные ни на что, как и все сектора, наверное, нужно передавать именно диапазон таковых.

Конечно, как и говорится в инструкциях использовать ntfscluster лучше со снятым образом, потому как работая с диском-источником не ясно, не было ли ремапа после клонирования. Да и в целом образ можно проверить, вдруг чего не так скопировалось. Но, таки все равно уже намного спокойнее будет спать, наверное пройдусь еще раз уже указывая диапазон кластеров, также посмотрю на вывод dd по секторам. Вот не знаю, стоит ли выполнять chkdsk на новом диске, таблицу разделов partclone полностью копировал с источника, не хотелось бы ФС потерять, насколько я полагаю, там где partclone не мог прочитать он просто ставил нули, это конечно может привести к тому что файл будет битый, но ФС на это по барабану, наверное, хотя, опять же эти ноды, все - таки запущу позже.

В той статье, на которую давал ссылку выше, было

ntfscluster ... 2>/dev/null

Остался один вопрос, так как количество SATA Power/Molex разъемов ограничено, похоже придется грузиться с USB-флешки. Чтобы минимизировать риски по причине, например, своей криворукости, хотелось бы что - то готовое в формате LiveCD(USB) c GNU ddrescue, rsync на борту. Что - то минимальное и надежное.

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

И ddrescue - отличная утилита. Я ей клонировал подыхающий диск полностью (не разделы, всё устройство /dev/sdX) на бо́льший диск, потом проверял файловую систему уже на нормальном рабочем диске и исправлял ошибки, потом увеличивал объём раздела под новый диск. Имхо - это самый правильный порядок. Если диск подыхает - работай с максимально рабочей копией на исправление ошибок.

Рекомендации прикладного ПО приветствуются, спасибо.

Дальнейшая обработка логов ddrescue:

ntfsheurecovery (GIT)

how-to-find-the-ntfs-filename-associated-...

Полезная инфа. А debugfs к ntfs применить нельзя? Большинство источников указывает именно на эту фс при разгребании лога badblocks. К чему склоняться то?