Рис. 1 HDD Quantum Fireball Plus KA 9,1Гб
Первым делом пришлось потрудиться с поиском в донорском архиве столь древнего брата-близнеца этого накопителя с исправной платой контроллера. Когда этот квест был пройден, то стало возможным произвести развернутые диагностические мероприятия. Проверив обмотки двигателя на короткое замыкание и убедившись в его отсутствии, устанавливаем плату с накопителя – донора на накопитель – пациент. Подаем питание и слышим нормальный звук раскрутки вала, прохождение калибровочного теста с загрузкой микропрограммы, и через несколько секунд накопитель по регистрам рапортует о готовности реагировать на команды со стороны интерфейса.
Рис. 2 Индикаторы DRD DSC означают готовность к принятию команд.
Резервируем все копии модулей микропрограммы. Выполняем проверку целостности модулей микропрограммы. С чтением модулей каких-либо проблем не возникает, но анализ отчетов показывает, что есть некоторые странности.
Рис. 3. Таблица зон.
Обращаем внимание на таблицу зонного распределения, замечаем, что количество цилиндров равно 13845.
Рис. 4 P-list (primary list – список дефектов, внесенных в процессе производственного цикла).
Обращаем внимание на слишком малое количество дефектов и их локализацию. Просматриваем модуль лог скрытия заводских дефектов (60h) и обнаруживаем, что он пуст и не содержит ни одной записи. На основании этого можем предполагать, что в каком-то из предыдущих сервисных центров, возможно, проделывались некие манипуляции со служебной зоной накопителя, и случайно или намеренно был записан чужой модуль, либо подчищен список дефектов в оригинальном. Для проверки этого предположения создаем задачу в Data Extractor с включенными опциями «создание посекторной копии» и «создание виртуального транслятора».
Рис. 5 Параметры задачи.
Создав задачу, просматриваем записи в таблице разделов в нулевом секторе (LBA 0)
Рис. 6 Главная загрузочная запись и таблица разделов.
По смещению 0x1BE находится единственная запись (16 байт). Тип файловой системы на разделе — NTFS, смещение до начала 0x3F (63) сектора, размер раздела 0x011309A3 (18 024 867) секторов.
В редакторе сектора открываем LBA 63.
Рис. 7 Загрузочный сектор NTFS
По информации в загрузочном секторе NTFS раздела можно сказать следующее: размер сектора, принятый в томе, 512 байт (по смещению 0x0B записано слово 0x0200 (512)), количество секторов в кластере равно 8 (по смещению 0x0D записан байт 0x08), размер кластера равен 512х8=4096 байт, первая запись MFT расположена по смещению 6 291 519 секторов от начала диска (по смещению 0x30 учетверенное слово 0x00 00 00 00 00 0C 00 00 (786 432) номер первого кластера MFT. Номер сектора вычисляется по формуле: Номер кластера * количество секторов в кластере + смещение до начала раздела 786 432* 8+63= 6 291 519).
Переходим к сектору 6 291 519.
Рис. 8
Но данные содержащиеся в этом секторе совершенно не похожи на запись MFT. Это хоть и указывает на возможную неправильную трансляцию из-за некорректного дефект-листа, но не доказывает этот факт. Для дальнейшей проверки проведем чтение диска по 10 000 секторов в обоих направлениях относительно 6 291 519 сектора. И после проведем поиск регулярных выражений в прочитанном.
Рис. 9 Первая запись MFT
В секторе 6 291 551 обнаруживаем первую запись MFT. Ее положение от расчетного отличается на 32 сектора, и далее непрерывно следует группа из 16 записей (от 0 до 15). Впишем в таблицу сдвигов положение сектора 6 291 519 сдвинуть вперед на 32 сектора.
Рис. 10
Положение записи №16 должно быть по смещению 12 551 431, но там обнаруживаем нули, вместо записи MFT. Проведем аналогичный поиск в окрестностях.
Рис. 11 Запись MFT 0x00000011 (17)
Обнаруживается крупный фрагмент MFT, начинающийся с записи под номером 17 протяженностью 53 646 записей) со сдвигом в 17 секторов. Для позиции 12 155 431 поставим сдвиг +17 секторов в таблицу сдвигов.
Определив положение фрагментов MFT в пространстве можем сделать вывод, что это не похоже на случайный сбой и запись фрагментов MFT по некорректным смещениям. Версию с некорректным транслятором можно считать подтвержденной.
Для дальнейшей локализации точек сдвигов установим максимально возможное смещение. Для этого определим, насколько сдвинут конечный маркер NTFS раздела (копия загрузочного сектора). На рисунке 7 по смещению 0x28 четверное слово — это значение размера раздела 0x00 00 00 00 01 13 09 A2 (18 024 866) секторов. Прибавим смещение самого раздела от начала диска к его длине получим смещение конечного маркера NTFS 18 024 866 + 63= 18 024 929. Ожидаемо там не оказалось нужной копии загрузочного сектора. При поиске в окрестностях он был обнаружен с нарастающим сдвигом в +12 секторов по отношению к последнему фрагменту MFT.
Рис. 12 Копия загрузочного сектора NTFS
Другую копию загрузочного сектора по смещению 18 041 006 игнорируем, так как она не имеет отношения к нашему разделу. На основании предыдущих мероприятий установлено, что внутри раздела имеются вкрапления из «всплывших» в трансляции 61 сектора, которые раздвинули данные.
Выполняем полное чтение накопителя, результатом которого остается 34 непрочитанных сектора. К сожалению, достоверно гарантировать, что все они являются дефектами, удаленными из P-list невозможно, но при дальнейшем анализе желательно учитывать их положение, так как в некоторых случаях можно будет достоверно определять точки сдвига с точностью до сектора, а не до файла.
Рис. 13 Статистика чтения диска.
Следующей нашей задачей будет установить ориентировочные места сдвигов (с точностью до файла, в котором они возникли). Для этого проведем сканирование всех записей MFT и построим цепочки расположения файлов (фрагментов файлов).
Рис. 14 Цепочки расположения файлов, либо их фрагментов.
Далее, двигаясь от файла к файлу, ищем, с какого момента вместо ожидаемого заголовка файла будут иные данные, а нужный заголовок обнаружится с неким положительным сдвигом. И по мере уточнения точек сдвигов заполняем таблицу. Результатом ее заполнения будет свыше 99% файлов без повреждений.
Рис. 15 Список пользовательских файлов (от клиента получено согласие на публикацию этого скриншота)
Для установления точечных сдвигов в отдельных файлах можно провести дополнительные работы и при знании структуры файла найти вкрапления данных, не относящихся к нему. Но в данной задаче это не было экономически целесообразно.
P.S. Хотелось бы также обратиться к коллегам, в чьих руках этот диск побывал ранее. Пожалуйста, будьте внимательны при работе с микропрограммой устройств и резервируйте служебные данные прежде, чем что-то изменить, а также не допускайте намеренного усугубления проблемы, если вам не удалось договориться с клиентом о выполнении работ.
Предыдущая публикация: Экономия на спичках или восстановление данных из скрежещущего HDD Seagate ST3000NC002-1DY166
Комментарии (100)
GeBoN
09.11.2019 18:18+1Сколько обошлась работа?
hddmasters Автор
09.11.2019 18:59Конкретно цена этой работы коммерческая тайна. И не одобрено клиентом ее озвучивание.
Могу лишь сказать что стоимость работ с проблемами в трансляции начинается от суммы эквивалентной 150 долларов США (от 9 500 российских рублей). Стоимость сильно зависит от множества технических нюансов и набора иных проблем.GeBoN
09.11.2019 19:12Могу лишь сказать что стоимость работ с проблемами в трансляции начинается от суммы эквивалентной 150 долларов США (от 9 500 российских рублей).
за восстановление дорогих сердцу фотографий вполне приемлемая сумма.
nerudo
09.11.2019 20:09Стоимости ботинок клиента?
hddmasters Автор
09.11.2019 20:18+4Можно иронизировать по поводу озвучиваемых сумм за восстановление данных, но в профильной компании цена все же не зависит от внешнего вида клиента.
Areso
09.11.2019 21:01Жаль, что почти нигде не работает, иначе я бы прилично экономил на услугах с плавающим ценником :)
nerudo
09.11.2019 21:11Надо не забывать еще цепь золотую снимать!
hddmasters Автор
09.11.2019 21:31+3Если уже говорить о самых платежеспособных клиентах, то как правило это юридические лица. Системные администраторы, как правило не выделяются какой-то внешней атрибутикой. Посему оценивать по одежке — это заведомо неверный подход, который вряд ли увеличит прибыль компании.
Chosen_One
09.11.2019 23:09Ну не каждый решиться братка обсчитать )
Ok_Lenar
10.11.2019 11:11Обсчитать и назвать цену сообразную толщине его понтов это совершенно разные вещи. Обсчитывает продавщица овощей на рынке, мастер называет стоимость своих услуг исходя из своих личных мотивов.
nixtonixto
09.11.2019 18:43А чем ваша работа отличается от специализированных программ типа GetDataBack, которым можно подсунуть диск даже после быстрого форматирования, они автоматически просканируют все секторы и автоматически восстановят структуру данных? Как я понял, диск системой виден и на запросы отвечает.
hddmasters Автор
09.11.2019 18:54Если кратко, то тем, что runtime GetDataBack в принципе неспособна решить данный комплекс задач.
Быстрое форматирование — это одна из примитивнейших задач, которая обычно легко решается с использованием средств автоматического восстановления. Алгоритм работы GetDataBack сводится к поиску метаданных файловых систем и определению стартовой точки отсчета относительно которой могут быть расположены данные. Никаких средств контроля целостности данных там нет, также как и алгоритма, который мог бы учесть нарастающие точечные сдвиги. При отработке на образе этой задачи GetDataBack мы бы получили может быть и корректное древо каталогов, но позиции подавляющего большинства файлов были бы рассчитаны неверно.
Также в стартовых условиях указана неисправная PCB (плата контроллера) с множественными попытками ремонта. И только после нахождения донорской исправной платы стало возможным работать с накопителем. Кроме этого некоторые дефекты этого накопителя при попытке чтения приводили к зависанию накопителя, что делает невозможным нормальную работу алгоритмов программ автоматического восстановления данных.
hddmasters Автор
11.11.2019 16:48В дополнение к вашему вопросу установил и провел тестирование двух популярных программ автоматического восстановления данных, чтобы вы и многие другие могли убедиться воочию, что они не предназначенных для решения задача вроде описанной в данной статье.
Берем образ накопителя полученный после его вычитки и запускаем полной сканирование всего образа.
1. Используем версию R-Studio 8.10
Древо каталогов ей получить удалось, но открыв предпросмотр JPG файла видим там нечто совсем не похожее на служебный заголовок jpeg.
2. Используем GetDataBack for NTFS 4.33
Древо каталогов получено неверное, к просматриваемой папке присвоены совсем не те объекты, что там должны быть. Предпросмотр JPG файла также показывает некие данные, не похожие на служебный заголовок jpeg.
3. Используем Data Extractor и уточняем места сдвигов в трансляции
после уточнения точек сдвигов получаем корректные указатели на начала файлов. На примере виден правильный служебный заголовок jpeg
Полагаю многим очевидно, что средства автоматического восстановления данных хороши лишь для некоторого круга задач.
Miller777
12.11.2019 17:47Тем, что GetDataBack не поможет, если винт не определяется: не крутится шпиндель, сгорела плата, и т.д. Или с головками что-то…
Не все задачи можно решить только софтово. Иногда надо задействовать руки и вскрывать гермозону.
decomeron
09.11.2019 19:17он решился еще раз отнести его куда-нибудь…
Куда-нибудь это куда? Если нельзя сказать адрес, то хотя-бы, территориальноhddmasters Автор
09.11.2019 19:21Республика Беларусь. г. Минск hddmasters.by/contacts.html
Вроде бы вся эта информация должна быть доступна в моем профиле.decomeron
09.11.2019 23:01+1Спасибо, далековато будет. Придется тут учиться
hddmasters Автор
09.11.2019 23:17+1Если Вы ищете организацию оказывающую услуги восстановления, то в случае СНГ не так и дорого прибегнуть к услугам транспортных компаний, которые выполнят доставку накопителя. Главное определитесь какая из компаний у Вас вызывает больше доверия.
ky0
09.11.2019 20:41Вы бы хоть название используемых программ озвучили, что ли…
А то получается — заменяем управляющую плату, открываем мегапрогу1, мегапрогу2, хекс-редактор, восстанавливалку файлов — и вуаля!hddmasters Автор
09.11.2019 21:28В тексте указан Data Extractor компонент программно-аппаратных комплексов PC3000Express(UDMA, SAS). Используя его инструменты изыскиваем решение для задачи.
kunix
09.11.2019 22:17Есть HDD с кучей файлов, пошифрованных Dharma, расширение .wiki.
Шифровальщик шифрует поверх оригинала, поэтому никаких удаленных файлов, которые можно восстановить, нет.
Насколько реально прочитать содержимое пошифрованного файла до шифрования?
Как я понимаю задачу: вот есть сектор диска, его перезаписали мусором один раз, нужно прочитать предыдущее содержимое.
Я так понимаю, это фантастика?..hddmasters Автор
09.11.2019 22:22+2Из любого сектора можно прочитать только его текущее содержимое. Каких-либо старых версий содержимого сектора даже в достаточно старых накопителях вам прочитать не удастся. Эксперименты в области магнитно-силовой микроскопии показываю тщетность подобных попыток digital-forensics.sans.org/blog/2009/01/15/overwriting-hard-drive-data
kunix
09.11.2019 22:25Ясно, спасибо.
hddmasters Автор
09.11.2019 22:32+1Есть небольшая оговорка, что справедливо это для жестких дисков. В случае накопителей с NAND памятью почти тоже справедливо, но есть нюансы. Например неочищенные блоки исключенные из трансляции в которых могут содержаться небольшие обрывки каких-то пользовательских данных. Доступными они будут, только после получения дампов их микросхем NAND памяти.
kunix
09.11.2019 22:36Не, там все ценное на HDD.
SSD, если я верно понимаю, вообще не обязан перезаписывать тот же физический блок при записи логического.
Он может ремапнуть его куда-то далеко в соответствии со своими алгоритмами wear leveling.
Отсюда особенности при использовании всяких трукриптов.
lll000lll
10.11.2019 15:16На некоторых моделях можно считать предыдущее содержимое с края сектора. Головка не позиционируется всегда на одно и то же место, поэтому из-под новых записей с краёв могут «торчать» старые. Тут зависит от конструкции головки. Например, она может быть специально устроена таким образом, чтобы писать шум по краям полосы данных. И если полосы шума достаточно широкие — следов от предыдущих записей не остаётся.
Считать края трека можно сдвигая головку относительно центра с помощью соответствующих технокомманд.
Но практической ценности всё это не представляет. Если и удастся считать какие-то обрывочные куски, будет непонятно, что именно это за куски, от чего именно они остались и как их интерпретировать.hddmasters Автор
10.11.2019 15:31Уже несколько десятков лет со стороны интерфейса невозможно управлять сервоприводом(со времен анонсирования IDE в 1986 году). Но даже если допустить такую возможность, то другим камнем преткновения будут принципы кодирования данных, которые весьма продвинулись со времен RLL/ARLL.
Ну и как уже приводилась в комментариях ссылка на достаточно давние исследования в области магнитно-силовой микроскопии, материалы в которой достаточно четко поясняют бесполезность подобных затей.lll000lll
10.11.2019 16:32На всякий случай, для людей которые «не в теме» сообщаю, что отсутствие подобных знаний у специалиста не влияет на его компетентность в восстановлении данных. Они просто не нужны для практических задач.
Уже несколько десятков лет со стороны интерфейса невозможно управлять сервоприводом
Для некоторых семейств известна технокоманда, позволяющая задать смещение головки от центра дорожки.
Когда я пишу, что это возможно, я имею в виду конкретные разработки конкретного специалиста, результаты которых видел лично. Если вам интересно, напишите мне в личку, и я сообщу о ком и о чём речь.
Секрета тут нет, но без разрешения разработчика не хотел бы об этом в публичном пространстве писать.
Ну и как уже приводилась в комментариях ссылка на достаточно давние исследования
Прошу извинить, если невнимательно прочитал, но там вроде про остаточную намагниченность, а не про края дорожек. Разве нет?hddmasters Автор
10.11.2019 21:45Прошу извинить, если невнимательно прочитал, но там вроде про остаточную намагниченность, а не про края дорожек. Разве нет?
так то да, но и рассматривается возможность отыскать признаки каких-либо иных данных на треке и в окрестности (что есть «края»)
Для некоторых семейств известна технокоманда, позволяющая задать смещение головки от центра дорожки.
По большому счету корректируя некоторые адаптивные параметры можно добиться в любом накопителе неточного попадания на трек (но для этого нужно проделать множество работ по реверсу-инжинирингу, чтобы в полной мере понять значение всех параметров), которое в итоге превратится сначала в нестабильное чтение (UNC ошибки), а при больших отклонениях DAM/sync error. При очень больших отклонениях получим громкий стук. Кроме этого нужно отметить, что в современных дисках данные не записываются в явном виде. Сегодня проблематично в каком-либо из дисков получить осмысленные данные из буфера (пусть даже с битовыми ошибками), если чтение завершилось даже банальной UNC ошибкой.
Когда я пишу, что это возможно, я имею в виду конкретные разработки конкретного специалиста, результаты которых видел лично. Если вам интересно, напишите мне в личку, и я сообщу о ком и о чём речь.
Было бы любопытно узнать, кто именно работает в данном направлении. И точно ли вы или исследователь не ошиблись.
Секрета тут нет, но без разрешения разработчика не хотел бы об этом в публичном пространстве писать.
Насколько мне известно, сегодня много кто пытается исследовать возможности чтения в современных дисках с разрушениями в трансляциии (речь идет о некоторых SMR дисках, где транслятор становится похожим на транслятор ssd, а также о возможностях чтения различных медиа кешей (особенно работающих по принципу write back) Именно в таких дисках есть шансы прочесть что-то старе и формально не существующее и дальше гадать, где оно могло быть и к чему относилось. Но пока что работы в этом направлении являются огромным и почти непаханным полем.hddmasters Автор
11.11.2019 14:50На всякий случай, для людей которые «не в теме» сообщаю, что отсутствие подобных знаний у специалиста не влияет на его компетентность в восстановлении данных. Они просто не нужны для практических задач.
исходя из уточнения в личных, мне пока стоит признать, что в данном вопросе у меня недостаточно информации для какого-либо дальнейшего продолжения дискуссии.
Naves
09.11.2019 23:35Был опыт восстановления перезаписанного поверх текстового файла на ntfs. Суть была в том, что новое содержимое было в новом секторе диска, а старое содержимое нашлось поиском по сигнатуре по всем секторам раздела. Примерно таким способом несколько раз находил предыдущие версии файлов в разной степени повреждения.
Ещё было несколько особенностей. Если файл удалить через shift+delete, то он прекрасно находится любым undelete средством в нужном каталоге. Если файл удалить через корзину с ее очисткой, то пропадал бесследно, даже поиск по сигнатуре не находил ничего.hddmasters Автор
10.11.2019 00:36Перезаписанное поверх — это перезапись именно в то же место. В вашем случае все же запись состоялась в другом месте.
Удаление через корзину не особо отличается от простого удаления, кроме того, что принадлежность объекта сначала приписывается корзине. Не нашлось вероятно потому, что уже успело перезаписаться иными данными.Naves
10.11.2019 10:13Я всего лишь хочу сказать, что в контексте изначального вопроса перезапись файла не всегда означает перезапись одного и того же сектора диска, и что вероятность восстановить файл в том или ином виде остаётся. И вообще ещё есть файловые системы с copyOnWrite.
hddmasters Автор
10.11.2019 10:19Куда именно запишется новый файл — это уже решение компонентов ОС работающих с файловой системой. И разумеется не во всех случаях файл будет расположен на том же самом месте. Кроме этого есть еще масса факторов из-за которых одни и те же файлы могут оказаться в нескольких местах на диске (например различные дефрагментаторы-оптимизаторы расположения файлов).
Изначально говоря о перезаписи, так рассматривался вариант именно возможности прочитать какое-то иное содержимое из конкретного сектора кроме того, что в нем записано на данный момент. И на него давался ответ о невозможности такого рода восстановления данных.
Разумеется, что в случае различных шифровальщиков кроме прямых попыток расшифровки зачастую целесообразно провести поиск регулярных выражений характерный для нужных пользователю файлов. В некоторых случаях, где свободное пространство принудительно не зачищалось это позволит получить какой-то объем данных.
JerleShannara
09.11.2019 22:35+3И для тех, кому возможно нужно будет восстановление данных на таком уровне хочется сказать:
1) Используйте сарафанное радио, узнайте у знакомых, где им восстанавливали данные(успешно) после крупных факапов (уронили диск, словили багу в прошивке и т.д.), т.к. есть много фирм, которые мало что умеют, но обещают золотые горы.
2) Если вас не устраивает ценник — будьте вежливыми, для озобленного ремонтника с низкими нормами морали запустить в терминале скриптик типа «fukfuj/fukmarvel»/аккуратно уронить диск — дело десяти секунд, после чего ценник восстановление в нормальной фирме взлетит до высоты МКС, а то и само восстановление станет просто невозможным(либо перейдет к классической схеме «10$ за мегабайт без гарантий»).
Пока я занимался восстановлением периодически появлялись диски, на которых была просто стёрта вся служебка/были убиты P-List/G-List. Как правило эти диски приходили с описанием «обратился в „ООО ГовноконтораРазводил“, мне насчитали 100500$, не хотели отдавать, я поругался, мне вернули».
VBKesha
09.11.2019 23:15+41) Используйте сарафанное радио, узнайте у знакомых, где им восстанавливали данные(успешно) после крупных факапов (уронили диск, словили багу в прошивке и т.д.), т.к. есть много фирм, которые мало что умеют, но обещают золотые горы.
Я бы сказал даже желательно узнать имя человека который это делал и где он сейчас работает.
А то было что в одной и тойже организации идеально восстановили WD80JB с горелой платой(до сих пор рабоатет без нареканий). Через год принес SCSI винта с обитой индуктивностью, даже донора принес с такой же индуктивностью, две недели меняли индуктивность, потом попросили SCSI контроллер чтобы протестировать, отадли со словами восстановить нельзя. Пришёл домой стал глядеть вместо индуктивности запаяли кондесатор. Инструмета нормального тогда небыло но за 40 минут с ЭПСН-60 поменял кондесатор на нужную инуктивность, диск после этого ещё и заработал нормально.
Отгадка оказалось простой все адекватные работники свалили из конторы и открыли свою в другом месте.JerleShannara
09.11.2019 23:51+2С таким человеком очень желательно вообще дружеские отношения иметь =)
eugene08
10.11.2019 00:50скажите, а есть ли смысл добавить «0.5) сделать дамп диска (dd и тп)»?
послея поругался, мне вернули
я бы ничего хорошего от диска не ждал уже.JerleShannara
10.11.2019 01:38Не во всех случаях, т.к. если у диска БМГ совершил близкое знакомство с поверхностью, то внутри могут уже быть весьма острые продукты этого знакомства, и выполнив простое dd if=/dev/sda of=/mnt/koolshare/mypron.img вы рискуете во-первых прикончить БМГ, а во вторых превратить его в миниатюрную болгарку и перейти в вариант «ну мы тут вам восстановили 10% диска, далее там всё мертво было», либо уже попасть в клиенты фирм типа OnTrack с ценником из пункта 2). То есть посекторную копию имеет смысл снять только если файлы были тупо удалены, после чего диск отформатировали или схожих проблем.
engine9
10.11.2019 12:45О, кстати о dd. Вопрос к автору статьи: а бывали случаи когда к вам приходили не с устройством а со снятым с него образом, для починки логических проблем?
lll000lll
10.11.2019 16:22Отсеять значительную часть «разводил» может быть намного проще, чем вы себе представляете. Чаще всего они врут прямо на главных страницах своих сайтов и по телефону. И проверяется это за минуты.
Вот буквально, прямо на главной странице сайта. В былые времена публиковали фотографии непонятного медицинского оборудования рядом с рассказом о своей «уникальной лаборатории».
Сейчас могут написать, к примеру, что являются партнёрами Сигейта. Хотя все профи знают, что у Сигейта нет партнёров по восстановлению данных в России. Проверяется это быстро.
Любимая тема — это «крупнейшая компания» и «20 лет на рынке». Ежегодно наблюдаю появление новых «крупнейших» компаний, на сайтах которых утверждается, что они к тому же «старейшие». Просто посмотрите дату регистрации домена, перед тем, как обращаться. Зачем крупнейшей-старейшей компании переносить сайт на новый домен?
Можно ещё попросить показать лабораторию. Если ответят, что она секретная — вы общаетесь с «разводилами». Нет там ничего секретного. Все секреты в головах, софте, или, максимум, в ящик стола помещаются.
Что касается намеренной порчи оборудования. На сколько мне известно, в Москве, в известных компаниях, которые работают годами работают под своими именами, такого сейчас нет. Это довольно быстро «всплывает» и «специалист» мгновенно увольняется, руководители за этим следят, лишние проблемы им не нужны.
Да, где-то работают по прайсу, а где-то менеджер определяет платёжеспособность клиента и важность данных. Где-то квалификация специалистов выше, где-то ниже. Кто-то постоянно врёт про организацию конференций, партнёрство с вендорами и т.п. Есть компания, в которой при поступлении диска, побывавшей до этого в другой организации, в обязательном порядке расскажут о вопиющей некомпетентности специалиста, который смотрел до них, и попросят написать об этом отзыв. Сами при этом называют всегда «более тяжелую» неисправность, чтобы если клиент начнёт обзванивать другие компании, с вопросом о стоимости её устранения, ему называли боле высокую цену.
Но есть группа людей, которые последних лет 15 под разными именами «работают» по такой схеме:
- Обещают восстановить данные дёшево.
- Если случай сложный — отказываются. Если простой — копируют данные себе и доламывают диск.
- Сообщают о том, что проблема намного сложнее, чем предполагалось, и либо предлагают обратиться в другое место (куда передают считанные данные), либо называют высокую стоимость работ сами.
pedaye
10.11.2019 01:29Как видно в данной статье восстанавливали диск с NTFS. Что является стандартной и часто используемой ФС.
Для дисков с данными я использую файловые системы Btrfs и ZFS.
hddmasters правильно ли я понимаю, что в случае необходимости(бекапы есть, но всякое бывает) вы не сможете восстановить данные с HDD, на котором используется Btrfs или ZFS?
А если сможете, то насколько сложнее или меньше шансов это сделать, чем в случае с NTFS? Или совершенно нет никакой разницы при восстановление информации с NTFS, Btrfs или ZFS?hddmasters Автор
10.11.2019 01:32На сегодняшний день Btrfs, ZFS уже не представляет такую диковинку какими были еще несколько лет назад и разумеется на сегодня достаточно много известно об организации метаданных данных файловых систем и разработаны методы анализа.
Возможность или невозможность восстановления определяется в первую очередь характером повреждений файловой системы или самого накопителя.
pedaye
10.11.2019 01:40Спасибо за ответ!
А то было немного завидно, что в случае проблем, тем у кого NTFS можно надеятся, что в случае проблем есть шансы восстановить диск, ибо я думал, что Btrfs или ZFS не восстановить…
nikolainefedov
10.11.2019 08:41Интересная публикация. Но я, например, все дорогие мне или очень важные файлы копирую и на флешки, и на переносные жесткие диски. Понятно, что в 2004 году мобильных дисков не было, но дискеты, другие диски, в том числе CD и DVD уже были. Что мешало клиенту позаботиться о копиях дорогих ему файлов?
hddmasters Автор
10.11.2019 09:411) кто-то не задумывается о резервном копировании вообще.
2) кто-то задумывается, но не особо следит за регулярностью
3) кто-то не проверяет насколько корректно созданы резервные копии
у каждого человека свои причины.
drWhy
10.11.2019 14:27Первый раз теряя ценные данные, человек получает нечто более ценное — опыт (который сын ошибок трудных).
evasilenko
10.11.2019 09:31-1А разве за 16 лет полимер на дисках не должен был уплыть и все к черту размагнититься?
hddmasters Автор
10.11.2019 09:33+1Как показывает практика не должен. В донорской базе хватает дисков выпущенных в девяностых годах прошлого века. Они вполне себе работоспособны.
psycho-coder
10.11.2019 12:56Несколько лет назад еще работал Maxtor на 164Мб, выпущенный в 1992 году. Как сейчас не знаю, не проверял.
corvair
11.11.2019 06:56Из самых мелких у меня жив MFM Seagate ST-225 на 20 МБ, стоит в XT. Выпущен в конце 80х, распространённая модель, рабочие НЖМД этой модели не такая редкость.
drWhy
11.11.2019 12:01Самый первый, встреченный в 1991-92 г. — 6 МБ, болгарский, уже тогда страдавший тяжёлой формой перемежающейся амнезии, требовавший форматирования раз в неделю.
Самый-самый — 1 ГБ SCSI, занимавший два пятидюймовых слота, в глубину весь ATX корпус. Температура корпуса была не ниже 80 °C. Замечаний к функциональности не было.corvair
11.11.2019 12:10Это что за бандурень в глубину на весь корпус? Видел полноразмерные 5,25", но такой глубины ещё не попадались.
hddmasters Автор
11.11.2019 12:31Возможно что-то вроде этого
(картинка взята из публичного источника)drWhy
11.11.2019 12:36Диск был весь в металлическом корпусе, без окон. И визуально длиннее. Но тоже красавец.
corvair
11.11.2019 13:44Кстати, Seagate оказывается до сих пор использует марку Maxtor, для SSD и внешних HDD.
Miller777
12.11.2019 22:50Я года 3 назад отдал кому-то Quantum емкостью 80 или 800 мб, точно не помню уже. В хорошем состоянии, но вот куда его использовать?
drWhy
12.11.2019 22:54Из Fujitsu MPG (если не ошибаюсь в серии) неплохие точилки для ножей получались. В них движок питался напрямую, в более поздних — через контроллер.
psycho-coder
12.11.2019 23:15В IBM 386 или 486) Один такой, не помню уже точно что там, возможно даже 286, пылится на шкафу. Может кому в «музей» нужен?
JerleShannara
10.11.2019 19:16/me посмотрел на Conner Peripherals на 40мб из своего компака 88 года выпуска. Ещё год назад читался и писался (с ооочень «большой скоростью») на старой второпнёвой материнке, на новых и во всех USB-IDE работать он не хочет, что вполне ожидаемо.
hddmasters Автор
10.11.2019 19:35+1CHS адресация. В этих древних накопителях поддержка LBA адресации была опцией. Также в древних conner зачастую логические параметры CHS в паспорте записаны совсем не те, которые нужны для работы. Кроме этого с новыми контроллерами встречались нюансы с работой в режиме ниже, чем PIO 4. Вероятно одна из этих причин не позволила вам запустить старый диск на новой системе.
JerleShannara
11.11.2019 00:02100% попадание, диск не умеет в LBA, в паспорте весьма смешные значения, да и IDE контроллеры последних лет существования весьма оригинально трактовали стандарты. Хотя по большому во времена этого диска ничего этого нужно не было, LBA никто не использовал(я вообще сомневаюсь, что оно было в стандарте тех лет), диск в BIOS выставлялся не по параметрам, а по типу, ну и шустрых PIO/MWDMA/SWDMA/UDMA в природе ещё не существовало.
hddmasters Автор
11.11.2019 12:55диск в BIOS выставлялся не по параметрам, а по типу,
Эти типы и были стандартные по тем временами наборы CHS параметров.
engine9
10.11.2019 12:41Пост теплоты и ламповости. Эх, если бы наше общество состояло из профи такого уровня на всех местах. Наверное, уже бы все доступные планеты заселили...
v1000
10.11.2019 14:28диски вообще странные. всегда считал HITACHI надежными, но один диск пару лет пролежал на полке, подключаю-ноль реакции. при этом второй такой-же вполне рабочий, но я его переодически включал. неужели «разрядился»? :)
hddmasters Автор
11.11.2019 12:02Для начала снять плату контроллера. Промыть и прогреть паяльным феном. После этого скорее всего какая-то активность при подаче питания будет, если он просто умер от лежания на одном месте.
corvair
11.11.2019 07:20Самый старый НЖМД с которого приходилось восстанавливать информацию? MFM/RLL, ESDI были? Экзотические накопители типа Orb, SyQuest? Держите приводы для них и вообще старое железо для соответствующих накопителей?
hddmasters Автор
11.11.2019 12:01В прошлом десятилетии было обращение с MFM диском. В этом нет. В донорское базе в не сортированном старом мусоре вполне возможно, что есть некоторое количество старых MFM накопителей.
Очень старые диски обычно находятся в промышленном оборудовании, которое работает не один десяток лет, но как показывает практика большинство этого оборудования уже родом из девяностых и диски там IDE, SCSI.
Самый древний диск из которого требовалось извлечь данные за последние 3 года был из некого древообрабатывающего станка. Conner емкостью 40Mb с IDE интерфейсом. Датировался или 1991 или 1992 годом выпуска.
KostikN
11.11.2019 23:56Диск старенький. Если у диска сгорела электроника и дефектов на поверхности не было, можно попробовать просканировать поверхность с обнуленным транслятором, занести дефекты в P-List и пересчитать транслятор. Это должно убрать сдвиги, на старых квантумах раньше помогало. Если диск еще у вас, можно попробовать.
PS: это работает только для ооооочень старых дисков.hddmasters Автор
12.11.2019 00:02Да, такая методика могла быть использована для некоторых старых накопителей. В данной ситуации можете сами видеть, что нечитаемыми дефектами являются 34 сектора, а к концу раздела сдвиг дорастает до 61 сектора. Это достаточно красноречиво говорит о том, что метод занесения в P-list с пересчетом транслятора уже в полной мере не поможет в этом случае.
johnl
13.11.2019 12:36Давно лежит знаменитый IBM Deskstar 80gb умерший от click of death. Года 2003го выпуска. Можно его ещё восстановить? Сколько это будет стоить?
hddmasters Автор
13.11.2019 12:57Ответить на вопросы можно ли восстановить и сколько будет стоить можно лишь после проведения бесплатных диагностических мероприятий. К сожалению заочно я не могу оценить состояние пластин, БМГ, PCB и модулей микропрограммы.
Могу предположить, что Вы говорите о стучащем накопителе, который не выходит в готовность. Вероятнее всего по причине неисправного блока магнитных головок. В таком случае ориентировочная стоимость работ при достижении успешного результата может быть от 400 до 1000 белорусских рублей (от 200 до 500 долларов США или от 12 500 до 31 250 российских рублей).
0mogol0
интересный отчет!
не спрашиваю во сколько в итоге обошлось клиенту восстановление данных, всё же интересно, что же такого ценного там было, что стоило пятнадцать лет таскать диск по сервисам.
hddmasters Автор
Клиента в первую очередь интересовало коллекция фотографий, а также исходники его попыток программирования в студенческие годы. Со слов клиента диск не все время был в сервисах. в этом десятилетии он преимущественно был у самого клиента. И лишь когда диск ему вновь попался на глаза он решился еще раз отнести его куда-нибудь.
0mogol0
листаю предыдущие записи, и захотел попросить рассказать про желаемый алгоритм действия продвинутого пользователя, когда что-то с диском пошло не так…
Просто вариант — сразу нести в специализированную фирму — он обычно чреват лишними расходами, поэтому если знаешь про существование программ для восстановления данных, то сначала попробуешь использовать их.
Судя по вашим рассказами — иногда это может сработать, иногда это может только ухудшить ситуацию. И вот было бы интересно прочитать, в каких ситуациях (с вашей т.з. / с учётом вашего опыта) можно попытаться самим что-то вытащить, а в каких лучше аккуратно выключить и нести к вам.
Понятно, что дальше каждый может сам решать, следовать ему вашим советам или эксперементировать дальше самому
P.S. и если можно упомянуть про особенности SSD дисков, а то у меня классические диски остались только в NAS, а вот в PC cтоит уже SSD. Ну и чем лучше следить за состоянием дисков — тоже интересно
hddmasters Автор
При наличии свободного времени попробую учесть пожелания. Но не буду обещать, что это случится быстро.
0mogol0
Ну само собой, только если будет время или желание написать на эту тему :-)
Mutilator
Дико присоединяюсь к предыдущему оратору, хотелось бы хотя бы минимальный польвозательский алгоритм, на предмет — стоит ли вообще возиться с пациентом, перед тем как отправлять в дорогущую лабораторию.
drWhy
Если диск не раскручивает шпиндели — в лабораторию. Если раскручивает, но издаёт механический скрежет — туда же (попался один диск, весь внутри расписанный циклоидами). Если не отзывается интерфейс и нет запасной платы электроники — также. В лаборатории шансов восстановить такие диски гораздо больше. Впрочем, если вы уверены в собственных навыках по замене двигателя шпинделя, блока головок или восстановлении силовой части платы электроники — лаборатория будет излишней.
Если диск физически скорее жив — сделать тест чтения программой Victoria HDD (она не травмирует диск принудительными многократными попытками считывания), посмотреть, какие области читаются без проблем, а какие нужно читать аккуратно и в последнюю очередь, чтобы не ухудшить ситуацию.
Для восстановления файлов можно использовать R.Saver.
hddmasters Автор
В современных дисках это давно уже не совсем так. Идеология микропрограмм такова, что накопители обнаружив проблемные участки будут пытаться самостоятельно анализировать проблемы. И попытки тестов накопителей с дефектами могут очень сильно усугубить проблему на пару с процедурами оффлайн-скана. Если кратко, то совет можно дать такой, если в SMART по 5 и 197 атрибутам в поле RAW обнаружились значения отличные от нулевых и данные имеют высокую стоимость и штатным путем уже не копируются, то немедленно прекратить любые попытки.
Некоторый объем рекомендаций есть в моей заметке от 2017 года hddmasters.by/articles/chto_takoe_SMART.html
drWhy
Определённо, при любых физических проблемах лаборатория предпочтительна (опыта и возможностей больше, чем у пользователя).
Но в случаях, когда данные не являются критически важными, пользователь вполне может попытаться восстановить данные самостоятельно. И Victoria, в данном случае, гораздо лучше, чем попытка скопировать содержимое сыпящегося диска Explorer'ом, после чего в очередь на ремапинг ставятся сектора в количестве, заведомо превышающем возможности накопителя, и он уже никогда не возвращается в онлайн.
NiTr0_ua
определяетесь с ценой информации. потом — интересуетесь ценой восстановления в известном датарикавери с положительными отзывами (или у гуру с профильных веток на руборде к примеру). дальше — принимаете решение: отдавать ценные данные в датарикавери, или пытаться поднять своими силами с возможным финалом в виде потери данных.
в целом — если винт начинает издавать непонятные звуки (стуки/скрипы/писки), то его лучше не мучить лишний раз. если на поверхности серьезный запил — он и сам может разрастаться при попытке вычитывать данные вокруг него, и голову может убить.
и да, что НЕ стоит делать: не стоит писать что-либо на проблемный диск (в т.ч. избегать подключения его к виндовс машинам — виндовс имеет свойство гадить без спросу в ФС), не стоит работать с помирающим диском напрямую (делается резервная копия через ddrescue к примеру, а потом уже все эксперименты с ней), не стоит пытаться длительно вычитывать нечитаемый файл — сначала вытягивается все, что читается, а потом уже то что читается плохо.
lll000lll
Для пользователей, не имеющих опыта восстановления данных в случае аппаратных проблем, как правило, алгоритм следующий:
Для помощи в отделении программных проблем от аппаратных, а также для примерного определения характера аппаратной проблемы, есть режим «Quick Diag» в R.tester, программа также бесплатна и не требует установки.
Да, как написали выше, принимайте во внимание, что в случае некоторых вариантов аппаратных проблем, каждое включение диска ухудшает его состояние, не говоря уже о попытках чтения. Поэтому, в случае критически важных данных — несите специалистам сразу.
0mogol0
Ну собственно некоторый опыт восстановления данных есть, но именно что небольшой и давно, поэтому и хотелось услышать именно как отделить случаи, когда можно ещё попробовать самому повозиться, а когда или в морг, или морально готовиться расставаться с некоей суммой за услуги профи.
Так что я внимательно сохраняю и ваши советы, и данные выше, именно на случай, чтобы как говорил т-щ Гиппократ «Не навреди»
uzverkms
Забавно, что все последующие ответы — более менее прямые. В то время как решение проблемы не редко лежит вне области проблемы ;0) Продвинутый пользователь делает бэкапы. И когда с диском что-то пошло не так — восстанавливается из бэкапов. Или меняет диск и опять же восстанавливается с бэкапов.
0mogol0
ох… «если бы я был такой умный ДО, как моя жена ПОСЛЕ...» ;-)
У меня есть NAS, и каждую неделю туда на RAID0 идёт бэкап рабочих файлов, так что если что — восстановится есть откуда, хотя даже недельной давности файлы жалко будет терять.
Но помимо моего ПК, который я обслуживаю сам, есть ещё куча «друзей и знакомых Кролика», которые от ИТ очень далеки, и бэкап, если и делают на внешний диск, то ручками и когда вспомнят, и то что вспомнят… А когда к ним приходит жаренный петух, то они идут ко мне, и просят посмотреть, что можно сделать.
uzverkms
В этом смысле мне нравится как реализована Time machine в Mac OS — для чайников. И то этой функцией пользуются не так часто, как следовало бы.
А в Windows штатные механизмы бэкапа ещё менее дружелюбные и удобные.
Если в отношении антивирусов маркетологи сделали хоть какие-то успехи на потребительском рынке, то с ПО для бэкапов всё существенно грустнее.
Miller777
Под Windows была замечательная бесплатная Comodo Time Machine. Но потом проект умер.
Кажется, есть какие-то современные платные аналоги, но я ими не пользовался.
Кстати, кто-то пользуется чем-то подобным сейчас под Windows?
psycho-coder
Подпишусь на ответы. Тоже интересно
seri0shka