В данной статье описываются методы самостоятельной диагностики различных неисправностей жестких дисков по симптомам их проявления, а также способы относительно безопасного клонирования жестких дисков с незначительными проблемами.

Рассмотрены различные случаи утраты данных и набор оптимальных действий, которые без глубоких знаний устройства файловых систем с помощью программ автоматического восстановления помогут вам вернуть вашу информацию без посторонней помощи.

Но прежде, чем приступить к каким-либо самостоятельным действиям, необходимо внимательно ознакомиться со всеми материалами статьи, и только потом анализировать состояние вашего жесткого диска, чтобы ваши попытки не стали последними в жизни накопителя, и чтобы оными вы не лишили себя последних надежд на восстановление нужных вам данных.




СОДЕРЖАНИЕ


Часть первая: Диагностика


1. Визуальный осмотр
2. Тестовый запуск
3. Подготовка к тестированию
4. Тестирование
5. Посекторная копия

Часть вторая: Восстановление данных.


6. Методы восстановления данных
7. Типовые случаи и рекомендуемые действия
8. Проверка целостности файлов
9. Частые ошибки пользователей

Соглашаясь на следование дальнейшим инструкциями, вы осознаете, что никто кроме вас самих не несет ответственности за возможный выход из строя накопителя и безвозвратную потерю данных. Набор мер направлен на снижение вероятности наступления неблагоприятного исхода, но не страхует от него на 100%.

Диагностика


1. Визуальный осмотр


Осмотрите накопитель на предмет наличия деформаций, отсутствующих или выгоревших элементов на плате контроллера, проверьте целостность разъемов. Если обнаруживаются какие-то серьезные повреждения или выгоревшие элементы, то настоятельно не рекомендуется пытаться подавать питание на такой накопитель, во избежание усугубления проблемы.

Используя отвертки (как правило, это Torx — T5, T6, T9) открутите винты, фиксирующие плату контроллера, и проверьте состояние контактных площадок на плате контроллера.


Рис. 2 на контактных площадках присутствует оксидная пленка

При наличии окислов можно обычным ластиком попытаться убрать их с контактных площадок. Работать с ластиком можно только над плоскими площадками, как на рисунке. В иных случаях подобное действие неприменимо.


Рис. 3 очищенные контактные площадки.

Если обнаружились какие-то повреждения платы, то не стоит в современных жестких дисках пытаться подставлять плату контроллера от аналогичного накопителя, так как в современных устройствах в ПЗУ на плате могут находиться различные адаптивные параметры, которые формируются во время производственного цикла и уникальны для каждого накопителя. В относительно редких случаях чужие параметры могут грозить повреждением жесткого диска.

При наличии паяльной станции нужно осуществить перенос MCU, EEPROM, NV-RAM, NAND (смотря что имеется на борту платы контроллера и что из этого обязательно требуется переносить) и после такой адаптации использовать донорский контроллер. Стоит отметить, что для адаптации многих контроллеров будет достаточно перенести только микросхему EEPROM.

При подборе платы в первую очередь смотрите на вытравленный номер PCB. Дальше оценивайте совпадение маркировок MCU и VCM&SM контроллера. Если на оригинальной плате и плате донора маркировки MCU и VCM&SM контроллера отличаются, то высока вероятность, что плата потенциального донора не является подходящей. В рамках одного семейства могут существовать разные версии плат, и в некоторых случаях они могут быть совместимы с определенным оговорками, но не стоит пытаться выяснять это в домашних условиях.

Попытка подставить неподходящую плату контроллера (с иным номером на PCB) может привести к выгоранию коммутатора-предусилителя.

При наличии мультиметра проверьте цепи 5В и 12В на предмет короткого замыкания. Также проверьте сопротивление обмоток двигателя. Если есть в наличии гарантированно исправный точно такой же накопитель (совпадает производитель, модельный ряд, ревизия платы контроллера), то можно проверить, одинаковое ли количество выводов в колодке коммутатора будет прозваниваться на «землю», а также сравнить сопротивления. При серьезных различиях можно сделать вывод, коммутатор-предусилитель неисправен, и на этом прекратить какие-либо самостоятельные попытки дальнейшего восстановления данных.

2. Тестовый запуск


Удостоверьтесь в исправности вашей тестовой системы, во избежание постановки неверных диагнозов и если не обнаружилось каких-то внешних причин, препятствующих попытке старта, то подключите интерфейсный кабель и кабель питания к соответствующим разъемам и включите БП.

Если вам заведомо известно, что накопитель был ударен или уронен в рабочем состоянии, или до того, как попал к вам, начал издавать стучащие звуки, воздержитесь от попыток включения.

В этих случаях требуется обязательное вскрытие жесткого диска в условиях ламинарного бокса (или чистой комнаты) и скрупулезное обследование с использованием микроскопа.


Рис. 4 подключение кабелей к жестким дискам.

После подачи питания накопитель должен начать вращать вал. В некоторых случаях это может не произойти с совершенно исправными накопителями, если по каким-то причинам в настройки накопителя внесено требование подачи команды spin up.

При вращении вала появляется легкий шум от воздушного потока. В некоторых накопителях он едва слышим поэтому можно вооружиться стетоскопом (или держать накопитель близко у уха с соблюдением всех правил техники безопасности, чтобы не допустить короткого замыкания).
Если вместо шума воздуха слышна серия цикличных жужжаний, тихих писков или звуков, отдаленно похожих на телефонные гудки, то вероятнее всего накопитель не может начать вращение вала двигателя. Причины этому могут быть следующие: залипание БМГ вне парковочной рампы (зоны), заклинивание вала двигателя, неисправность микросхемы VCM&SM контроллера.

При наличии подходящего накопителя-донора можно проверить версию с неисправностью VCM&SM контроллера, если вы готовы выполнить необходимые адаптации донорской платы, описанные в пункте «визуальный осмотр».

В случаях же залипания БМГ вне парковочной рампы самостоятельные действия по мотивам роликов на youtube обычно приводят к образованию дополнительных царапин на поверхностях пластин либо отрыву слайдеров. Даже если вам удастся относительно удачно вывести БМГ на парковочную рампу, то дефекты полимерного покрытия, образовавшиеся в месте залипания слайдеров, микроцарапины от слайдеров, полученные при выводе БМГ, вкупе с процедурами оффлайн сканирования и пылью из неочищенного воздуха вряд ли позволят вам успеть прочитать существенный объем данных в подавляющем большинстве случаев до начала развития дальнейших необратимых деградационных процессов. Как происходит процесс восстановления данных в таких случаях в профильной компании можно ознакомиться в этой статье «Восстановление данных с внешнего жесткого диска Seagate FreeAgent Go»

При заклинивании вала двигателя обычно требуется пересадка пакета дисков в гермоблок накопителя донора. Такое мероприятие в домашних условиях без должной подготовки и отсутствия необходимых инструментов в 99,9% случаев будет обречено на провал.


Если отсутствует какой-либо звук при подаче питания и накопитель не начинает вращать вал, то возможны следующие диагнозы: неисправна плата контроллера, неисправен коммутатор-предусилитель, неисправен БМГ.

После того, как накопитель начал вращение вала, он должен выполнить калибровку, произвести чтение микропрограммы и, проинициализировав систему трансляции, выйти в готовность. Если вместо калибровки раздаются цикличные стучащие звуки, скрежет или какие-то иные звонкие звуки, немедленно отключите накопитель. Причиной подобных явлений может быть: неисправность БМГ или коммутатора-предусилителя, неисправность микросхемы VCM&SM контроллера.

Микропрограммы некоторых накопителей производят опрос коммутатора-предусилителя до раскрутки вала двигателя, и в случаях обнаружения некорректного отклика или зашкаливающего сопротивления по какой-либо из головок производят аварийную остановку процесса начальной инициализации. К сожалению, далеко не все микропрограммы в достаточной степени контролируют исправность самого устройства и допускают попытки старта откровенно проблемного жесткого диска. Пересадки БМГ рекомендовано проводить в условиях ламинарного бокса с чистым воздушным потоком и специализированным инструментом. Кроме этого, необходимо знать, каким образом подбирать донора, чтобы выбрать его с подходящей ревизией коммутатора-предусилителя, картой головок и близкими адаптивными параметрами. Просто совпадение производителя и модели совершенно не гарантирует, что накопитель является подходящим донором. Даже если удастся самостоятельно подобрать донора и произвести процедуру пересадки, вряд ли удастся прочитать серьезный объем данных из-за сопутствующих проблем.

Какие действия можно предпринять при неисправной плате контроллера, указано в разделе «Визуальный осмотр».



Рис. 5 сильно исцарапанная поверхность пластины (множественные запилы).

Важно понимать, что с каждой попыткой включения накопителя с неисправным БМГ существуют риски дальнейшего разрушения поверхностей пластин, что может привести к полной невозможности восстановления данных.

Если никаких подозрительных звуков накопитель не издает, то после выполнения всех процедур инициализации он должен выйти в готовность. С этого момента накопитель должен быть готов к обмену данными через интерфейс, и в случае подключения к порту системной платы ПК он должен ответить на запрос паспорта со стороны BIOS. Если все в полном порядке с подключением и настройками BIOS, но диск остается невидимым для ПК, то вероятнее всего имеют место проблемы в микропрограмме накопителя, которые не позволяют ему выйти в готовность.

Если накопитель отдает некорректные паспортные данные, например только название модели и нулевую емкость, или название модели не совсем такое, как должно быть, отсутствует серийный номер, то это говорит о том, что процедуры инициализации завершились неуспешно и есть неполадки в микропрограмме. В таких случаях самостоятельно решить проблему без использования профессиональных программно-аппаратных комплексов обычно невозможно.

Отдельным исключением можно рассмотреть случай с Seagate 7200.11 (семейства Moose) с которыми некоторые проблемы можно было решить с использованием RS232-TTL адаптера и обычного терминала, но здесь нужно понимать, что без вникания в проблему микрокода есть риски существенно усугубить ситуацию.

Настоятельно не рекомендуется применять методику в отношении других семейств, так как она приведет к пересчету транслятора, который в подавляющем большинстве случаев будет некорректен и доступ к пользовательской зоне будет до первой точки расхождения. Восстановление данных в этом случае существенно усложняется.


Если в отданном накопителем паспорте все поля корректны кроме емкости, то необходимо проверить, не является ли это следствием ошибки BIOS некоторых материнских плат, которые, используя команды управления HPA, вместо отрезания маленького кусочка LBA диапазона для сохранения копии BIOS, отрезают почти 1Тб.


