Сырье для чтения USB-накопитель или SCSI

На жестком диске USB жены есть небольшая проблема, когда папка отказывается открываться (файловая система NTFS). Я смог создать образ диска с Linux, но для одного сектора (сектора 4096 байт). Чтение этого сектора не удается:

sudo dd if = / dev / sdb of = пропуск блока = 21647245 bs = 4096 count = 1 dd: ошибка чтения '/ dev / sdb': ошибка ввода / вывода 0 + 0 записей в 0 + 0 записей 0 байт (0 B) скопировано, 22,9317 с, 0,0 кБ / с 

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

При доступе к указанному сектору вывод dmesg выглядит так:

[20381.842495] SD 7: 0: 0: 0: [SDB] Необработанный смысловой код [20381.842506] SD 7: 0: 0: 0: [SDB]  [20381.842510] Результат: hostbyte = DID_ERROR driverbyte = DRIVER_SENSE [20381.842514] SD 7: 0: 0: 0: [SDB]  [20381.842517] Sense Key: Аппаратная ошибка [текущий]  [20381.842531] SD 7: 0: 0: 0: [SDB]  [20381.842535] Add. Смысл: нет дополнительной информации о смысле [20381.842539] SD 7: 0: 0: 0: [SDB] CDB:  [20381.842542] Читать (10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: ошибка ввода-вывода, dev sdb, сектор 173177960 [20381.842572] Ошибка ввода-вывода в буфер на устройстве sdb, логический блок 21647245 

Есть ли способ прочитать этот сектор, необработанный, без проверки CRC или что-то еще, чтобы попытаться восстановить некоторые поврежденные данные?

Я открыл корпус: жесткий диск является родным USB, нет преобразования USB в SATA.

Редактировать: Пробовал ddrescue, но не смог также восстановить поврежденный сектор. Читая 2Gigs вокруг плохого сектора, пусть головы стабилизируются после поиска:

sudo ddrescue -s 2Gi -o 0 -i 87593373696 / dev / sdb blkk GNU ddrescue 1.19 Нажмите Ctrl-C, чтобы прервать спасено: 2147 МБ, ошибка: 4096 B, текущая скорость: 0 B / s IPOS: 88667 МБ, ошибки: 1, средняя скорость: 8488 КБ / с. opos: 1073 МБ, время выполнения: 4,21 м, успешное чтение: 1,06 м назад Законченный

Чтение назад (флаг -R) тоже не удалось.

Редактировать 2: Мой запланированный второй шаг состоял в том, чтобы использовать судебную экспертизу, чтобы попытаться получить недостающие файлы. Я впервые начал смотреть на MFT вручную, но это быстро становится очень, очень утомительным. Итак, в моем списке были следующие инструменты:

1. Sleuthkit
2. NTFS-3g
3. скальпель
4. выпросить-NTFS

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

С помощью Ntfs-3g (сейчас Tuxera) можно смонтировать образ с отладочными данными:

sudo mount -o loop, ro, offset = 258048, debug image2 ./mnt -t ntfs-3g 

Попытка войти в неисправный каталог вызовет ошибку:

Индексный буфер (VCN 0x0) каталога inode 101874 имеет размер (24), отличный от указанного размера каталога (4096). 

Поиск этой ошибки в DuckduckGo привел меня к следующему сообщению: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 Оказывается, что люди из Tuxera / ntfs-3g действительно поощряют использование Microsoft CHKDSK для восстановления ошибок NTFS

Запуск chkdsk на диске был моим третьим и последним запланированным шагом, однако его следует попробовать намного раньше, зная, что он МОЖЕТ быть запущен на образе диска, используя, например, OSFMount ( http://www.osforensics.com/tools/mount- disk-images.html ).

Большинство отсутствующих файлов и каталогов (если не все) были восстановлены программой chkdsk / f на смонтированном образе диска. Более ста ошибок (большинство из которых являются потерянными файлами) были исправлены.

Изменить 3: Я принимаю ответ псуси. Несмотря на то, что это оказалось невозможным, попытка чтения поврежденных секторов, безусловно, является наиболее неопределенным и сложным способом восстановления данных со слегка поврежденного жесткого диска.