» Восстановление разделов и информации на HDD (часть 7)

9285
Я хотел ставить убунту, поэтому делил диск утилитой, которая у неё была (кстати говоря, после покупки харда сначала был размечен только один C: на весь хард, но потом убунтой я поделил на C: и D;, поделилось нормально и без проблем, а вот когда хотел отделить конец от D: - почему-то затянулось на 3 часа и свет вырубился). Ну в общем, после этого диск D: перестал открываться, а потом вылез chkdsk и намудрил вот такое...
Но я не могу понять, у большинства файлов такой сдвиг есть, а у некоторых нет, и как в такой ситуации разруливать.
Насчёт PhotoRec: сканил вчера 7 часов, пока спать не пошёл и не прервал восстановление, так вот, восстановило много фоток и видео, и они были нормальные и не с обрезанным концом в 3кб, но их названия почему-то восстановить не смогло. Но я залез в found.000, там у тех же фоток есть нормальное название (и дата изменения верная), но их содержание сдвинуто. Это, конечно, не столь важно, но всё же удобнее, ведь раньше все фотки и видео были аккуратно разложены по всем папкам, названы как следует и отсортированы по дате изменения. Пока думаю над этим вопросом...
Кстати, мне в 2009 предлагали такой вариант: грохнуть раздел, а потом натравить на него какую-нибудь прогу для восстановления данных. Поможет ли это восстановлению, или же только всё испортит, и мне восстановит папку found.000 со сдвинутыми данными и потерянными 3кб?

evgen1137

Цитата:

Кстати, мне в 2009 предлагали такой вариант: грохнуть раздел, а потом натравить на него какую-нибудь прогу

именно это вам и ответил 9285 - ниже цитата. То, что у вас все съехало - не означает, что в один момент испортились все файлы.. просто сейчас записи в фс таковы, что файлы определяются некорректно...
9285

Цитата:

... вполне возможно что есть альтернативные структуры, с правильными записями.

т.е. убивать текущую разбивку не нужно, просто нужно сделать поиск всех возможных и пробовать вычитать. Для наглядности у GDB очень неплохо это видно - будет сформировано дерево из различных "вариантов" представления ФС.
Только отключить quick scan и valid MFT only.

evgen1137
Я не знаю как сейчас, но в районе 2009 года у убунты (если говорить о её встроенном "менеджере" дисков) утиль соответствовала этому слову.
Но я не занимался её исследованием. поэтому мне сложно сказать что она могла сделать отностельно безобидной операции поджатия конца раздела. Но, судя по результату (не уверен, но чекдиск к этому не причастен), скорей всего он сделал в стиле акрониса - начала передвигать и начало раздела. Возможно на те самые 6 секторов. если это так, то процесс очень длительный, так как надо переписать практически все данные + ещё и пересчитать MFT. Соотвественно, если на каком то отрезке произошёл сбой, то действие не завершилось полностью. И при передвижках вполне обьяснимо начальное перемещение больших файлов - ведь маленькие потом проще рассовать по дыркам.

Что касается результатов Photorec, то это ка бы подтверждение того, что есть тот самый сдвиг.
А что касается имён и структуры каталогов, то он и не делает этого, так как не работает с ФС (даже если она идеальная).
PS. Cовет не сказать чтобы хороший, но уж точно получше "легендарного" отформатировать раздел а потом искать. Хотя тут ещё надо разбираться чем это делать. А то может прога кроме удаления ещё и что то типа вайпинга сделает. В случае еже если нечто не удаляет ничего из структур ФС, то это почти равносильно MBR off, то есть исключает возможность работы винды с разделом - которая без этих действий может его заполнять новыми записями.

Просканировал раздел через GetDataBack, он меня троллит нашёл 3 варианта MFT, один рекомендованный и два других. Рекомендованный - это который мой текущий со сдвигом 6 сектора "вправо".
Нашёл оригинал одной картинки и её же среди восстановленных данных и принялся изучать. Второй вариант - содержание файлов сдвинуто на 4 сектора в обратную сторону... То есть начала нет, в конце левая информация. Третий вариант - сдвинуто на 1 сектор, тоже в обратную. Можно как-нибудь ткнуть его носом открыть с нужным сдвигом?
P.S. походу всё же структура папок утеряна, в двух дополнительных вариантах MFT были те же dirXXXX в папке с названием типа [000011]

evgen1137

Цитата:

Можно как-нибудь ткнуть его носом открыть с нужным сдвигом?

А может попробовать скопировать на диск приёмник нулевой сектор, бутсектор, MFT, ну и данные со сдвигом на нужное количество секторов?

В WinHex или DMDE это вполне реально попробовать реализовать. Если фактически сдвиг один, то вроде как ничего особо сложного в этом нет. По крайне мере попытка то не пытка.

Цитата:

Второй вариант - содержание файлов сдвинуто на 4 сектора в обратную сторону... То есть начала нет, в конце левая информация.

А четыре сектора до этого файла пробовал присовокупить к началу файла?
Опять же, не факт что это какие то обломки разных ФС. Тут было немало случаев когда по логам было по несколько дублей фрагментов MFT. Да и по тем же логам после разрушений акрониса создаётся впечатление что сдвиг данных происходит не за один заход. То есть они как бы сначала сдвигаются, а птом уже перемещаются - не исключено что это делается в онлайне. В таком случае вполне обьяснимо почему часть данных с одним сдвигом, а другие с другим.

Цитата:

походу всё же структура папок утеряна, в двух дополнительных вариантах MFT были те же dirXXXX в папке с названием типа [000011]

А вот это уже больше похоже на последствия чекдиска не осилившего все эти сдвиги.

Alex_Green
Представил что MFT многофрагментная.
Вообще мне думается что evgen1137 пора бы поработать с DMDE и с результатами открытия разных найденных томов.

Вообще я не понимаю, почему GDB нашёл такие вот левые сдвиги (точнее такие варианты MFT). Я сколько файлов пересматривал и у всех был сдвиг вправо на 6 секторов. У маленьких файлов менее 1кб сдвига не было, они были нормальные. Я смотрел представление файлов в этих всех вариантах MFT и всё было одинаково: папка found.000, названная как [000011], и в ней все те же dirXXXX.chk, только внутри файлов сдвиг другой.
Кстати, я забыл упомянуть одну мелочь. Допустим в dir0765.chk есть папки, так вот, они пустые, а вот их содержание будет в dir0766.chk или же dir0767.chk и т.п. Но иногда может выпасть так, что внутри dirXXXX.chk может быть папка, но не пустая, но такое редко.
Сейчас через GDB я открыл Disk Explorer и в нём подменил Cluster0 @ sector и Boot Record @ sector, и начал просматривать файлы. Все картинки в порядке, даже структура папок вроде бы правильная, в смысле в линейном виде в правильном порядке идут они. Но только встаёт вопрос, как всё это дело аккуратно восстановить? Чтобы не накосячить там и всё не испортить...

evgen1137

Цитата:

У маленьких файлов менее 1кб сдвига не было, они были нормальные.

А как же появившиеся знания?
Файлы такого размера (преимущественно) располагаются резидентно в MFT и поэтому у них нет никаких сдвигов.
Что касается имён папок и их содержимого, то и здесь всё обьяснимо тем, что существуют т.н. "родители". То есть у файла существует родительская папка, которая в свою очередь может иметь своего родителя. Самый главный "родитель" корневая папка. И если нет какой то записи о папке (её имени) то ей и задаётся имя dirXXX. И это могут быть цепочки таких вот "сирот".

comrades, помогите, пожалуйста, как лучше сделать:
жесткий диск WDC WD1600AAJS-00L7A0WD, как мне сказали "несколько раз был синий экран смерти, а после очередного жесткого ресета всё", жестко вис проводник в WinPE, SMART в CrystalDiskInfo уже после того, как оснаска управления дисками перестала виснуть и удалось убрать буквы у дисков, сразу подумал, что поврежденный сектор попал на какой-то служебный файл ФС, поэтому - SMART в Victoria и скан в ней же.
Скрин разделов в DMDE. При попытке открыть первый раздел в DMDE получаю ошибку Ошибка чтения MFT #46085-46085, после нажатия на ОК раздел открывается со всей структурой. Если верить findlbaf, то первый сектор попал на $MFT (хотя начинается с 786432), второй - на какой-то JPEG (пока не искал, название на русском, ну что за люди, а?).
Как быть? Вытаскивать инфу любой приличной рекаверилкой, а потом Erase и чтение с ремапом?

Цитата:

Как быть? Вытаскивать инфу любой приличной рекаверилкой

Если нет задания восстановить "на месте" - почему бы и нет. Тем более диску нужно небольшое лечение от бэдов, а при этом лучше инфы чтобы не было. Кроме того перед
Цитата:

а потом Erase и чтение с ремапом

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

igor_me
Спасибо, начну с контактов, пожалуй. ОС в любом случае под снос, мне только не совсем понятно: не помешает ли этот битый сектор? Не хотелось бы искать и восстанавливать по сигнатурам, без имени, без пути, но R-Studio вроде молча открыла, DMDE ругнулась только на одну запись. И в SMART не очень разбираюсь, но, кажется, ничего фатального. Не хочу накосячить, поэтому хотел всё уточнить

С условиями я в пролете, наверное. Не буду загадывать.

Цитата:

то первый сектор попал на $MFT (хотя начинается с 786432),

786432 - это начальный кластер, а 46085 - это номер записи. Учитывая что запись из двух секторов, не исключено что первый сектор может и читаем - соотвественно можно узнать что за обьект в нём записан.
Я обычно такое лечу ремапом проблемного сектора и последующим чекдиском. Но это при условии что сбой единичный, потому как бывает сбойный один, а последующие действия выявляют не один (десяток, сотню).

9285

Цитата:

Представил что MFT многофрагментная.

Просто будет больше мороки, но в принципе ведь можно перенести все фрагменты MFT, сколько бы их не было.
А вообще да, было бы интересно посмотреть на результат поиска NTFS в DMDE.

evgen1137
Как насчёт DMDE? В некоторых случаях она справляется лучше других рекаверилок.

9285

Цитата:

Я обычно такое лечу ремапом проблемного сектора

до ремапа полезно сделать простое стирание (запись) в проблемный сектор (read-erase вместо read-remap).. если при чтении ошибок не будет - значит, был софт-бед, а при ремапе (бывает) этот сектор сразу заменят из резервных и соотв. картину в СМАРТе подпортят и время доступа станет чуть хуже..

Skif_off

Цитата:

С условиями я в пролете, наверное. Не буду загадывать.

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

south_man
Я писал не про софт-бэды. Не знаю, может система пытается записать в MFT неоднократно, поэтому в случае софт-бэда у неё это получается; а когда не софт то и последствия другие ( отсюда? растут ноги синьки).
По крайней мере, лично мне пока не встречались софт-бэды в области MFT.

9285
для ОС любой UNC (софт или нет) - это бедблок, записать она не может, т.к. испорчена сервисная инфа о секторе (которая правится в режиме записи сектора или при форматировании). я к тому, что прежде, чем делать ремап т.е. "намекать" диску сделать замещение, лучше сделать перезапись сектора - если это софт, то он встанет на место и замещать его не нужно будет..

south_man
Я не в курсе алгоритмов (попыток) записи различных ОС; в том числе в служебную область. Хотя не вижу особой разницы в попытке записи при быстром формате виндой и попыткой записи в MFT.
Если реально так, как пишешь, то конечно же ты прав.

Alex_Green

Цитата:

А вообще да, было бы интересно посмотреть на результат поиска NTFS в DMDE.

Сканировал 2 часа, нашло только одну NTFS, мою текущую. Ну и посмотрев через DMDE содержание файлов - всё также, сдвиг на 6 секторов. В общем, я понял одну вещь: GDB в строке "Кластер 0" пишет 184 313 745. Аналогично и в Disk Explorer. Так вот, в Disk Explorer можно визуально менять это значение. Я поставил 184313751 (то есть прибавил 6) и сдвиг пропал, т.е. восстанавливая файлы через Disk Explorer с этой правкой он восстанавливался нормально. А через DBDE, если смотреть пункт "таблица разделов", там это правильное значение стоит в строке Hidden Sectors, и я что-то запутался. Собственно, как и где поправить значение Cluster 0? Заранее большое спасибо за помощь

evgen1137
GDB не пользовался давно, поэтому могу лишь предположить что речь идёт о виртуальной подстановке. То есть программа "в уме" прибавляет ко всем текущим значениям смещения. В реальности же для этого надо делать реальные смещения.
PS. Вообще то уже начинает напрягать игра в кошки-мышки. Может пора просто показать как это выглядит? В том числе и то, что тебя запутало.

Доброго вечера всем!
Помогите восстановить таблицу разделов на новом ноуте с таблицей GUID. Есть другой такой же ноут под рукой. Удалил Recovery раздел в конце диска, а теперь нужно его восстановить. Систему не устанавливал, поэтому данные затереться не могли. Каким софтом можно скопировать GUID-таблицу с одного на другой ноут и какой ее размер может быть?