Рис. 6 паспортная емкость диска 1Тб после некорректной отработки BIOS мат. платы Gigabyte

Для решения этой проблемы можно использовать HDAT2 или аналогичное бесплатное диагностическое ПО, с помощью которого можно вернуть оригинальную паспортную емкость накопителя, а также отключить возможность управления HPA в DCO во избежание рецидива проблемы.

3. Подготовка к тестированию


При тестировании дисков вне профессиональных комплексов важно подготовить операционную систему заранее. Необходимо запретить автоматическое монтирование томов диска во избежание самодеятельности операционной системы.

В ОС Windows для этого с правами администратора нужно запустить diskpart и выполнить команду automount disable. Если потенциально проблемный диск ранее подключался к данной ОС, то необходимо удалить параметры монтирования из реестра командой automount scrub. Для вступления данных настроек в силу рекомендована перезагрузка.

Также необходимо приготовить диагностическое ПО. Под Windows можно использовать бесплатный PC3000 DiskAnalyzer в котором, кроме диагностической функции есть возможность создания посекторной копии. Также желательно иметь в наличии загрузочный USB flash накопитель с HDAT2.

Не обязательно для диагностики использовать только это программное обеспечение. Можно использовать любые иные аналоги, за исключением некоторого небесплатного ПО для слишком доверчивых пользователей, в рекламе которого могут звучать подобные слоганы «… unique program for regeneration of physically damaged hard disk drives. It does not hide bad sectors, it really restores them!». При очень громких заявлениях по факту подобное ПО имеет весьма скромные возможности, которые не превышают возможностей бесплатного ПО, а идеология работы с дефектами больше направлена на окончательное убийство накопителя, нежели на помощь в дальнейшем получении данных.

Если при подключенном накопителе время загрузки ОС выросло в несколько раз даже при отключенном автоматическом монтировании томов, то рекомендуется прекратить какую-либо самодеятельность, во избежание усугубления проблемы.

Существенное увеличение времени загрузки ОС при подключении потенциально проблемного жесткого диска — это весьма характерный признак того, что на поверхностях пластин накопителя имеют место дефекты поверхности. Задержки загрузки ОС возникают вследствие обращений к дефектным секторам и попыток микропрограммы выполнять процедуры оффлайн сканирования, которые ей не по зубам.

После успешной загрузки ОС зайдите в диспетчер устройств и удостоверьтесь, что ваш накопитель присутствует в списке устройств. Если его там нет, то удостоверьтесь, установлен ли драйвер для контроллера, к которому он подключен, и не выключен ли сам контроллер в списке устройств. Если с драйвером и настройкой ОС все в порядке, а накопитель так и не появился в ОС или появился и через некоторое время пропал, то обычно это говорит о широком спектре неисправностей. Наиболее вероятные — это неисправности платы контроллера, зависание микропрограммы накопителя, либо переход накопителя в аварийный режим, при котором он перестает нормально реагировать на большинство команд.

Для уточнения диагноза можно попробовать загрузить DOS и с помощью HDAT2 посмотреть параметры SMART. Если обнаружатся признаки дефектообразования (ненулевые значения по 5 и 197(С5) атрибута в полях ненормированных значений), то можно сделать вывод, что без вмешательства в настройки работы микропрограммы в домашних условиях сделать ничего не получится. Если признаков дефектообразования нет, то причина зависаний может крыться в некорректной работе платы контроллера. В этом случае можете попытаться использовать плату контроллера от накопителя донора.

4. Тестирование


Пройдя предыдущие этапы и не заметив веских причин для остановки процесса, можно приступить к дальнейшей оценке состояния накопителя. В большинство накопителей, выпущенных в этом веке, внедрена технология S.M.A.R.T., которая контролирует состояние накопителя и фиксирует различные события за время его работы. Подробнее прочитать о реализации данной технологии в HDD и какие параметры желательно контролировать при эксплуатации дисков можно в нашей статье «Что такое SMART и как его читать».

Используя диагностическое ПО, необходимо запросить параметры S.M.A.R.T.


Рис. 7 атрибуты SMART исправного жесткого диска

Важно оценить показатели по атрибутам 5 и 197(С5). Если значения в столбце RAW нулевые или показатели проблем единичные, тогда необходимо перейти к дальнейшему тестированию.


Рис. 8 атрибуты SMART диска с серьезным дефектообразованием

Если количество кандидатов в дефекты трех-четырехзначное число, то в большинстве случаев дальнейшие попытки тестирования поверхности или сканирования утилитами автоматического восстановления данных усугубят проблему вплоть до полной невозможности получения данных.

Для получения данных в таких случаях важно вмешиваться в настройки микропрограмм накопителей и отключать процедуры оффлайн сканирования, ведение журналов S.M.A.R.T., чтобы избавить накопитель от занятий фоновыми процессами, которые могут сильно сократить время жизни проблемного устройства. К сожалению, простыми путями без глубокого знания архитектуры микропрограмм накопителей и без профессиональных комплексов этого сделать не получится. Следующая задача — оценить состояние каждой из головок по отдельности и локализовать основные дефектные зоны. Линейное чтение с многократными повторами на дефектных участках в таких случаях противопоказано, как слишком опасное.

Даже если накопитель на первый взгляд работает корректно и согласно показаниям S.M.A.R.T. на нем не обнаруживается признаков дефектов, это не является гарантией того, что их действительно нет. Поэтому необходимо сделать завершающую стадию тестирования и выполнить верификацию поверхности.

Важно непрерывно контролировать процесс сканирования. При появлении посторонних звуков или обнаружении крупных зон с ошибками чтения немедленно прерывать процесс и отключить накопитель во избежание наступления необратимых последствий.


Рис. 9 график сканирования исправного диска

Если результатом сканирования диска получен монотонно-убывающий по скорости график и не зарегистрировано ошибок чтения, то накопитель можно считать исправным и переходить к следующему разделу.

В дисках с большим медиакэшем и трансляцией, отличающейся от классической (как правило в дисках с черепичной записью (SMR),) график может быть иной формы. Возможны различного рода выпады.


Рис. 10 график сканирования диска с проблемной головкой

Если при верификации диска обнаруживаются цикличные «медленные» зоны, то это характерный признак не совсем исправной головки. Не нужно ждать, когда будут обнаружены дефекты, и немедленно прекратить тестирование.

В такой ситуации не приходится ждать ничего хорошего при самостоятельных попытках извлечения данных. С высокой вероятностью накопитель не переживет попытку создания посекторной копии доступными пользователю средствами.

В случаях, когда в атрибутах S.M.A.R.T. 5 и 197(С5) были обнаружены признаки дефектообразования, или в процессе верификации были обнаружены точечные дефекты, необходимо создать копию диска

5. Посекторная копия


Если по результатам тестирования накопитель исправен и никаких проблем не обнаруживается, то можно не создавать посекторную копию и работать с оригинальным диском. Но во избежание различного рода случайностей настоятельно рекомендуется не пропускать этот шаг и далее работать только с копией.

При исправном жестком диске или диске с небольшим количеством дефектов нет особой разницы, какой инструмент вы примените, важно, чтобы он создавал полную копию. Также важно не пытаться задействовать опции некоторых программ по созданию сжатого образа, так как потом вы скорее всего сможете работать только в рамках возможностей ПО, создавшей такой образ.

В ОС Windows можно использовать следующие программы: WinHex, DMDE, PC3000 DiskAnalyzer, R-studio и другие.

В ОС Linux хватит возможностей штатной команды dd

Не все ПО бесплатное, но во многом возможностей trial/demo версии будет достаточно для создания копии накопителя.

В качестве примера используем WinHex для клонирования диска.


Рис. 11 опции в меню WinHex для клонирования диска

На вкладке «Инструменты» выбираем опцию «Дисковые инструменты» в выпавшем окне выбираем «Клонировать диск» или просто нажимаем Ctrl+D.


Рис. 12 настройки параметров клонирования

Источником выбираем диск, который необходимо клонировать.

Приемником может выступить диск аналогичного или большего объема, а также возможно клонирование в файл-образ.

Убедитесь, что на диске-приемнике достаточно свободного пространства.
В настройках копирования желательно задействовать опцию «пропускать дефекты, секторов».

Если ваш накопитель с сектором с физическим размером сектора 4096 байт, но в ОС транслируется с виртуальным размером 512 байт, то необходимо установить значение 8, чтобы избежать лишних попыток чтения проблемного сектора.

«Шаблон для замены дефектов источника» — указать удобное для поиска слово или словосочетание, которым будет заполнен сектор в копии на месте непрочитанных секторов из источника. В дальнейшем удобно будет находить поврежденные файлы.

При создании копии обязательно неотрывно контролировать процесс. При появлении посторонних звуков, зависании накопителя или обнаружении большего числа, чем было при первичном тестировании, немедленно прекратить процесс и отключить накопитель во избежание наступления необратимых последствий.

В профессиональных средствах восстановления данных, в таких как DataExtractor, значительно большие возможности по настройке сценария копирования данных, а также присутствует контроль состояния накопителя, что существенно повышает шансы на успешное извлечение при наличии грамотного специалиста.


Рис. 13 настройки реакций профессионального комплекса при проблемах чтения

Восстановление данных


6. Методы восстановления


На сегодняшний день существует масса программ автоматического восстановления данных, которые не требуют от пользователя никаких профильных знаний и подразумевают получение данных чуть ли не в один клик мышкой. Но такой подход во многих случаях не даст максимально возможного результата или он будет теряться в массе мусорных вариантов.

Для эффективной работы программы восстановления данных лучше максимально сузить область поиска. Для этого желательно указать область сканирования и тип искомой файловой системы. Такое уточнение может отбросить массу вариантов предыдущих файловых систем, а также снизит вероятность неверного интерпретирования обнаруженных метаданных файловой системы.


Рис. 14 Пример настройки R-studio для поиска метаданных нужной файловой системы

Метаданные файловой системы — это структуры, описывающие расположение файлов их имена, атрибуты, права доступа к ним, логи и т.п.


Рис. 15 Пример метаданных. Фрагмент записи MFT (Master File Table в NTFS)

