У USB HDD жены есть небольшая проблема, когда папка отказывается открываться (файловая система NTFS). Мне удалось создать образ диска с помощью Linux, но для одного сектора (секторы имеют размер 4096 байт). Чтение этого сектора не удается:
sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1 dd: ошибка чтения '/dev/sdb': Ошибка ввода/вывода 0+0 записей в 0+0 записей вышло 0 байт (0 Б) скопировано, 22,9317 с, 0,0 кБ/с
Замена этого сектора нулевыми байтами приводит к тем же симптомам, что и в Windows, поэтому сектор, по-видимому, связан с проблемным каталогом.
При доступе к указанному сектору вывод dmesg выглядит следующим образом:
[20381.842495] sd 7:0:0:0: [sdb] Необработанный код смысла [20381.842506] сд 7:0:0:0: [сдб] [20381.842510] Результат: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514] сд 7:0:0:0: [сдб] [20381.842517] Сенсорный ключ: Аппаратная ошибка [текущая] [20381.842531] сд 7:0:0:0: [сдб] [20381.842535] Доп. чувство: Нет дополнительной информации о чувстве [20381.842539] сд 7:0:0:0: [сдб] ЦДБ: [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 Б, текущая скорость: 0 Б/с ipos: 88667 МБ, ошибок: 1, средняя скорость: 8488 кБ/с opos: 1073 MB, время выполнения: 4.21 мин, успешное чтение: 1.06 мин назад Законченный
Чтение в обратном направлении (флаг -R) также не удалось.
Редактировать 2:Вторым моим запланированным шагом было использование криминалистики для попытки получить недостающие файлы. Сначала я начал просматривать MFT вручную, но это быстро становится очень, очень утомительным. Поэтому в моем списке были следующие инструменты:
- Сыщик
- ntfs-3g
- скальпель
- scrounge-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 на самом деле поощряют использование CHKDSK от Microsoft для исправления ошибок NTFS.
Запуск chkdsk на диске был моим третьим и последним запланированным шагом, однако его следует попробовать гораздо раньше, учитывая, чтоего МОЖНО запустить на образе диска, например, с помощью OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).
Большинство отсутствующих файлов и каталогов (если не все) были восстановлены с помощью chkdsk /f на смонтированном образе диска. Исправлено более сотни ошибок (большинство из которых были потерянными файлами).
Редактировать 3:Я принимаю ответ psusi. Хотя это и не доказано, но попытка прочитать поврежденные сектора, безусловно, является самым неопределенным и сложным путем восстановления данных с умеренно поврежденного жесткого диска.
решение1
Нет, это невозможно. Для этого есть команда SCSI, но вы все равно получите только мусор, и она не поддерживается на дисках потребительского уровня, особенно USB. Все, что было в этом секторе, исчезло.