ICQman2GO
А ты уверен в идентичности буков и GUID.
Если же надо просто вставить удалённый раздел то можно сделать это в DMDE.

Ноутбуки абсолютно одинаковые. Я на одном начал ставить семерку и удалил разделы, в т.ч. Recovery, а потом оказалось, что Win7 никак не хочет ставиться на GPT. Теперь хочу вернуть изначальную разметку и установить с нее предустановленную 8-ку.

9285

Цитата:

Может пора просто показать как это выглядит?

Я погуглил про Hidden sectors и прочитал о том, что он используется для вычисления смещения на данные. Так вот прикол в том, что у меня в MFT записано правильное значение, а вот Cluster 0 неверный... Подробнее в комментах на скринах ниже:
http://d.qw0.ru/akina/img/2014-09/16/wxdwjfxv5r6965bk5wodx7s62.png
http://d.qw0.ru/akina/img/2014-09/16/f768svae5f3qajl9fg0paw4p1.png
http://d.qw0.ru/akina/img/2014-09/16/qljmdoi0mfr8gw3moimxul41l.png
http://d.qw0.ru/akina/img/2014-09/16/i28chyts86wmdvyjcwpyo2cxe.png
http://d.qw0.ru/akina/img/2014-09/16/1ipt0132y59mnrkidwmykv27b.png
http://d.qw0.ru/akina/img/2014-09/16/pl3s08jim3hdv02p8e4opbsbo.png
http://d.qw0.ru/akina/img/2014-09/16/gm08janu46u1e4d8ahs098e2m.png
http://d.qw0.ru/akina/img/2014-09/16/t45uib7h0fim1cil4ne8lfe5e.png

evgen1137
Hidden sectors - количество секторов между бутсектором раздела и таблицей разделов.
Для основных разделов оно равно значению сектора, в котором начинается раздел
К данным не имеет никакого отношения. И в MFT этого значения нет.
Но в ранлисте каждого файла указываются кластера, которые занимает файл; и они отсчитываются от начала раздела. Соотвественно, в GDB ты как бы говоришь "файл начинается в кластере ХХХ, но не от сектора 184313751 а от 184313756".
PS. Когда имеются какие то проблемы, которые могут затрагивать не только сектора логического диска, следуют делать поиск на участке где могут быть эти "хвосты" или уж на всём физическом диске.

Рабочий винчестер Hitachi HDS721050CLA362 в пятницу вечером когда выключали компьютер все было в порядке, сегодня по включению, винчестер перестал быть видимым в BIOS. Поставил его 2-м винчестером на 2-й компьютер, система его увидела, но говорит, что он не размечен и не отформатирован, как будто это новый винчестер. Вернул его обратно в родной системный блок, BIOS стал видеть, но также говорит что нет данных. Acronis Disk Director также видет и утверждает, что данных нет!!!
Возможно ли восстановить работоспособность или хотя бы достать данные!?

Yaumen
Цитата:

хотя бы достать данные!?

для начала достать винт. открутить плату электроники и почистить с обратной стороны контакты стиркой. они от времени часто окисляются. поставить винт в комп запустить с флешки WinPE и попробовать !читать! на нем сектора какой-нить прогой типа Hex Workshop / Hex Editor Neo / WinHEX. если читает нормально - пробовать вытащить данные DMDE / R-Studio / Runtime.

Цитата:

Возможно ли восстановить работоспособность

зависит от состояния винта.

Yaumen
Если в винде сообщается я что диск не проинициализирован. то как минимум проблемы с 0-вым сектором.
Вопрос только в том, с чем они связаны. Можно попробовать посмотреть что покажет DMDE, но подозреваю что есть физические проблемы, и при некоторых каждое лишнее включение-чтение могут лишь усугубить ситуацию. Поэтому попробуй спросить в теме про ремонт Hitachi - может у них есть какие то (фирменные) болячки.

alexgr,
Но ведь диск не имеет буквы в Windows возможно ли будет к нему применить большинство программ по восстановлению или хотя бы те же
Цитата:

Hex Workshop / Hex Editor Neo / WinHEX

9285,
Acronis Disk Director говорит что на диске нет данных, т.е. не отформатирован и не разбит

Цитата:

спросить в теме про ремонт Hitachi - может у них есть какие то (фирменные) болячки.

0-я голова подыхает часто.