Не во всех случаях программы автоматического восстановления точно рассчитывают начальную точку отсчета применительно к найденным метаданным, а также не всегда корректно отсеивают данные разных файловых систем, в связи с чем возможен ошибочный расчет расположения для всех файлов, к тому же различные мусорные интерпретации увеличивают предполагаемый объем данных, порой во много раз больше, чем емкость самого накопителя.

В профессиональных комплексах присутствуют инструменты по созданию виртуальных томов различных файловых систем с заданными вручную параметрами, а также инструменты для поиска метаданных с возможностью отсева лишних объектов вручную.

В случаях, когда нужных метаданных файловой системы уже не существует или они некорректны, необходимо применить метод поиска регулярных выражений характерных для тех или иных типов файлов.


Рис. 16 0xFF 0xD8 0xFF регулярное выражение характерное для JPG файлов

Программы автоматического восстановления, ведущие поиск таким методом в своем большинстве, обладают следующими недостатками: отсутствует структура каталогов и оригинальные имена файлов, не производится анализ структуры файлов и недостаточно контролируется целостность найденного файла, в связи с чем находится множество мусорных данных, которые невозможно использовать, для многих типов файлов не рассчитывается корректный размер.


Рис. 17 Настройки R-Studio для поиска регулярных выражений нужных вам файлов

7. Типовые случаи и рекомендуемые действия


Повреждение файловой системы

В результате сбоев компонентов ПК, некорректной работы ОС, внезапного обесточивания во время записи на диск, неисправностей жесткого диска могут оказаться поврежденными метаданные файловой системы. При многих видах повреждений ОС не сможет монтировать том с поврежденной файловой системой.


Рис. 18 поврежденные метаданные файловой системы (нераспознанная файловая система RAW)

В этих случаях достаточно эффективен метод поиска метаданных файловой системы в границах существующего раздела. При незначительных повреждениях можно получить результат, близкий к 100%. Данная рекомендация актуальна для большинства различных файловых систем.

Разумеется, существуют случаи, когда в результате сбоев оказывается испорченным большой объем метаданных текущей файловой системы. Тогда, если не отработал первый вариант, необходимо воспользоваться методом анализа регулярных выражений для поиска нужных вам файлов.

Работа специалиста отличается тем, что он оценивает характер повреждения метаданных и если они не уничтожены, а пребывают в искаженном виде, то возможны ручные коррекции в шестнадцатеричном редакторе.

Удаление файла или группы файлов.

Ошибочное удаление данных — достаточно частый случай. Последствия этого действия сильно зависят от типа файловой системы, а также в относительно новых дисках от идеологии работы микропрограммы самого устройства.

Если файлы были удалены на разделе с файловой системой NTFS, то оптимальным методом поиска будет экспресс анализ в различных утилитах, при котором быстро сканируются ключевые структуры (MFT, Index, Logfile) без полного сканирования раздела. Если нужные файловые записи и место, занимаемое этими файлами не перезаписаны иными данными, то достаточно оперативно можно получить интересующие файлы.


Рис. 19 после сканирования $MFT фиолетовым выделены записи, числящиеся удаленными

Если при быстром сканировании нужные данные не обнаружены или повреждены, то можно выполнить полное сканирование раздела, но скорее всего серьезным образом результат не изменится и кроме поиска регулярных выражений ничего другого не останется.

В арсенале специалиста доступен инструмент построения карты незанятого пространства и дальнейший анализ исключительно в этих областях, что убирает из результата восстановления существующие данные. Это существенно экономит время пользователя при дальнейшем поиске необходимых файлов во множестве безымянных данных.

Если файлы удалены на разделе с файловой системой FAT16, FAT32, то можно использовать анализ метаданных и получить некоторую часть данных с оригинальными именами. В случае SFN будет отсутствовать первый символ в имени файла, если же файл был с длинным именем, то его полное имя будет в LFN записи. В случае удаления фрагментированных файлов восстановление данных средствами программ автоматического восстановления не будет успешным, так как при удалении в FAT таблице удаляется запись о цепочке кластеров, принадлежащих файлу. Также в FAT32 в некоторых случаях кроме удаления цепочки расположения файла в обеих копиях таблицы, в директории удаляется первый символ SFN и старшие два байта в номере первого кластера, занимаемого файлом. Большинство утилит автоматического восстановления, анализирующих метаданные, не определят правильную позицию файла.

Восстановление фрагментированных файлов, как правило, достаточно сложная работа, которая весьма слабо автоматизирована. Методы автоматизации можно разрабатывать под конкретный тип структур. Чаще всего задача сводится к ручному низкопроизводительному анализу по поиску необходимых фрагментов. Пример подобной работы можно оценить в статье «Восстановление базы 1С Предприятие (DBF) после форматирования»

Если методы анализа метаданных не привели к нахождению нужных данных или нужные файлы не могут быть открыты, то остается метод поиска регулярных выражений. Возможно некоторую часть файлов удастся обнаружить.

Если файлы удалены на разделе с файловой системой HFS+, Ext 2, Ext3, Ext4, то, к сожалению, анализировать метаданные бесполезно. Кроме поиска регулярных выражений ничего другого не остается.

Удаление раздела с данными

Если в оснастке управления дисками был удален один или несколько разделов ошибочно, то для пользователя, желающего восстановить данные, будет рекомендован запуск утилит автоматического восстановления с полным сканированием всего устройства. Также желательно учитывать положение существующих разделов, чтобы исключить заведомо неверные варианты в найденном.


Рис. 20 удаленный раздел

Специалистом подобная работа выполняется относительно быстро, посредством поиска загрузочных секторов, суперблоков в ожидаемых местах. На основании найденного рассчитываются точные позиции начала разделов и их протяженность.

Также можно попытаться использовать DMDE или аналогичные утилиты, которые относительно быстро могут позволить найти признаки начала раздела, и попытаться отобразить файловую систему найденного раздела.


Рис. 21 результат быстрого поиска разделов с помощью DMDE

Отформатирован раздел с данными.

В таких случаях рекомендуемый сценарий действий сильно зависит от типа файловой системы, которая была до форматирования раздела, и какая файловая система стала использоваться после форматирования.

Например, если раздел FAT32 c кластером 8кб, был отформатирован в FAT 32 с кластером 64кб, то размер новых таблиц FAT стал в 8 раз меньше и, следовательно, обе копии новых таблиц испортили только первую копию старых таблиц FAT. В такой ситуации поиск метаданных может дать результат близкий к 100%. Если же раздел был отформатирован в FAT32 с меньшим или равным размером кластера, чем был до форматирования, то новые чистые таблицы полностью перезапишут старые и частично затронут область с пользовательскими данным. В таком случае поиск метаданных даст значительно худший результат.

Если до форматирования на разделе использовалась файловая система FAT32, а раздел был отформатирован в NTFS, то новые структуры ($MFT, $Bitmap, $Logfile), как правило, располагаются не у самого начала раздела, и высока вероятность посредством метода поиска метаданных получить большинство данных с нормальной структурой каталогов и минимальными повреждениями самих данных.

Также высокий процент восстановления будет, когда раздел с файловой системой NTFS отформатирован в FAT32. В этом случае таблицы FAT испортят данные в начале раздела и как правило не затронут ключевые структуры NTFS. Неудовлетворительный результат будет в случае с малым объемом данных, размер которых сопоставим с размерами двух копий таблиц FAT.


Но если пользователь не желает вникать в нюансы расположения метаданных различных файловых систем, то логичным шагом будет запустить утилиту автоматического восстановления данных в режиме поиска метаданных. И в случае, если получен недостаточный объем данных, применить метод поиска регулярных выражений.

Отформатирован раздел с данными и частично перезаписан иными данными.

Как часто бывает, пользователь может отформатировать раздел и начать заполнять его иными данными, а только потом спохватиться, что на старом разделе была важная информации. В таких случаях не может быть однозначной рекомендации. Все очень сильно зависит от того, как много (количественно и по объему) было записано новых данных, а также где расположились эти данные. В зависимости от условий результат может быть от 0 до близкого к 100%. Заочно это непредсказуемо.

Во многих случаях с большим перекрытием области данных имеет смысл начать с метода поиска регулярных выражений для нужных типов файлов, чтобы понять, есть ли еще признаки существования нужных данных, и в случае их обнаружения выполнить поиск метаданных файловой системы.

В условиях лаборатории восстановления данных специалист построит карту незанятого пространства и проведет поиск регулярных выражений только по этим участкам, чтобы исключить в результатах поиска наличие уже существующих данных. Также с помощью инструментов контроля целостности значительно уменьшит количество ложных распознаваний. А в некоторых задачах вроде восстановления jpg файлов (например, чьего-то домашнего фотоальбома) сможет произвести сортировку согласно информации, содержащейся в Exif тегах jpeg файлов, что позволит получить упорядоченный в хронологическом порядке результат и отсортированный по моделям камер.


Рис. 22 результат сортировки JPG файлов, найденных посредством поиска регулярных выражений

Аварийное завершение процедур изменения размера, перемещения или объединения разделов.

В случаях аварийного завершения процедур дисковых менеджеров по изменению размера раздела, его перемещению или слияния нескольких разделов предстоит разобраться, какие именно шаги были совершены и на каком этапе была остановлена операция, чтобы получить максимально возможный результат.

Учитывая сложность и количество возможных вариаций, рассмотрим только универсальный вариант для пользователя, которому нужен результат с минимальным количеством действий. Объектом для анализа нужно выбрать весь накопитель, чтобы гарантированно охватить все места расположения данных. Использовать метод поиска метаданных и копировать все варианты данных по найденным файловым системам. Высока вероятность, что в каждом из вариантов будут корректными разные наборы файлов. Поиск регулярных выражений по заданным типам файлов также важен, так как в таких случаях утраты данных возможна частичная потеря информации об именах и размещении файлов.

8. Проверка целостности восстановленных данных


Важно понимать, что отображение имен файлов в программе восстановления данных или количество найденных регулярных выражение не гарантирует, что все найденное будет годным к использованию. Поэтому не менее важный этап после восстановления данных программой автоматического восстановления — это проверка целостности самих данных.

К сожалению, универсального бесплатного средства для проверки целостности большого количества разных файлов, не существует. Но по отдельности можно отыскать бесплатное ПО, которое может контролировать отдельные типы файлов. Например, многие архиваторы позволят проверить исправность архивов, утилитой MP3Diag можно проверить исправность mp3 файлов, ImageMagick можно использовать для тестирования jpg файлов.

