— процесс восстановления/копирования образа в принципе гораздо лучше делать в Linux (если конечно консоль и dd не пугает, хоть и с гуглежкой), открыв в соседнем окне dmesg -w. Там, где винда зависает наглухо, в лине копирование может вполне успешно продолжаться после таймаута и/или пропуска сбойного места, с возможными подробностями в dmesg. Еще спецэффекты от сбоев сильно зависят от контроллера SATA
Весьма спорно, что это лучше. Если диск зависает, то лучше его линейно не читать во избежание получения фактурных пластин с кучей металлической пыли. Кроме этого главная проблема зависаний Windows в попытке монтировать раздел на проблемном накопителе. После отключения этой опции Windows ведет себя более адекватно.
Рекомендую добавить расшифровки и краткие пояснения специфичных терминов/аббревиатур (БМГ, коммутатор-предусилитель, парковочная рампа...) при первом их упоминании. Или ссылку на статью, если уже где-то описывали.
добавлю расшифровку аббревиатур в ближайшее свободное время. мое упущение.
Разумеется заочный диагноз не претендует на точность. Но из вашего описания можно предположить проявления весьма характерной проблемы этого семейства.
В этих дисках нередко оказывается нечитабельной таблица MediaCache. Симптоматика такова, что накопитель может выйти в готовность и даже отдать сразу паспорт, но на попытки чтения ответит «ABR» (отбоем команды).
В этих случаях, как правило требуется вмешательство в микрокод. Вычитывание обеих копий таблиц и дальнейшая реконструкция. После чего накопитель можно будет вывести в готовность и осторожно приступить к вычитыванию дефектов.
Просто сбросить таблицу и очистить медиакеш не стоит. Так как он работает по принципу: сначала запись в медиакеш, а потом уже накопитель запишет это в основную юзерзону, когда это заблагорассудится сделать его микропрограмме.
Проблема как раз в том, как заставить R-studio (или другую программу) интерпретировать часть секторов, как физически недоступные.
а смысл? Ведь если в местах пропусков в вашем образе нули или какой-то паттерн, но не куски чужой MFT, то на качество сканирования не повлияет. Если нужные данные не находятся при анализе метаданных, то кроме поиска регулярных выражений по нужным типам файлов вам ничего не светит.
Достаточно классическая ситуация. Кто-то на момент создание RAID не задумывался, как будет происходить уведомление в случае отказа одного из дисков. Порой достаточно одного небольшого подвисания из-за точечного дефекта, чтобы накопитель был исключен из массива.
Исключение произошло. Никто не заметил этого и два года работали на одиночном диске не проверяя целостность массива.
Отключение автоматического монтирование подразумевает, что содержимое MBR или GPT все равно будет прочитано. Не будут читаться лишь метаданные файловых систем.
Бегло глянул в статью. Как бы на дисках с GPT и с наличием защитной MBR по 0x1B8 обычно нули и windows не порывается заниматься самодеятельностью.
Что касается Acronis то его клонирование дисков часто не является честной посекторной копией. И номер в 0x1B8 в копии зачастую другой. В старых windows это не приводило к отказу загрузки. Для Windows Vista и выше как правило bootmgr вылетает с ошибкой «Status: 0xc000000e Info: The boot selection failed because reqired device is inaccessible»
Если в boot sector NTFS корректная информация, то возможны 2 сценария:
1. Если живы первые записи MFT или цела MFT mirr то будет достаточно просто сканировать все записи MFT и не сканировать весь раздел, чтобы увидеть возможное древо каталогов.
2. Если первые записи MFT убиты и копия MFT mirr тоже, то потребуется полный скан раздела, чтобы найти все фрагменты MFT и после уже разбирать, что относится к актуальным записям.
можете попробовать R-Studio, DMDE в первом случае просто раскрыть раздел, а во втором с полным сканом.
Для всего этого ПО лог от ddrescue не будет полезен. Полезным он будет лишь на дальнейшем анализе повреждений файлов.
К сожалению успокаиваться пока рано. Далеко не со всеми разновидностями контроллеров можно решать задачи восстановления данных. Слишком много исследовательской работы еще предстоит проделать. Для решения многих актуальных задач.
У ssd насколько я понимаю обычно дохнет контроллер,
в подавляющем большинстве случаев он жив. Что с ним может статься. Посудите логически — это же обычный MCU, там ничего не изнашивается так явно, чтобы просто так умирала микросхема.
а он у каждой серии дисков может быть уникальный, поэтому восстановить данные потом бывает проблематично — микросхемы с памятью может и уцелели, но как именно их читать знает только конкретный контроллер.
MCU (контроллер) совершенно не уникален. Да там, есть небольшой boot ROM но его содержимое будет одинаково для огромного количества дисков. Проблемы SSD в подавляющем большинстве случаев кроются либо в NAND памяти, либо в повреждениях модулей служебки записанных в NAND.
Если найдётся подходящий контроллер-донор, то можно и восстановить, но может и не найтись.
в 99% случаев для мертвых SSD нет нужды искать донорский контроллер. Как правило работа в технологических режимах с поиском структур ответственных за трансляцию с дальнейшим чтением «по физике» в порядке установленном найденными и разобранными структурами. Либо для некоторых SSD применим метод распайки на микросхемы, чтение и дальнейший разбор алгоритма (можно посмотреть пример на простой USB flash, в случае SSD все будет несколько сложнее)
Говоря о дисках хорошо бы указывать модель, тогда будет понятно о чем идет речь и какие у предмета разговора могут быть общие проблемы.(Например в случае Seagate ST1000LM035 (семейство Rosewood), ST1000LM014(kahuna), ST1000LM010 (Sentosa) и т.п. )
вдруг стал определяется как 76 петабайт. Такое уже в домашних условиях не решается, возможно даже не решается в принципе.
Важно понять где он стал 76PB. Если в паспорте, то необходимо анализировать его миропрограмму. Если это записался бредовый размер в GPT и оснастка Windows показывает такую емкость, вряд ли это представляет серьезную проблему.
Статья изначально не планировалась для аудитории, которой надо рассказать, что такое жесткий диск. Предполагается, что на данном ресурсе ее будет читать человек представляющий как выглядят основные компоненты ПК и для которого не будут чем-то сверхъестественным действия вроде установки ПО или создания загрузочной USB flash.
И так уже планируемая коротенькая инструкция раздулась до неприличного размера.
Да, такие случаи встречаются. Как правило на предприятиях с большой текучкой кадров, маленькой заработной платой администратора и с полным непониманием руководства на предмет какими должны быть должностные инструкции для данной единицы коллектива.
При некорректно работающем накопители возможны всякие сюрпризы
1. выдача мусора вместо данных.
2. при попытке перезаписи некоторых метаданных возможны записи со сдвигами. (а при монтировании под Windows не так и мало пытается переписать.
Мне как-то удалось прочитать винчестер, который не запускался по обычному SATA,
В статье написано, что нужно отключить автоматическое монтирование и убрать все MountPoints в реестре ОС. Всего лишь две команды в diskpart. После этого ОС не будет автоматически монтировать проблемный накопитель при загрузке и соответственно не будет зависания.
при наличии времени, желания возможно будет и такая статья. как всегда не буду зарекаться, что она выйдет в свет, но постараюсь рассмотреть возможность ее публикации.
Если диск справляется со требуемыми RW операциями без всяких нареканий и при тесте поверхности, seek тесте, тесте буферного ОЗУ не наблюдается никаких сбоев то определенно накопитель исправен. Некоторые накопители бывают достаточно громкими при непрерывном перемещении БМГ (что и происходит при запуске торрент-клиента).
Весьма спорно, что это лучше. Если диск зависает, то лучше его линейно не читать во избежание получения фактурных пластин с кучей металлической пыли. Кроме этого главная проблема зависаний Windows в попытке монтировать раздел на проблемном накопителе. После отключения этой опции Windows ведет себя более адекватно.
добавлю расшифровку аббревиатур в ближайшее свободное время. мое упущение.
В этих дисках нередко оказывается нечитабельной таблица MediaCache. Симптоматика такова, что накопитель может выйти в готовность и даже отдать сразу паспорт, но на попытки чтения ответит «ABR» (отбоем команды).
В этих случаях, как правило требуется вмешательство в микрокод. Вычитывание обеих копий таблиц и дальнейшая реконструкция. После чего накопитель можно будет вывести в готовность и осторожно приступить к вычитыванию дефектов.
Просто сбросить таблицу и очистить медиакеш не стоит. Так как он работает по принципу: сначала запись в медиакеш, а потом уже накопитель запишет это в основную юзерзону, когда это заблагорассудится сделать его микропрограмме.
В домашних условиях этого сделать не получится.
а смысл? Ведь если в местах пропусков в вашем образе нули или какой-то паттерн, но не куски чужой MFT, то на качество сканирования не повлияет. Если нужные данные не находятся при анализе метаданных, то кроме поиска регулярных выражений по нужным типам файлов вам ничего не светит.
Исключение произошло. Никто не заметил этого и два года работали на одиночном диске не проверяя целостность массива.
Итог закономерен.
Бегло глянул в статью. Как бы на дисках с GPT и с наличием защитной MBR по 0x1B8 обычно нули и windows не порывается заниматься самодеятельностью.
Что касается Acronis то его клонирование дисков часто не является честной посекторной копией. И номер в 0x1B8 в копии зачастую другой. В старых windows это не приводило к отказу загрузки. Для Windows Vista и выше как правило bootmgr вылетает с ошибкой «Status: 0xc000000e Info: The boot selection failed because reqired device is inaccessible»
1. Если живы первые записи MFT или цела MFT mirr то будет достаточно просто сканировать все записи MFT и не сканировать весь раздел, чтобы увидеть возможное древо каталогов.
2. Если первые записи MFT убиты и копия MFT mirr тоже, то потребуется полный скан раздела, чтобы найти все фрагменты MFT и после уже разбирать, что относится к актуальным записям.
можете попробовать R-Studio, DMDE в первом случае просто раскрыть раздел, а во втором с полным сканом.
Для всего этого ПО лог от ddrescue не будет полезен. Полезным он будет лишь на дальнейшем анализе повреждений файлов.
в подавляющем большинстве случаев он жив. Что с ним может статься. Посудите логически — это же обычный MCU, там ничего не изнашивается так явно, чтобы просто так умирала микросхема.
MCU (контроллер) совершенно не уникален. Да там, есть небольшой boot ROM но его содержимое будет одинаково для огромного количества дисков. Проблемы SSD в подавляющем большинстве случаев кроются либо в NAND памяти, либо в повреждениях модулей служебки записанных в NAND.
в 99% случаев для мертвых SSD нет нужды искать донорский контроллер. Как правило работа в технологических режимах с поиском структур ответственных за трансляцию с дальнейшим чтением «по физике» в порядке установленном найденными и разобранными структурами. Либо для некоторых SSD применим метод распайки на микросхемы, чтение и дальнейший разбор алгоритма (можно посмотреть пример на простой USB flash, в случае SSD все будет несколько сложнее)
Говоря о дисках хорошо бы указывать модель, тогда будет понятно о чем идет речь и какие у предмета разговора могут быть общие проблемы.(Например в случае Seagate ST1000LM035 (семейство Rosewood), ST1000LM014(kahuna), ST1000LM010 (Sentosa) и т.п. )
Важно понять где он стал 76PB. Если в паспорте, то необходимо анализировать его миропрограмму. Если это записался бредовый размер в GPT и оснастка Windows показывает такую емкость, вряд ли это представляет серьезную проблему.
И так уже планируемая коротенькая инструкция раздулась до неприличного размера.
1. выдача мусора вместо данных.
2. при попытке перезаписи некоторых метаданных возможны записи со сдвигами. (а при монтировании под Windows не так и мало пытается переписать.
В статье написано, что нужно отключить автоматическое монтирование и убрать все MountPoints в реестре ОС. Всего лишь две команды в diskpart. После этого ОС не будет автоматически монтировать проблемный накопитель при загрузке и соответственно не будет зависания.