Неисправный диск Windows/NTFS. Я смог подключиться к другому компьютеру через кабель USB-IDE и восстановить большую часть диска с помощью Knoppix 7.2 LiveUSB и ddrescue/ddrutitliy . Я восстановил наиболее важные данные. Сейчас я использую его в качестве учебного упражнения и выясняю, смог бы я упростить процесс и насколько я смог бы вернуться, не вмешиваясь в аппаратное обеспечение.
Полный рассказ ниже, но мне было интересно, если кто-нибудь успешно создал сценарий для обработки ситуации с диском (USB или другим), который либо прерывисто, либо по известной причине отключается во время спасения.
Используя ddru_ntfsbitmap я смог вытянуть загрузочный сектор и растровое изображение MBR, чтобы сузить восстановление до только что использованного файлового пространства (16 ГБ на диске 60 ГБ). Используемая команда была:
ddru_ntfsbitmap -i 32256 -m MFTDomainFile.txt /dev/sdc filelocations.txt
(-i использует 63*512 = 32256 поскольку диск не будет монтироваться, чтобы найти 63 из fdisk, я должен был угадать, пока ddru_ntfsbitmap не сообщит мне, что может найти загрузочный сектор. Видимо это обычно 63 или 2048.)
Этот диск часто отключается, и есть одна секция диска (первые 950 МБ), где он отключается после ошибки чтения одного сектора. Для продолжения необходимо потянуть кабель usb-IDE и снова подключить его, чтобы привод снова отображался в /dev. На этом ПК (или, может быть, это связано с Knoppix), если диск отключается, ddrescue продолжает помечать дополнительные попытки чтения как ошибки, что затрудняет отслеживание проблем чтения «реального» сектора. (На другом старом ПК с Ubuntu он каким-то образом обнаружит это и прекратит работу с ddrescue , хорошей функцией, но я не знаю, что было причиной такого другого поведения.) После нескольких запусков и перезапусков я смог использовать ddrescue для одновременного чтения / копирования больших разделов и получения большей части диска. (> 95% раздела с лучшим поведением). Используя опции -i и -s , я работаю и ограничиваю влияние проблемы «пометить все как плохое».
Обычно команда, которую я использовал, была что-то вроде:
ddrescue -S -m filelocations.txt /dev/sdc HDImage.img HDRecoverlog.txt -r2 -d -i5GB -s1GB
если он обрезается, он помечает только 1 ГБ раздел как плохой, и я могу повторить попытку добавления -AM чтобы он заблокировал копирование, или просто запустить с -r5 . Скорость копирования в медленных разделах не имела большого значения, и она делалась бы чаще при выполнении блок-копий.
После получения всех больших неопробованных разделов, позволяя ddrescue работать в течение ночи на более стабильной части диска, обнаружил большинство ошибок сектора в этом разделе. ddru_ntfsfindbad (чтобы найти, в каких файлах были ошибки) сообщил о 20 секторальных ошибках в $ MFT, поэтому я перезапустил всю ночь, используя:
ddrescue -S -m MFTDomainFile.txt /dev/sdc HDImage.img HDRecoverlog.txt -r-1 -d
Это обнаружило все ошибки $MFT , поэтому я запустил ddru_ntfsfindbad чтобы найти файлы, которые все еще имели ошибки на остальной части диска:
ddru_ntfsfindbad -i 32256 -DD -HDImage.img HDRecoverlog.txt
(-DD создает файл журнала отладки с расположением секторов для каждого inode, который можно объединить с обычным ntfsfindbad.log чтобы найти каждый файл с ошибкой.)
Просто позволив ddrescue работать на стабильной части в течение целых выходных, он обнаружил в этом разделе все ошибки сектора, кроме двух (из 1112 ошибок в пятницу). ddru_ntfsfindbad привел к гораздо меньшему списку ошибок файла.
Для сложной передней части накопителя оставалось ~ 150 МБ, помеченных как «плохие». Многое было просто пропущено / не проверено, но помечено так же плохо, как и отключение диска. Используя журнал ntfsfindbad, я мог вручную нацелить файл с помощью следующего (очевидно хорошо известного) болезненного процесса:
- Подключите USB-разъем.
- Выполните команду
ddrescueпосле раскрутки. - Нажмите
CTRL-Cесли я слышу, что он обнаружил плохой сектор, в противном случае он теряет свое местоположение, как указано выше.- с
CTRL-Cон останавливается на следующем секторе и начнется там в следующий раз. - опция
-Xустраняет необходимость в этом, но она остается в проблемном секторе, а не в продвижении, и никогда не будет проходить мимо действительно плохого сектора.
- с
- отключите диск, чтобы отключить питание
- Перейти (1)
Большинство интересующих меня файлов мне удалось полностью восстановить таким способом. Ручное нацеливание / разбиение больших непроверенных разделов может привести к потере целого раздела без ошибок. Но иногда мне приходится повторять конкретную ошибку 10-20 раз. Используя этот процесс, все ошибки, кроме ~ 150 КБ, «быстро» устраняются. С тех пор повторная попытка вручную снизилась до ~ 55 ошибок одного сектора и 31 кБ. Основываясь на поведении остальных дисков, я не удивлюсь, если смогу очистить все, кроме нескольких действительно поврежденных секторов, и, возможно, заставить работать весь образ после замены нескольких файлов (конечно, Windows / system32 сидит в этом разделе).
Я понимаю, что это довольно удачный (хотя и редкий) случай, когда данные можно восстановить. Но на последнем диске, который я спас, была очень похожая проблема "диск отключен при одной ошибке чтения". Я прочитал несколько постов о том, как попытаться перезагрузить или отключить питание диска и / или USB-порта. Из того, что я видел, возможность отключения питания USB сильно зависит как от аппаратного, так и от ядра Linux. Я также понимаю, что существуют решения для аппаратного и сервисного обслуживания, которые могли бы помочь в этом, если бы соотношение затрат и выгод было другим.
Итак, есть ли лучший способ справиться с 5-шаговым процессом выше? Это, возможно, также ускорило начальную очистку данных в «хорошем» разделе (меньше ручного). Был ли лучший способ (все еще сделай сам), чтобы заняться всем процессом?