Главный недостаток многих бесплатных утилит проверки целостности файлов в том, что они не гарантируют полной проверки файлов. И возможны массовые ошибки.

Для многих типов файлов у пользователя не остается других вариантов, кроме как визуально оценивать целостность данных посредством поочередного открытия файлов в соответствующих приложениях.

В профессиональных комплексах присутствует набор инструментов, позволяющий частично контролировать исправность файлов, что избавляет результат восстановления данных от большого количества мусорных файлов.

Кроме отсева мусора, необходимо отловить поврежденные дефектами файлы. Если вы создавали посекторную копию с заполнением паттерном непрочитанных секторов, то вопрос нахождения поврежденных файлов легко решить посредством поиска в файлах текстовой строки «BAD!BAD!BAD!BAD!» (в нашем примере был использован заполнитель «BAD!»). После нахождения необходимо проверить степень повреждения, так как некоторые форматы файлов могут не сильно страдать от потери небольшого куска данных, а некоторые могут быть полностью негодны.

9. Частые ошибки пользователей.


Разного рода попытки «лечения» дефектов с использованием популярных диагностических утилит в надежде, что это вернет доступ к данным, являются одной из главных ошибок многих пользователей. Попытки скрыть дефекты на накопителе с поврежденным полимером на поверхности пластин обычно заканчиваются запиливанием пластин, а не получением доступа к данным. По этой причине, не зная характера дефектов на поверхности настоятельно не рекомендуется выполнять какие-либо сервисные операции над диском до получения данных. После успешного восстановления информации можно попытаться обслужить накопитель, и если вдруг повезет, то возможно еще накопитель будет пригоден для дальнейшей эксплуатации в не особо ответственных задачах.

Нередко дефекты приходятся на метаданные файловой системы. В этих случаях ОС при попытке монтировать поврежденный том надолго замирает. При подключенном проблемном накопителе время загрузки ОС может растянуться на десятки минут. Одна из самых неудачных идей по решению этой проблемы – форматировать проблемный раздел. Вновь созданные метаданные могут записаться корректно, и проблема долгой загрузки ОС будет решена, но задача восстановления данных усложнится, а качество результата восстановления может сильно пострадать.

Копирование данных, обнаруженных утилитой, на тот же раздел, с которого пытаются восстановить файлы. В этом случае обычно все заканчивается тем, вместо данных пользователь получит мусор, и следующая попытка восстановления данных уже будет с куда худшим результатом. Если действовать по инструкциям из этой статьи, то от такой ошибки вы будете застрахованы.

Не выполняется проверка целостности восстановленных данных и уничтожается содержимое оригинального накопителя вместе с его копией. В этом случае есть риск остаться с кучей папок, заполненных ошибочным результатом попытки восстановления данных без возможности получить качественный результат.

Неправильный выбор инструмента и методик восстановления данных, в связи с чем получается результат значительно хуже, чем он мог бы быть.



Надеюсь, этот комплекс мер поможет вам принять решение, допускает ли ситуация с вашим накопителем самостоятельные попытки восстановления данных и готовы ли вы выполнить этот набор относительно простых действий, перечисленных в этой статье.

Предыдущая публикация: Хождение по мукам или долгая история одной попытки восстановления данных

