Сырье для чтения 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 кБ / с. Опции:     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) индексного узла 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: Я принимаю ответ псуси. Несмотря на то, что это оказалось невозможным, попытка считывания поврежденных секторов, безусловно, является наиболее неопределенным и трудным путем восстановления данных со слегка поврежденного жесткого диска.