На жестком диске USB жены есть небольшая проблема, когда папка отказывается открываться (файловая система NTFS). Я смог создать образ диска с Linux, но для одного сектора (сектора 4096 байт). Чтение этого сектора не удается:
sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1 dd: error reading ‘/dev/sdb’: Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 22.9317 s, 0.0 kB/s
Замена этого сектора нулевыми байтами приводит к тому же симптому, что и в Windows, поэтому сектор, похоже, связан с проблемным каталогом.
При доступе к указанному сектору вывод dmesg выглядит так:
[20381.842495] sd 7:0:0:0: [sdb] Unhandled sense code [20381.842506] sd 7:0:0:0: [sdb] [20381.842510] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514] sd 7:0:0:0: [sdb] [20381.842517] Sense Key : Hardware Error [current] [20381.842531] sd 7:0:0:0: [sdb] [20381.842535] Add. Sense: No additional sense information [20381.842539] sd 7:0:0:0: [sdb] CDB: [20381.842542] Read(10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: I/O error, dev sdb, sector 173177960 [20381.842572] Buffer I/O error on device sdb, logical block 21647245
Есть ли способ прочитать этот сектор, необработанный, без проверки CRC или что-то еще, чтобы попытаться восстановить некоторые поврежденные данные?
Я открыл корпус: жесткий диск является родным USB, нет преобразования USB в SATA.
Редактировать: Пробовал ddrescue, но не смог также восстановить поврежденный сектор. Читая 2Gigs вокруг плохого сектора, пусть головы стабилизируются после поиска:
sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk GNU ddrescue 1.19 Press Ctrl-C to interrupt rescued: 2147 MB, errsize: 4096 B, current rate: 0 B/s ipos: 88667 MB, errors: 1, average rate: 8488 kB/s opos: 1073 MB, run time: 4.21 m, successful read: 1.06 m ago Finished
Чтение назад (флаг -R) тоже не удалось.
Редактировать 2: Мой запланированный второй шаг состоял в том, чтобы использовать судебную экспертизу, чтобы попытаться получить недостающие файлы. Я впервые начал смотреть на MFT вручную, но это быстро становится очень, очень утомительным. Итак, в моем списке были следующие инструменты:
- Sleuthkit
- NTFS-3g
- скальпель
- выпросить-NTFS
Sleuthkit не сделал бы ничего полезного, прекратив очень рано жаловаться на ошибки в структурах метаданных.
С помощью Ntfs-3g (сейчас Tuxera) можно смонтировать образ с отладочными данными:
sudo mount -o loop,ro,offset=258048,debug image2 ./mnt -t ntfs-3g
Попытка войти в неисправный каталог вызовет ошибку:
Index buffer (VCN 0x0) of directory inode 101874 has a size (24) differing from the directory specified size (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: Я принимаю ответ псуси. Несмотря на то, что это оказалось невозможным, попытка чтения поврежденных секторов, безусловно, является наиболее неопределенным и сложным способом восстановления данных со слегка поврежденного жесткого диска.