Комментарии (102)


  1. CrazyElf
    20.11.2019 20:20

    О, у меня где-то валяется диск, в котором, похоже, что-то случилось с основной копией файловой системы NTFS (при некорректном выключении внешнего контейнера, видимо), но я так понимаю, у неё ещё должны быть ведь копии. Нет ли какой-то простой утилиты, которая может по этим копиям увидеть сразу все файлы, чтобы потом всё скопировать куда-то?
    Утилиты типа R-Studio файлы там находят, но хотелось бы не по отдельности файлы копировать, а прямо из копии сразу всю файловую систему восстановить, если такое возможно.


    1. hddmasters Автор
      20.11.2019 20:33

      О, у меня где-то валяется диск, в котором, похоже, что-то случилось с основной копией файловой системы NTFS (при некорректном выключении внешнего контейнера, видимо), но я так понимаю, у неё ещё должны быть ведь копии.

      чтобы говорить, что именно пострадало необходимо скрупулезно проанализировать повреждения ключевых структур. В случае NTFS — ключевая структура $MFT. $MFT mirror — это копия первых 4 записей $MFT.
      Нет ли какой-то простой утилиты, которая может по этим копиям увидеть сразу все файлы, чтобы потом всё скопировать куда-то?

      обратите внимание на то, что написано в разделе про типичные случаи, в частности про повреждение файловой системы. Там даны рекомендации.
      Утилиты типа R-Studio файлы там находят, но хотелось бы не по отдельности файлы копировать, а прямо из копии сразу всю файловую систему восстановить, если такое возможно.
      такое возможно, главный инструмент шестнадцатиричный редактор и глубокое знание структур файловой системы. В большинстве случаев это нецелесообразно, так как работа специалиста и затрачиваемое время на ручные реконструкции обойдется в большинстве случаев дороже стоимости лицензии той же R-Studio.

      И настоятельно не рекомендуется искать «быстрые» варианты. Лучше озадачиться безопасностью процесса во избежания дальнейшего кусания собственных локтей.


    1. DuMOHsmol
      21.11.2019 13:48

      Как насчёт TestDisk?


      1. hddmasters Автор
        21.11.2019 13:52

        DuMOHsmol о нем уже был комментарий В случаях наличия повреждений больше, чем загрузочный сектор или первые 4 записи в NTFS он не поможет.


  1. Foxbator
    20.11.2019 20:28

    Если диск издает пищащие звуки попытки раскрутиться, и не стартует, то кроме вышеприведенных причин, хочу отметить просадку питающего напряжения, (зачастую из-за плохого контакта, окисления разъемов, переходники низкого качества, блок питания не вытягивает.) Причем такая неисправность может быть непостоянной: один раз все нормально запускается, другой раз диск не видит. Или жёсткий диск может нормально работать, но при интенсивных операциях отваливаться и вешать систему.


    1. hddmasters Автор
      20.11.2019 22:46

      Спасибо, замечание учтено.

      Удостоверьтесь в исправности вашей тестовой системы, во избежание постановки неверных диагнозов и если не обнаружилось каких-то внешних причин, препятствующих попытке старта, то подключите интерфейсный кабель и кабель питания к соответствующим разъемам и включите БП.

      В этой статье будем предполагать, что тестовый ПК совершенно исправен и рассматриваем только проблемы самих жестких дисков и способы их решения.


  1. hddmasters Автор
    20.11.2019 20:33

    del


  1. BkmzSpb
    20.11.2019 21:50

    Нередко дефекты приходятся на метаданные файловой системы. В этих случаях ОС при попытке монтировать поврежденный том надолго замирает. При подключенном проблемном накопителе время загрузки ОС может растянуться на десятки минут. Одна из самых неудачных идей по решению этой проблемы – форматировать проблемный раздел. Вновь созданные метаданные могут записаться корректно, и проблема долгой загрузки ОС будет решена, но задача восстановления данных усложнится, а качество результата восстановления может сильно пострадать.

    1-в-1 моя проблема, и я допустил именно такую ошибку. Как бороться с диском, если любые обращения к нему в лучшем случае просто отваливаются по таймауту через сколько то там минут, а в худшем — подвешивают ОС?


    1. hddmasters Автор
      20.11.2019 22:59

      С дисками в таком состоянии обычно требуются возможности профессиональных комплексов.
      1. необходимо отключить процедуры оффлайн-сканирания.
      2. оценить состояние каждой из головок.
      3. построить карту зонного распределения
      4. с малым таймуатом начать поочередное чтение минизон с пропуском оной при первом же обнаружении нестабильности.
      5. учитывая, что вы отформатировали раздел, то придется анализировать предполагаемые места расположение старых метаданных, чтобы в первую очередь попытаться добыть из проблемных зон.

      если накопитель накопитель зависает напрочь при обращении к дефектам, то в домашних условиях крайне низкая вероятность получить из него образ для дальнейшего анализа. После упорных мучений скорее получить стучащий жесткий диск с горсткой металлических опилок в гермоблоке. Хотя если вы намеренно готовы идти до конца, то можете сканом локализовывать дефекты и пытаться начитывать образ кусками и после собрать все воедино в том же WinHex.


    1. psycho-coder
      21.11.2019 12:04

      Была похожая ситуация с внешним диском. В линуксе и маке подключалось и читалось нормально, а винда уходила в себя. Скинул данные из под мака и форматнул диск.


      1. hddmasters Автор
        21.11.2019 12:10

        Иделогия работы с файловой системой отличается у разных ОС. Windows пытается прочитать побольше метаданных для дальнейшей работы и если в каком $Logfile будут дефекты то Windows «уйдет в себя». В статье указано, как избегать этого «ухода в себя».

        В ОС Windows для этого с правами администратора нужно запустить diskpart и выполнить команду automount disable. Если потенциально проблемный диск ранее подключался к данной ОС, то необходимо удалить параметры монтирования из реестра командой automount scrub. Для вступления данных настроек в силу рекомендована перезагрузка.


        1. psycho-coder
          21.11.2019 12:33

          Теперь я знаю как это отключить, за это спасибо. На тот момент было проще скопировать и отформатировать диск.


  1. 0mogol0
    21.11.2019 00:15

    Спасибо большо!
    Сохранил себе в блокнот, чтобы если что, всегда было под рукой!


  1. lohmatij
    21.11.2019 03:01
    +1

    Я для снятия образа диска люблю использовать ddrescue — это dd переписанный для копирования информации с проблемных дисков. У него много настроек, например можно после появления первых ошибок чтения, читать диск с конца, и тем самым максимально быстро скопировать 99.9% диска. А потом, к примеру, оставить оставшиеся 0.01% на ночь и довести количество «спасённых» даных до 99.99%


    Я помню у меня был диск который намертво вешал систему при загрузке и отваливался при попытке доступа при подключении через USB-адаптер. Загрузка с флешки и считывание с конца с помощью ddrecue позволили скопировать диск целиком, там что-то около 4 килобайт только не прочиталось, ни одного важного файла по факту не пострадало.


  1. hddmasters Автор
    21.11.2019 03:47
    +1

    Я для снятия образа диска люблю использовать ddrescue — это dd переписанный для копирования информации с проблемных дисков. У него много настроек, например можно после появления первых ошибок чтения, читать диск с конца, и тем самым максимально быстро скопировать 99.9% диска.

    К сожалению — это все равно средство для копирования дисков с незначительными проблемами. Диски с дефектами полученными в результате контакта какого-либо из слайдеров с поверхностью пластины как правило имеют совсем не точечные дефекты. А прыжки в конец LBA диапазона на каком-либо Seagate Grenada с дефектами и вовсе могут стать последним, что будет в его жизни.
    Я помню у меня был диск который намертво вешал систему при загрузке и отваливался при попытке доступа при подключении через USB-адаптер. Загрузка с флешки и считывание с конца с помощью ddrecue позволили скопировать диск целиком, там что-то около 4 килобайт только не прочиталось, ни одного важного файла по факту не пострадало.
    Ваш пример весьма наглядно подтверждает незначительность проблемы диска. Достаточно отключить автоматическое монтирование в ОС, чтобы подобные диски не вешали ее намертво при загрузке и далее вычитывать любым удобным средством.
    По возможности никогда не стоит читать проблемный диск через USB-SATA мост так как со многими из них можно получить дополнительных ворох проблем.


    1. KciroohS
      21.11.2019 16:28

      Какие именно проблемы могут добавить USB-SATA мосты?

      (Мне как-то удалось прочитать винчестер, который не запускался по обычному SATA, через USB-SATA от внешнего винчестера. Вероятно, сыграла какая-то другая логика в последовательности инициализации).


      1. hddmasters Автор
        21.11.2019 16:32

        При некорректно работающем накопители возможны всякие сюрпризы
        1. выдача мусора вместо данных.
        2. при попытке перезаписи некоторых метаданных возможны записи со сдвигами. (а при монтировании под Windows не так и мало пытается переписать.

        Мне как-то удалось прочитать винчестер, который не запускался по обычному SATA,

        В статье написано, что нужно отключить автоматическое монтирование и убрать все MountPoints в реестре ОС. Всего лишь две команды в diskpart. После этого ОС не будет автоматически монтировать проблемный накопитель при загрузке и соответственно не будет зависания.


  1. Mem0
    21.11.2019 04:06

    Интересно, но я бы всё-таки сначала делал бы посекторную копию с игнорированием ошибок чтения, а только потом делал бы сканирование поверхности, особенно если данные важны. Как только диск попадает в руки — делай копию.


    1. hddmasters Автор
      21.11.2019 09:13

      Интересно, но я бы всё-таки сначала делал бы посекторную копию с игнорированием ошибок чтения,

      В случае различных копиров различных доступных пользователю утилит можно совсем не сразу заметить дефекты и пропустить немало секунд. В случае некоторых видов дефектов это будет смерть диску. При верификации На графике в первую секунду можно заметить остановку сканирования и обесточить, также можно увидеть многие проблемы в виде полудохлых головок до подхода к реальным дефектам и вовремя остановиться. Заметьте, что в статье написано о том, что этот скан нужно делать не отходя от накопителя.
      особенно если данные важны. Как только диск попадает в руки — делай копию.
      Если данные очень важны, то лучше не переоценивать свои силы.
      При обнаружении признаков дефектов еще на этапе просмотра SMART лучше остановиться, особенно с современными дисками. Так как в домашних условия вряд ли вам удастся отключить оффлайн-скан, SMART, процедуры реаллокации, количество повторов чтения дефекта микропрограммой и т.п. Отсутствие всего этого вмешательства на дисках с проблемами серьезнее точечных дефектов создает дополнительные немалые риски из-за которых накопитель может слишком скоропостижно скончаться.


  1. perlestius
    21.11.2019 08:36

    В результате сбоев компонентов ПК, некорректной работы ОС, внезапного обесточивания во время записи на диск, неисправностей жесткого диска могут оказаться поврежденными метаданные файловой системы.

    Один раз получил RAW-раздел, воткнув внешний хард в дефектный USB-порт. По SMART всё было хорошо, на физическом уровне диск был здоров, пострадала именно файловая система. Тогда ни одной из платных утилит, включая пресловутую R-Studio, восстановить не смог и смирился с потерей, отформатировав раздел. А уже потом узнал про бесплатную программу TestDisk, которая не раз выручала при аналогичных проблемах, даже когда диск начинал сыпаться. Но я не спец в этом деле, поэтому было бы интересно еще узнать мнение автора статьи и других сведущих в этой области людей о TestDisk и других бесплатных аналогах. Кстати, было бы интересно увидеть в качестве продолжения статью со сравнительным обзором таких утилит, как платных, так и бесплатных


    1. hddmasters Автор
      21.11.2019 09:38
      +1

      Один раз получил RAW-раздел, воткнув внешний хард в дефектный USB-порт. По SMART всё было хорошо, на физическом уровне диск был здоров, пострадала именно файловая система. Тогда ни одной из платных утилит, включая пресловутую R-Studio, восстановить не смог и смирился с потерей, отформатировав раздел.

      В случае проблемных USB коробок можно часто получить запись мусора или сдвинутых данных (сдвиг не кратен размеру сектора) В таких случаях многие утилиты автоматического восстановления бессильны. Требуются ручные правки в шестнадцатеричном редакторе, если конечно есть что исправлять.
      восстановить не смог и смирился с потерей, отформатировав раздел.
      в любом случае метод поиска нужных регулярных выражений помог бы найти вам данные на исправном диске с убитой файловой системой.
      А уже потом узнал про бесплатную программу TestDisk, которая не раз выручала при аналогичных проблемах, даже когда диск начинал сыпаться.
      на текущий момент вы можете говорить лишь об аналогичной симптоматике проблемы. Какая именно проблема была у в вашему случае вы же так и не узнали. Перечисленные возможности TestDisk весьма скромны. Найти удаленный раздел сможет, переписать 4 записи из MFT Mirr в основную копию тоже сможет, попытаться скопировать удаленные файлы без контроля целостности на основание останков метаданных в некоторых файловых системах сможет, скопировать boot NTFS, FAT32 из копии тоже. Как-то очень скромно, чтобы рассматривать это как серьезный инструмент. Скорее утилита для быстрого получения доступа к данным в случаях «если не получилось, то бог с ним».
      Кстати, было бы интересно увидеть в качестве продолжения статью со сравнительным обзором таких утилит, как платных, так и бесплатных
      учитывая обилие различных средств восстановления со схожим функционалом и возможностями не хватит жизни все проверить на разных случаях, чтобы написать какой-то обзор. Кроме этого нужно учесть, что развитие этого всего ПО не стоит на месте и по мере тестирования на образцах актуальность описания возможностей будет устаревать.
      Лучше понимать какие методы можно применить в том или ином случае и как направить утилиту автоматического восстановления в нужное русло.


      1. minamoto
        21.11.2019 15:01
        +1

        Мне кажется, у вас особый взгляд с перекосом на особо тяжелые случаи, когда других вариантов, кроме как обратиться к профессионалам, больше нет.
        По моему опыту, ситуации порчи MFT, загрузочных секторов или случайного удаления важных файлов встречаются много чаще, чем физическое повреждение диска или сбой контроллера, поэтому для простых пользователей или выездных мастеров, занимающихся всем подряд, в т.ч. и восстановлением данных, TestDisk или, например, Recuva — это вполне подходящие инструменты.
        При этом стоит всегда помнить, что не стоит пытаться лечить перелом прикладыванием подорожника, поэтому ваша статья — просто отличная памятка/инструкция, как определить — можно ли что-то сделать своими силами, или лучше не трогать диск и сразу нести его вам, если данные критичны, или выкидывать, если данные не важны/есть резервная копия.


        1. hddmasters Автор
          21.11.2019 15:25

          При этом стоит всегда помнить, что не стоит пытаться лечить перелом прикладыванием подорожника, поэтому ваша статья — просто отличная памятка/инструкция, как определить — можно ли что-то сделать своими силами, или лучше не трогать диск и сразу нести его вам, если данные критичны, или выкидывать, если данные не важны/есть резервная копия.

          Именно для этого она и написана, чтобы многие могли уяснить, что можно пытаться делать, а когда лучше не стоит.
          По моему опыту, ситуации порчи MFT, загрузочных секторов или случайного удаления важных файлов встречаются много чаще, чем физическое повреждение диска или сбой контроллера, поэтому для простых пользователей или выездных мастеров, занимающихся всем подряд, в т.ч. и восстановлением данных, TestDisk или, например, Recuva — это вполне подходящие инструменты.

          Я не говорю, что они совсем негодные инструменты. Но стоит лишь ограничить их применимость исходя из возможного нанесения вреда. К сожалению современные диски очень уж хрупкие устройства.


  1. saege5b
    21.11.2019 09:49

    Вы бы в самом начале статьи, дали бы предупреждение, что все действия на свой страх и риск, для людей чётко понимающих что они делают с опытом подобных манипуляций.
    Знаю много случаев, когда людидемонтировали смд при помощи кисточки, или пропарывали плату отвёрткой.


    1. hddmasters Автор
      21.11.2019 09:59

      Соглашаясь на следование дальнейшим инструкциями, вы осознаете, что никто кроме вас самих не несет ответственности за возможный выход из строя накопителя и безвозвратную потерю данных. Набор мер направлен на снижение вероятности наступления неблагоприятного исхода, но не страхует от него на 100%.

      Так дано ж предупреждение. До начала диагностических мероприятий.


  1. CoolCmd
    21.11.2019 10:33

    подскажите виндовую прогу, которая по номеру сектора скажет, какому файлу он принадлежит, включая служебные файлы NTFS.


    1. hddmasters Автор
      21.11.2019 12:04

      Мне пока неизвестно бесплатное ПО или платное ПО у которого был бы такой функционал по разбору записей MFT, чтобы при вводе номера сектора увидеть название файла которому он принадлежит.

      В профессиональных комплексах можно строить цепочки расположения файлов и сортировать их по порядку расположения.
      image
      Также профессиональные комплексы позволят построить отчеты со списком не полностью прочитанных файлов и позволят скопировать данные с разделением на битые и не битые.


    1. psycho-coder
      21.11.2019 12:09

      ЕМНИП NftsExplorer так умеет. Давно им не пользовался


    1. nick758
      21.11.2019 17:02

      www.disktuna.com/finding-out-which-file-is-affected-by-a-bad-sector

      NFI на сайте Микрософта уже не было, но я где-то нашёл.


      1. CoolCmd
        23.11.2019 14:02

        спасибо, дружище! это то, что надо. по ссылкам нашел на superuser.com более полный ответ.


  1. legolegs
    21.11.2019 12:21

    Спасибо за статью. Напомнила мне пойти проверить, как делаются бекапы :)


    1. hddmasters Автор
      21.11.2019 12:25
      +1

      Спасибо за статью.

      Пожалуйста.
      Напомнила мне пойти проверить, как делаются бекапы :)

      отличная идея, которая избавит от необходимости судорожного чтения подобных статей :)


  1. CherryPah
    21.11.2019 13:42

    А кто чаще являются клиентами — физики потерявшие коллекцию фоток с отпуска или юрики у которых там базы 1Ски? Точнее кто соглашается на услуги, узнав стоимость восстановления данных.
    Как организовано хранение важной информации у юриков — ну там есть следы рейдов, или все по старинке — вся критичная инфа хранилась на одном ЖД в бухгалтерии?


    1. hddmasters Автор
      21.11.2019 14:00

      А кто чаще являются клиентами — физики потерявшие коллекцию фоток с отпуска или юрики у которых там базы 1Ски? Точнее кто соглашается на услуги, узнав стоимость восстановления данных.

      Услугами интересуются и физические и юридические лица. Ценовая политика такова, что многие услуги доступны гражданам с текущим уровнем заработных плат в нашем регионе. После бесплатной диагностики клиент принимает решение о целесообразности получения услуги исходя из ценности своей информации.
      Как организовано хранение важной информации у юриков — ну там есть следы рейдов, или все по старинке — вся критичная инфа хранилась на одном ЖД в бухгалтерии?
      хватает случаев, когда данные не хранились на одном диске, а был RAID массив. Естественно, что нашими клиентами становятся те, кто хранил важные данные в одном экземпляре.


  1. derduron
    21.11.2019 14:00

    Я как-то читал заметку (может даже тут) о бесполезности RAID-массивов. Суть сводилась к тому что если один диск отправился на небеса, то при попытке восстановления на остальные создается большая нагрузка и высок шанс гибели следующего. А если учесть вероятность кодирования данных вирусятиной, то гораздо проще иметь бэкап.


    1. hddmasters Автор
      21.11.2019 14:06

      Я как-то читал заметку (может даже тут) о бесполезности RAID-массивов. Суть сводилась к тому что если один диск отправился на небеса, то при попытке восстановления на остальные создается большая нагрузка и высок шанс гибели следующего.

      Рассуждать можно по разному.
      1. Если имеем отказоустойчивый массив например 1,5, 6 (или комбинированые 10, 50, 60) то в случае отказа одного диска у нас есть шанс скопировать информацию, а далее попытаться восстановить целостность массива посредством ребилда. И все это можно выполнить без остановки сервера. В случае отказа одиночного диска будет и остановка сервера и необходимость восстановления данных.
      2. Для обработки некоторых данных требуется быстрая дисковая система. В таких случаях RAID 0 выход. Но надежность в n раз хуже одиночного диска. (где n количество дисков в массиве)
      3. Также могут потребоваться хранилища данных более емкие, чем маскимально доступные в продаже диски RAID 0, JBOD позволят вам создать такое хранилище.

      Можно подытожить, что польза от RAID массивов есть, главное понимать для чего они и чего от них ожидать.
      А если учесть вероятность кодирования данных вирусятиной, то гораздо проще иметь бэкап.
      наличие RAID массива не освобождает системного администратора от регулярного резервного копирования. Как и не освобождает пользователя, который задумался о сохранности своих данных.


      1. derduron
        21.11.2019 14:24

        Совершенно верно. Я не имел ввиду серверные задачи и использование RAID для ускорения дисковой подсистемы. Статья же не для сисадминов.


      1. sergeyns
        21.11.2019 17:43

        В моей практике хватает случает когда админы делают бэкапы. И хранят их на том же RAIDe… И пару раз эти RAID'ы таки рассыпались…


        1. hddmasters Автор
          21.11.2019 17:55

          Да, такие случаи встречаются. Как правило на предприятиях с большой текучкой кадров, маленькой заработной платой администратора и с полным непониманием руководства на предмет какими должны быть должностные инструкции для данной единицы коллектива.


      1. lubezniy
        22.11.2019 00:27

        У меня было веселее… Был программный RAID1 на небольшом Linux-сервере из двух одинаковых SATA-дисков. Лет через 5 работы один из дисков в массиве вышел из строя. После его извлечения и загрузки системы выяснилось, что на втором диске находятся только файлы примерно двухлетней давности, новее ничего нет. Благо самое критичное в бэкапе лежало, а остальное оказалось уже неактуальным.


        1. hddmasters Автор
          22.11.2019 00:35

          Достаточно классическая ситуация. Кто-то на момент создание RAID не задумывался, как будет происходить уведомление в случае отказа одного из дисков. Порой достаточно одного небольшого подвисания из-за точечного дефекта, чтобы накопитель был исключен из массива.

          Исключение произошло. Никто не заметил этого и два года работали на одиночном диске не проверяя целостность массива.

          Итог закономерен.


    1. Am0ralist
      21.11.2019 14:07

      Эм… так ведь рейд и бекапы про разное же.


      1. derduron
        21.11.2019 14:29

        Во многих случаях RAID позволяет записывать избыточные данные и восстанавливать данные при неисправности одного из дисков (или нескольких, не суть).


        1. Am0ralist
          21.11.2019 14:31
          +1

          Но рейд — это средство обеспечения бесперебойности работы. А бекап — средство дублирования хранения данных с целью именно защиты от их потерь.
          Задачи таки — разные.


          1. derduron
            21.11.2019 14:43

            Я бы сказал что есть задача (сохранность данных), а методы реализации разные. И как у каждого метода есть плюсы и минусы. Просто один метод обеспечивает бесперебойную работу (и то, только в некоторых случаях), а второй метод обеспечивает более высокую сохранность.
            Я бы вообще не был так категоричен. RAID0 вообще снижает отказоустойчивость. RAID — это скорее метод построения дисковой подсистемы, решающий определенные задачи пользователя в зависимости от конфигурации. В данном случае я просто обратил внимание, что иногда теория немного проигрывает практике.


            1. Am0ralist
              21.11.2019 15:02

              Да, рейд 0 ещё нагляднее показывает, что рейд — не про сохранность данных) Хотя я его не видел никогда в работе. 10-ку хотя бы стараются делать.
              Но никогда админы не ставят рейды ради сохранности данных (потому что рейд не сохранит их при удалении, например, даже если не брать вирусы-шифровальщики). Они (кроме нулевого) только про бесперебойность работы в случае одного типа отказов.
              Есть ещё дисковые полки, там уже бесперебойность работы при двух типах отказов (к рейду в плюс дублирование контроллеров добавляется). Но и они тоже не про сохранность данных — только про её доступность и иногда скорость.
              В противном случае даже просто сама запись на жесткий диск можно рассматривать как средство сохранности данных. Ну а что, если не записать — то данные точно не сохранятся.
              Поэтому когда кто-то говорит про рейды с точки зрения восстановления данных — нужно сразу развеивать его иллюзии)


              1. CherryPah
                21.11.2019 17:55

                Ну почему же, рейд вполне себе про сохранность
                Сохранность данных на одном диске равна вероятности его отказа. Сохранность данных на зеркальном массиве равна произведению вероятностей отказа, т.е на порядок выше. Еретичный страйп разумеется выбивается из этой картины, поскольку наоборот снижает вероятность сохранности данных в количество_дисков_в_массиве раз. Но да, вживую я его тоже нигде не видел, особенно при нынешних реалиях когда скорость доступа к схд решается ссд и nvme дисками.
                Ну и да, есть сценарии когда бэкап вообще невозможен, а сохранность обеспечивается большим фактором репликации.

                Но в общем и целом да, рейд и бэкап выполняют разные задачи.
                image


                1. Am0ralist
                  21.11.2019 18:15

                  Ну понятно, что доступность и сохранность — пересекаются. Если случился сбой конкретного вида, то доступные данные остались, то бишь сохранились.
                  Но понятия всё же повторюсь, разные.

                  Рейд сам по себе обеспечивает доступность данных только в том состоянии, когда случился сбой. Он не обеспечивает сохранность тех данных, которые кто-то целенаправлено или нечаянно удалил за сутки до этого. Он не защищает от вируса, от модификации и прочих вариантов потери информации. Он сам по себе защищает только от отказа n-го количества дисков ту информацию, которая в тот момент на них была.
                  А вот сохранить конкретные данные помогают дополнительные меры с хранением дубликатов этих данных в разных местах с желательно разными угрозами их уничтожения. Для рейда же весь набор угроз — одинаковый для всех копий данных, а отличаются только шансов на их реализацию из-за разной надежности конкретных винтов, что прекрасно нивелируется, например, погибшим рейд-контроллером или пробоем по питанию. Ну или можно вспомнить для особо продвинутых вариантов рейдов с хешами — процедуры проверки данных при побитой памяти…

                  А так и восстановление с убитого жесткого диска информации — это тоже про сохранность данных получается)


            1. hddmasters Автор
              21.11.2019 15:30

              В данном случае я просто обратил внимание, что иногда теория немного проигрывает практике.

              Если с теоретической частью все хорошо, то она не расходится с практикой. Граждане, имеющие завышение ожиданий от RAID массивов, обычно не в полной мере понимают теорию и влияние внешних факторов.


    1. CrazyElf
      21.11.2019 14:26

      За RAID-ами надо ведь ещё и следить. На одной моей старой работе были на серверах массивы дисков в RAID5, да ещё и с hot spare. В теории то всё замечательно — когда отваливается один из дисков массива, он тут же автоматически подменяется на hot spare диск и рейд через какое-то время перестраивается. Проблема была в том, что за серверами никто толком не следил и проблемы замечались только тогда, когда было уже два дохлых диска, т.е. hot spare уже не было и в работающем массиве был один дохлый диск. В результате, после его замены, массив по-живому перестраивался несколько дней. А то и бывало, что диски на замену кончались и в любой момент рейд мог накрыться окончательно, если выбьет ещё один диск. А ещё бывали случаи, когда дох не диск, а сам рейд-контроллер, и бывало, что он уносил с собой в итоге содержимое сразу всего рейда. В общем, рейды — это весело.


      1. derduron
        21.11.2019 14:33

        С NAS аналогично. Товарищ с фирмы админов рассказывал что умирают чаще установленных в них жестких дисков.


        1. CrazyElf
          21.11.2019 19:45

          У меня дома та же фигня наблюдается, уже несколько коробок для дисков так умерло, некоторые слегка убили файловую систему диска в них под конец.


      1. SergeyMax
        21.11.2019 15:54

        В результате, после его замены, массив по-живому перестраивался несколько дней
        Время перестроения никак не зависит от того, был ли в массиве hot-spare диск, или он уже задействован. Зато оно зависит от приоритета, выставленного задаче перестроения.


      1. CherryPah
        21.11.2019 17:43

        Спейр никак не влияет на производительность массива, это всего лишь способ моментальной доставки жёсткого диска взамен вылетевшего.
        Если у меня в полке без spare вылетает диск, то рейд теряет избыточность и мне нужно ехать в ЦОД и менять его. Если spare есть то данные ребилдятся на него и массив продолжает штатно функционировать, а сдохший диск я могу поменять в удобное время при плановом визите в ЦОД.
        Вышедший из строя контроллер тоже не должен уносить с собой данные(теряется доступность, а не данные), разумеется надо иметь в зипе такой же. А при двухконтроллерных решениях даже доступность не пострадает

        PS за Бэкапами тоже следить надо. Если люди не могут заменить вышедший из строя диск в массиве, навряд ли они следят за тем выполняется ли резервное копирование в принципе. Не говоря уж о проверках разворачиваются ли потом эти бэкапы и их консистентности


        1. CrazyElf
          21.11.2019 19:48

          Да, про спару я пожалуй прогнал. А что касается контроллера — ну вот такие были тогда контроллеры. Хотя серверное оборудование, SAS диски, все дела.
          А что касается бэкапов — да, был на той работе и такой случай, когда сервер умер, а бэкап базы из zip архива не распаковался. Хотя архивы делались регулярно, но их, конечно же, никто не проверял. То ли место кончилось, то ли что произошло, но свежий архив оказался битым, восстанавливались в итоге из базы месячной давности или что-то типа того.


    1. darthslider
      21.11.2019 15:16

      Во первых рейды бывают разные, описываемый вами сценарий потенциально актуален для 5 рейда. Для hdd больше 2 ТБ действительно время ребилда слишком велико, что бы было не тревожно.

      На ссд, в целом, 5 рейд — вполне приемлемый вариант, но тут очень холиварная территория начинается.


      1. CrazyElf
        21.11.2019 19:50

        Диски тогда были не такие большие как сейчас, но и не такие быстрые. Я помню ребилд несколько дней шёл. То ли из-за того, что рейд при этом ещё и использовался всё время, то ли ещё почему — уже не помню.


        1. DistortNeo
          23.11.2019 00:16

          Диски тогда были не такие большие как сейчас, но и не такие быстрые

          Всё последнее время объём дисков с блинами рос быстрее, чем линейная скорость, так что ребилд рейдов сейчас должен длиться ещё дольше.


  1. qasta
    21.11.2019 14:41

    Кроме dd под линуксом есть ddresque — он в паре с testdisk-ом иногда помогает. Теоретически, можно даже после восстановления образа с пропущенными нечитаемыми блоками попробовать его подмонтировать. Но скорее всего не получится — тогда уже сканировать testdisk-ом по сигнатурам файлов.


  1. pisos
    21.11.2019 15:26

    Подскажите пожалуйста, есть ли утилиты для восстановления повреждённого раздела hfs+ для win/linux? fsck.hfsplus не справился. Единственное что получилось сделать — склонировать диск через ddrescue пропуская битые блоки и восстановить файлы через hfsprescue.


    1. hddmasters Автор
      21.11.2019 15:27

      в той же R-studio есть возможность анализа поврежденной HFS+ и APFS. Качество результата анализа сильно зависит от повреждений.


  1. Gl237man
    21.11.2019 15:40

    Спасибо за статью. Еще было бы хорошо иметь подобную статью по твердотельным накопителям, такими как usb-falsh и SSD.


    1. hddmasters Автор
      21.11.2019 16:10

      при наличии времени, желания возможно будет и такая статья. как всегда не буду зарекаться, что она выйдет в свет, но постараюсь рассмотреть возможность ее публикации.


      1. CrazyElf
        21.11.2019 19:52

        У ssd насколько я понимаю обычно дохнет контроллер, а он у каждой серии дисков может быть уникальный, поэтому восстановить данные потом бывает проблематично — микросхемы с памятью может и уцелели, но как именно их читать знает только конкретный контроллер. Если найдётся подходящий контроллер-донор, то можно и восстановить, но может и не найтись. Так что только бэкапы, ну или не держать на ssd ничего кроме системы.


        1. hddmasters Автор
          21.11.2019 20:03

          У ssd насколько я понимаю обычно дохнет контроллер,

          в подавляющем большинстве случаев он жив. Что с ним может статься. Посудите логически — это же обычный MCU, там ничего не изнашивается так явно, чтобы просто так умирала микросхема.
          а он у каждой серии дисков может быть уникальный, поэтому восстановить данные потом бывает проблематично — микросхемы с памятью может и уцелели, но как именно их читать знает только конкретный контроллер.

          MCU (контроллер) совершенно не уникален. Да там, есть небольшой boot ROM но его содержимое будет одинаково для огромного количества дисков. Проблемы SSD в подавляющем большинстве случаев кроются либо в NAND памяти, либо в повреждениях модулей служебки записанных в NAND.
          Если найдётся подходящий контроллер-донор, то можно и восстановить, но может и не найтись.

          в 99% случаев для мертвых SSD нет нужды искать донорский контроллер. Как правило работа в технологических режимах с поиском структур ответственных за трансляцию с дальнейшим чтением «по физике» в порядке установленном найденными и разобранными структурами. Либо для некоторых SSD применим метод распайки на микросхемы, чтение и дальнейший разбор алгоритма (можно посмотреть пример на простой USB flash, в случае SSD все будет несколько сложнее)


          1. CrazyElf
            21.11.2019 20:37

            Спасибо, успокоили! А то начитался в своё время страшилок и думал, что вот так вот всё :)


            1. hddmasters Автор
              21.11.2019 20:39

              К сожалению успокаиваться пока рано. Далеко не со всеми разновидностями контроллеров можно решать задачи восстановления данных. Слишком много исследовательской работы еще предстоит проделать. Для решения многих актуальных задач.


  1. DrunkBear
    21.11.2019 16:00

    Прочитал статью — задумался про бэкапы, прочитал комменты — задумался про NAS.
    Посмотрел ценники на то, что хочется — решил собирать Nas самому, как раз материнка с процессором и памятью дома валяется без дела.
    Да здравствует Хабр!


    1. CrazyElf
      21.11.2019 19:53

      NAS тоже не очень то панацея. Толковый бэкап — это регулярно и сразу в несколько разных мест, хоть это и муторно.


  1. Aquarius90
    21.11.2019 16:06

    Можно ли считать диск не исправным если нету проблем в работе, но есть потрескивание при его работе, особенно когда торрент выключается.?
    З.Ы винты уже довольно старые, Хитачи 2009 и 2012 года)


    1. hddmasters Автор
      21.11.2019 16:08

      Если диск справляется со требуемыми RW операциями без всяких нареканий и при тесте поверхности, seek тесте, тесте буферного ОЗУ не наблюдается никаких сбоев то определенно накопитель исправен. Некоторые накопители бывают достаточно громкими при непрерывном перемещении БМГ (что и происходит при запуске торрент-клиента).


  1. Dmitriyar
    21.11.2019 18:25
    -2

    Забыли написать ещё, что такое жёсткий диск для чего и где находится.


    1. hddmasters Автор
      21.11.2019 18:28

      Статья изначально не планировалась для аудитории, которой надо рассказать, что такое жесткий диск. Предполагается, что на данном ресурсе ее будет читать человек представляющий как выглядят основные компоненты ПК и для которого не будут чем-то сверхъестественным действия вроде установки ПО или создания загрузочной USB flash.

      И так уже планируемая коротенькая инструкция раздулась до неприличного размера.


  1. iDm1
    21.11.2019 18:41

    Мне тут попался 2.5 HDD от Seagate на 1TB, который вдруг стал определяется как 76 петабайт. Такое уже в домашних условиях не решается, возможно даже не решается в принципе.

    Это ST100LM035. Объем «безумный» показывает всё ПО, работающее с дисками. Некоторое ПО показывает даже отрицательный объем.


    1. hddmasters Автор
      21.11.2019 18:55

      Мне тут попался 2.5 HDD от Seagate на 1TB,

      Говоря о дисках хорошо бы указывать модель, тогда будет понятно о чем идет речь и какие у предмета разговора могут быть общие проблемы.(Например в случае Seagate ST1000LM035 (семейство Rosewood), ST1000LM014(kahuna), ST1000LM010 (Sentosa) и т.п. )
      вдруг стал определяется как 76 петабайт. Такое уже в домашних условиях не решается, возможно даже не решается в принципе.

      Важно понять где он стал 76PB. Если в паспорте, то необходимо анализировать его миропрограмму. Если это записался бредовый размер в GPT и оснастка Windows показывает такую емкость, вряд ли это представляет серьезную проблему.


      1. iDm1
        21.11.2019 20:02

        Да, это ST100LM035. Проблемы с определение его объема и у TestDisk, и у других программ для управления жесткими дисками.


        1. hddmasters Автор
          21.11.2019 20:05

          Можете открыть PC3000 DiskAnalyzer и показать паспорт?


          1. iDm1
            22.11.2019 12:20

            Не вышло. Объем в петабайтах отображается через переходник SATA — USB3.0, вполне вероятно это его реакция на неисправность данного HDD и в целом не имеет никакого отношения к реальному положению дел.

            Чтобы работать напрямую с диском и считать паспорт при помощи PC3000 DiskAnalyzer я подключил жесткий к настоящему SATA интерфейсу, но в таком случае из под Windows он виден только в оснастке «Управление дисками», причем как неизвестный неинициализированный диск.

            Другое ПО для управления дисками в Windows, включая PC3000 DiskAnalyzer, его таким образом не видит вовсе, его просто нет в списке. В диспетчере устройств он отображается, но вместо его названия он указан как «Неизвестное устройство».

            В свойствах диспетчера устройств объём указан 0. Двигатель диска работает, ощущается вращение, никаких посторонних звуков нет, но нет и звуков перемещения головки. Но в начале, во время запуска системы, головка перемещается субъективно абсолютно нормально, без каких-либо зацикливаний, ничем не выделяясь среди других, подключаемых таким же образом 2.5 дисков.


            1. hddmasters Автор
              22.11.2019 12:43

              Разумеется заочный диагноз не претендует на точность. Но из вашего описания можно предположить проявления весьма характерной проблемы этого семейства.

              В этих дисках нередко оказывается нечитабельной таблица MediaCache. Симптоматика такова, что накопитель может выйти в готовность и даже отдать сразу паспорт, но на попытки чтения ответит «ABR» (отбоем команды).

              В этих случаях, как правило требуется вмешательство в микрокод. Вычитывание обеих копий таблиц и дальнейшая реконструкция. После чего накопитель можно будет вывести в готовность и осторожно приступить к вычитыванию дефектов.

              Просто сбросить таблицу и очистить медиакеш не стоит. Так как он работает по принципу: сначала запись в медиакеш, а потом уже накопитель запишет это в основную юзерзону, когда это заблагорассудится сделать его микропрограмме.

              В домашних условиях этого сделать не получится.


  1. volovetckoliya
    21.11.2019 19:00

    Ну это статья скорее для системщиков, а так у заурядного узера хард работает без нареканий.


  1. AlexanderS
    21.11.2019 19:58

    Некоторые проблемы можно снять сразу после покупки. Например я, после покупки жесткого диска совершаю несколько нехитрых действий:
    1) неоднократное включение и «слушание» шума раскрутки диска на предмет плавно нарастающего, а затем «ровного» гула
    2) просмотр смарта и тест поверхности викторией с анализом статистики распределения блоков по откликам и «ровности» графика скорости чтения
    3) полумесячная\месячная работа (неважно под/без нагрузки)
    3) снятие контролера с зачисткой контактов (да — это лишение гарантии)

    Один раз мне не понравилось то, как диск раскручивался. Он работал. Но исходя из моего опыта (скажем так, сотня дисков «отслушана») было что-то «не то». Диск был оставлен на неделю в ПК, через три дня успешно загнулся (при включении раскручивался с таким звуком и вибрацией, словно там диски неотбалансированные были) и я его обменял по гарантии. Другой раз диск у меня сдох в процессе теста викторией. Видать не выдержал нагрузки. Тоже заменили.
    Ну а зачистка контактов ластиком — я не знаю из чего сейчас эти контакты делают, но не раз видел неслабые окислы прям из магазина! У древнего 40гигового сигейта таких проблем до сих пор не наблюдается! Поэтому зачистка контактов у меня идёт как профилактика раз в 3-4 года.


  1. maedv
    21.11.2019 21:56

    А что за программа чтения SMART на скриншотах, она freeware?


    1. hddmasters Автор
      21.11.2019 22:01
      +1

      PC3000 DiskAnalyzer. Да, она бесплатна.


      1. maedv
        21.11.2019 22:15

        Благодарю


  1. DerRotBaron
    21.11.2019 22:51

    По поводу использования Windows для восстановления данных: ValdikSS описывал ситуацию, в которой Windows исправляла намеренно некорректные MBR DiskSignature, что ломало работу защиты. https://habr.com/ru/post/304014/


    Делает ли Windows это или что-то подобное при отключенном автомонтировании?


    1. hddmasters Автор
      21.11.2019 23:43

      Отключение автоматического монтирование подразумевает, что содержимое MBR или GPT все равно будет прочитано. Не будут читаться лишь метаданные файловых систем.

      Бегло глянул в статью. Как бы на дисках с GPT и с наличием защитной MBR по 0x1B8 обычно нули и windows не порывается заниматься самодеятельностью.


      Что касается Acronis то его клонирование дисков часто не является честной посекторной копией. И номер в 0x1B8 в копии зачастую другой. В старых windows это не приводило к отказу загрузки. Для Windows Vista и выше как правило bootmgr вылетает с ошибкой «Status: 0xc000000e Info: The boot selection failed because reqired device is inaccessible»


      1. DerRotBaron
        23.11.2019 20:22

        Попробовал в Windows7, происходит именно так, как описывал ValdikSS:


        • Выключил автомонтирование
        • В линуксовом fdisk создал MBR с одним пустым разделом и занулил идентификатор MBR (x->i->0)
        • Загрузил и выключил Windows

        Вместо нуля оказался записан новый идентификатор.
        Интересно, как от такого поведения избавиться, сколько ещё подобной самодеятельности делает Windows и не может это повредить и без того дохлому диску?


  1. Gellon
    21.11.2019 23:17

    Спасибо за интересную статью!
    Подскажите пожалуйста, какая из перечисленных программ способна корректно открыть RAW образ диска, если к нему прилагается лог с поврежденными секторами (большинство которых приходится на $MFT). Лог создан программой ddrescue и при необходимости его можно легко изменить под другой формат.


    1. hddmasters Автор
      21.11.2019 23:24

      Если в boot sector NTFS корректная информация, то возможны 2 сценария:
      1. Если живы первые записи MFT или цела MFT mirr то будет достаточно просто сканировать все записи MFT и не сканировать весь раздел, чтобы увидеть возможное древо каталогов.
      2. Если первые записи MFT убиты и копия MFT mirr тоже, то потребуется полный скан раздела, чтобы найти все фрагменты MFT и после уже разбирать, что относится к актуальным записям.

      можете попробовать R-Studio, DMDE в первом случае просто раскрыть раздел, а во втором с полным сканом.
      Для всего этого ПО лог от ddrescue не будет полезен. Полезным он будет лишь на дальнейшем анализе повреждений файлов.


      1. Gellon
        22.11.2019 00:42

        К сожалению, физический диск недоступен, есть только вышеупомянутый образ. MBR и boot sector раздела целый. R-studio видит часть ФС (10-20%), но важные каталоги или отсутствуют, или пустые. Поскольку битые секторы в образе заполнены нолями, то в логах R-Studio постоянно встречаются сообщения о некорректных данных в $MFT. Проблема как раз в том, как заставить R-studio (или другую программу) интерпретировать часть секторов, как физически недоступные.

        А найти поврежденные файлы среди восстановленных не составило труда. Достаточно было на место поврежденных секторов RAW образа записать произвольный паттерн, после чего обнаружить его среди восстановленных файлов (предварительно убедившись, что этого паттерна нет в образе).


        1. hddmasters Автор
          22.11.2019 00:46

          Проблема как раз в том, как заставить R-studio (или другую программу) интерпретировать часть секторов, как физически недоступные.


          а смысл? Ведь если в местах пропусков в вашем образе нули или какой-то паттерн, но не куски чужой MFT, то на качество сканирования не повлияет. Если нужные данные не находятся при анализе метаданных, то кроме поиска регулярных выражений по нужным типам файлов вам ничего не светит.


          1. Gellon
            22.11.2019 01:17

            Благодарю!


  1. hddmasters Автор
    22.11.2019 00:45

    del


  1. KorDen32
    22.11.2019 21:30

    Спасибо за статью!
    Рекомендую добавить расшифровки и краткие пояснения специфичных терминов/аббревиатур (БМГ, коммутатор-предусилитель, парковочная рампа...) при первом их упоминании. Или ссылку на статью, если уже где-то описывали.

    Тем, кто читает ваши статьи не в первый раз, все эти термины уже понятны, а вот остальным требуется пояснение. Как вариант — просто картинку разобранного HDD и стрелочки-подписи. Думаю, большинство хабровчан представляет HDD в разобранном виде, но вот терминология явно будет нова, или могуть быть ошибочные представления.

    Еще моменты:
    — 3.3v на SATA. В новых энтерпрайзных дисках вывернули наизнанку — наличие 3.3v стопорит накопитель. Пока в массе выглядит как «купил HDD, а он не включается», но возможны и случаи «HDD работал, а переставил — и не запускается»

    — процесс восстановления/копирования образа в принципе гораздо лучше делать в Linux (если конечно консоль и dd не пугает, хоть и с гуглежкой), открыв в соседнем окне dmesg -w. Там, где винда зависает наглухо, в лине копирование может вполне успешно продолжаться после таймаута и/или пропуска сбойного места, с возможными подробностями в dmesg. Еще спецэффекты от сбоев сильно зависят от контроллера SATA.


    1. hddmasters Автор
      22.11.2019 22:18

      — процесс восстановления/копирования образа в принципе гораздо лучше делать в Linux (если конечно консоль и dd не пугает, хоть и с гуглежкой), открыв в соседнем окне dmesg -w. Там, где винда зависает наглухо, в лине копирование может вполне успешно продолжаться после таймаута и/или пропуска сбойного места, с возможными подробностями в dmesg. Еще спецэффекты от сбоев сильно зависят от контроллера SATA

      Весьма спорно, что это лучше. Если диск зависает, то лучше его линейно не читать во избежание получения фактурных пластин с кучей металлической пыли. Кроме этого главная проблема зависаний Windows в попытке монтировать раздел на проблемном накопителе. После отключения этой опции Windows ведет себя более адекватно.
      Рекомендую добавить расшифровки и краткие пояснения специфичных терминов/аббревиатур (БМГ, коммутатор-предусилитель, парковочная рампа...) при первом их упоминании. Или ссылку на статью, если уже где-то описывали.
      добавлю расшифровку аббревиатур в ближайшее свободное время. мое упущение.


  1. sumanai
    22.11.2019 23:30

    А если диск внезапно немножечко подрос в объёме? На скрине правильный объём всего диска у первого раздела, второй это кривые руки меня.

    Заголовок спойлера


    1. sumanai
      22.11.2019 23:49

      Кажись зря я его подключил, диск посыпался. Ну да ладно, оставлю на случай, когда стану миллионером и захочу понастальгировать на старые проекты.

      Заголовок спойлера


      1. hddmasters Автор
        23.11.2019 02:09

        А что вы имеете в виду под посыпался?


        1. sumanai
          23.11.2019 03:03

          Первый и 195 параметры в потолок пошли.


    1. hddmasters Автор
      23.11.2019 02:03

      del


    1. hddmasters Автор
      23.11.2019 02:06

      чаще такие проблемы в оснастке дисков Windows возникают из-за ошибочных записей в таблице разделов, но не всегда причина в этом


      1. sumanai
        23.11.2019 03:09

        В данном случае даже Disc Analizer показывает неверную ёмкость (скрин выше). Утилита и винда считают, что у диска 4 284 936 864 сектора, а паспортная ёмкость около 3,907,029,168 секторов.