» Пропал диск. Восстановление таблицы разделов (не данных) - 2

Цитата:

Практически всегда проходило безболезнено.

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

Цитата:

Не заремапился? Тоже вполне рядовой случай.

Не знаю, что ты подразумеваешь под фразой "рядовой случай", но для меня совершенно очевидно, коль винт выдал бэд и не мог с ним справиться сам, все-в печку! Пусть диском занимается продавец, при условии, что винт на гарантии. Потому как никто мне не сможет дать гарантию, что винт не будет сыпаться и дальше. Если же диск уже не на гарантии, вот тогда можно и СМАРТ смотреть и слушать всякие умные речи тута, и скрывать бэды от файловой системы, и с горки кататься... но это хождение по краю. Да, работать он будет, но какое время-большой вопрос. А оно мне надо... а тебе?

Здравствуйте.
Так случилось, что Acronis Disk Director, который многие годы оправдывал моё доверие, всё же подсунул мне в конце концов свинью.
Мне принесли ноутбук с 500 ГБ винчестером, имеющим 3 раздела:
- Dell Utility Partition (FAT16) на 196,1 МБ
- раздел восстановления (NTFS) на 8928 МБ
- пользовательский раздел (NTFS) на 456,7 ГБ
Задача состояла в том, чтобы разбить пользовательский раздел пополам, для чего я и использовал Acronis Disk Director. Сначала уменьшил раздел до 191 ГБ, а потом на освободившемся пространстве создал логический диск на 265,7 ГБ. После этого повредилась MFT.
Внимательно изучил эту тему, но поскольку квалификации не хватает, а на диске есть пусть и небольшой, но критически важный объём данных, дальше пробовать не рискнул. Если кто-то из специалистов найдёт возможность помочь, был бы очень благодарен.
Архив с дампами и снимком экрана DMDE: http://rghost.net/12118971

Svagrad
Судя по данным логического (нюансы названий пока отбросим) раздела, проблемы с третьим разделом.
Если так, то сбросьте дампы секторов 25417728 + 50 последующих.

9285
Спасибо. Завтра с самого утра залью дампы — диск на работе. О нюансах можно в ЛС, если не затруднит

Секторы 25417728 + 50
http://rghost.net/12201251

Svagrad
В MFT присутствуют ошибки, но какие конкретно не знаю.

Я тут натворил дел. Вообщем k компу были подключены
внешний жесткий диск и
флешка. Мне надо было форматнуть флешку ,но по ошибке выбрал жесткий. Форматирование вроде даже не
началось, т.к он использовался в Daemon tools и сразу выскочила табличка с предупреждением на
английском. Вот только теперь не могу открыть диск. Пишет:ДИСК НЕ ОТФАРМОТИРОВАН, СДЕЛАТЬ ФОРМАТИРОВАНИЕ СЕЙЧАС? Возможно ли как нибудь
открыть его без
форматирования?

Svagrad
9285
Пропустил сообщение в личке, сорри.

Svagrad

Цитата:

Секторы 25417728 + 50

"Файл удален"! Перезалейте plz.
И еще, покажите результат chkdsk.exe БукваРаздела:

Добавлено:
xammep1984
Покажите дамп 10000 начальных секторов раздела (не диска, а раздела), а также дамп 100 секторов, начиная с сектора 6291456 от начаал раздела. Чем форматировался пострадавший раздел? Он был NTFS?

Antech
http://sderni.ru/73678

9285
Thx.
Но я там ошибок не заметил. По крайней мере в $MFT : DATA все размеры совпадают (ранлист, LastVCN, size in bytes). Другие начальные записи на вид в порядке, не проверять же их досканально. Так что ждем результатов Чекдиска без /f.

Antech
Подождём, но я исхожу из простой логики.
Берём работающий раздел и удаляем из него всё, кроме загрузочной записи и MFT (главных записей). Делаем chkdsk - сообщает о проблемах с индексами.
Теперь берём имеющиеся дампы кейса и записываем их в соответствующие места, и удаляем "лишние" сектора из MFT. Проверка - сообщение "повреждена основная таблица данных".

9285
Блин, вот дерьмо. Ладно, сейчас гляну, у меня тоже есть винт для опытов .
Проверил, у меня пишет не "Повреждена основная таблица файлов. Выполнение прервано", а "Запись атрибута 128 в сегменте записи файла 0 повреждена", но у меня раздел мелкий (233 ГиБ), а у Сваграда 457 ГиБ, а у MFT три фрагмента и, вероятно, один или два не влазят в мой раздел (точнее не смотрел).

Svagrad
Ау!

Antech
У меня хоть и есть винт на 500 гиг, но не для опытов. Зато есть VMware Player.

9285
У всех есть VMWare Player . Просто мне удобнее внешник воткнуть.
Что-то наш клиент не отвечает...

Прошу прощения, всё время был в разъездах. 9285 благодарю за заливку архива!
Вот что пишет CHKDSK:
Цитата:

Тип файловой системы: NTFS.
Метка тома: OS.

ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.
Повреждена основная таблица файлов. Выполнение CHKDSK прервано.

Svagrad
Ну тогда я не знаю. MFT взята по смещению в бутсекторе, это я еще раз проверил. Размер кластера 8 секторов, тут мы не ошибаемся. У меня на тестовом винте Ваше начало MFT нормально заработало. Было сообщение об ошибке в $MFT : DATA, я думал из-за размера раздела, но тут посмотрел: у Вас 205 ГБ, у меня был больше размер. На самом деле ошибка была из-за смещения MFT (у меня было стандартное, я по нему и вставил, а в самой MFT указано нестандартное). Миррор я тоже перезаписывал. Каким образом у Вас не работает, я не знаю. С размером винта все в порядке?

Упс, я вот что заметил. Размер раздела по бутсектору 400475432 сектора (205 ГБ). В то же время, ранлист MFT содержит экстенты с началами в секторах 522389328 = 267 ГБ (второй экстент) и 890850672 = 456 ГБ (третий экстент) - как же хорошо, что есть мой MediaWorkshop - так удобно посмотреть экстенты, и он Freeware (это были неумело скрытые понты ). Т.е. уж точно за пределы раздела вылезает. Вполне возможна такая реакция Чекдиска.

Посмотрим внимательнее на картинку DMDE. Мы там видим два раздела: тот, который сейчас рассматриваем (он есть в таблице) размером 205 ГБ и еще один раздел, который начинается немного раньше, размером 957644800 секторов (490 ГБ - до конца винта), в таблице его нет. Идея понятна? Бутсектор рассматриваемого раздела ссылается не на свою MFT. Это MFT раздела 490 ГБ, который занимал пространство до конца раздела, а сейчас у Вас есть еще какой-то там логический. Так что раскрывайте карты: как Вы такого добились и что делать. Какой размер должен быть у рассматриваемого раздела: 205 или 490 ГБ? Если 490, то что будем делать с логическим разделом в конце, убирать? Если 205, то ищите MFT от него (Поиск NTFS в области рассматриваемого раздела).

Да и вообще, млин, ну мы Шерлоки Холмсы... Да там все очевидно: посмотрите на смещение первого экстента MFT - там стандартное 786432 кластера (6291456 секторов), а в бутсекторе - совсем другое смещение! И мы так долго ходили вокруг да около... И это гворит о том, что без партмагоида тут, похоже, не обошлось.

Antech

Цитата:

Да там все очевидно:

Ну да, это же элементарно Ватсон. Хотя, подозреваю, что Svagrad сначала не поймёт о чём речь.
Кстати, про пармагоид (судя по начальному сектору MFT) я ему уже писал (в личке), а вот насчёт ранлистов как то и не глянул. Но это не моё. Поэтому то и написал ему кто может раскрутить этот клубок.

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


Добавлено:
Возможно, что теперь проблема уже не по теме текущего раздела. Просто я подумал, что исправив MFT, с диска получится извлечь все необходимые данные — конечная цель именно такова.
На снимке экрана выделен раздел на 490 ГБ, именно с него удаётся считывать и восстанавливать нужные каталоги, но часть DNG файлов в них оказывается битой



Партмагоидом в данном случае выступил Acronis Disk Director, как я и написал в первом сообщении.

А как будет выглядеть запись о начальном секторе раздела, находящегося в конце 3ТБ харда? Ведь макс. число FF FF FF FF (2ТБ)

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

После нахождения причины проблемы, всё выглядит немного по другому.

Цитата:

а потом на освободившемся пространстве создал логический диск на 265,7 ГБ. После этого повредилась MFT.

То есть, до создания раздела на 265, 7 гигов повреждения не было? Если да, то получается что система считывала MFT и за пределами раздела - на свободном месте, а когда его отдали лог.диску, то уже перестала.
В таком случае, я бы попробовал сделать следующее:
1. сделать посекторную копию обоих разделов (чтоб не было мучительно больно в дальнейшем)
2. удалить данные о расширенном разделе, и возможно изменить размеры раздела до прежних (не программами, а значениями в РТ и бутсекторе)
3. если не будет считывания нужных файлов, запустить проверку диска.
PS. Как вариант, прогнать рековерилками на участке прежнего раздела.

Добавлено:
Sphinx114
Если винт более 2тб, то как бы надо забыть об MBR и использовать GPT.

9285
Да, всё верно. Акронис завершил всё штатно и до создания раздела повреждения не было.
У меня тоже были подобные мысли по поводу возврата прежней разметки, так и сделаю.
Единственный вопрос — разъясните
Цитата:

(не программами, а значениями в РТ и бутсекторе)

Svagrad
Имеется в виду ручное изменение значений.
Потому как, если для изменения размера раздела воспользоваться тем же акронисом (впрочем как и другими) то, и так спутанные "карты" будут перемешаны окончательно.
Сейчас, действительно MFT как бы от старого раздела, хотя уже и смещена на место, указанное в бутсекторе нового раздела.
Сложновато, не видя всей картины, предложить как поступить лучше.
Давай, чтобы понять чуть больше, глянем содержимое секторов:
19126872+ 8
541515624 + 10
909976968 + 10




Добавлено:

Цитата:

На снимке экрана выделен раздел на 490 ГБ, именно с него удаётся считывать и восстанавливать нужные каталоги, но часть DNG файлов в них оказывается битой

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

Svagrad
Понятно... Это может быть партмагоидное смещение, что очень плохо. Хотя, если перезаписано, то эти файлы вообще не восстановимы.


Цитата:

Акронис завершил всё штатно и до создания раздела повреждения не было

Но ведь размер раздела уже был такой как сейчас, и MFT явно там же и была. Кроме того, файлы нормально восстанавливаются именно при старом начале разедла, а не при новом. Так что это непонятно. Неужели Акронис при создании нового раздела изменил начальный сектор сабжа?
Можете попробовать вернуть старые координаты сабжа в таблицу разделов. Бутсектор и MFT по показаниям на месте, может раздел и восстановится, но с битыми файлами врядли что-то можно сделать самостоятельно (если это партмагоидное смещение, то сделать наверняка можно, но врядли на любительском уровне). Вот MBR с исправленными координатами и без расширенного раздела. DMDE - Копировать секторы, из файла в физический диск, первый сектор 0, число секторов 1. После перезагрузки зацените результат. Если не понравится, можете вернуть как было: вместо этой MBR запишите свой дамп сектора 0 (sec_0_1.img).

Antech
Судя по скриншоту разделов, (409 гиговый смешён на 3 кластера) акронис оставил MFT на месте, но почему то не закончив остальные действия отраппортовал о завершении.

Нутром чую что делалось это из виндовой версии (ещё бы и версию узнать интересно).

9285
Архив с секторами 19126872+ 8; 541515624 + 10; 909976968 + 10 — http://sderni.ru/74063


Цитата:

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

Об этом я не подумал. Если это так и есть, то мы занимаемся бессмысленным делом.
Использовался Acronis Disk Director Suite 10 build 2161, виндовый, да.
Antech
Вчера вернул старые координаты, но поскольку операция оказалась очень долгой, пришлось оставить компьютер работать до утра — соответственно отписаться не смог. Сейчас вот просматриваю файлы и такое впечатление, будто бы те, что с предыдущей разметкой были недоступными, с нынешней разметкой открываются и наоборот. Такое вообще возможно или мне кажется? Тогда можно слить данные с двух разметок и, комбинируя, собрать максимально восстановленный каталог.

Svagrad

Цитата:

Если это так и есть, то мы занимаемся бессмысленным делом

Не стоит вешать нос, а надо верить в лучшее. Тем более что сам дальше пишешь что есть варианты.
Тут главное соизмерить все плюсы и минусы. Был как то случай, когда занимался восстановлением базы 1С. Были предприняты различные методы и база была восстановлена, хотя изначально был восстановлен архив недельной давности.
Когда отдал базу, то пострадавший мимолётом сказал "И к чему было столько усилий, если бы мои работники (читай как негры) всю недельную движуху бы вбили за пару дней".

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

9285
В том-то и дело — ладно бы сам возился, так ведь пришлось к сторонней помощи прибегать, а злоупотреблять этим не стоит.

Цитата:

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

Дампы вот этих: 19126872+ 8; 541515624 + 10; 909976968 + 10 подтвердили?
То есть проблема всё же в MFT, а данные не затронуты? В принципе, не буду лишний раз вопросы задавать, надо проверить на деле.

Svagrad

Цитата:

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

Опять на кактус... Надо было просто залить патч, операция выполняется почти мгновенно. Вы опять что-то колбасили Акронисом...


Цитата:

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

Партмагоидное смещение. Копируйте вначале по старым координатам, потом по новым, и собирайте исправные файлы.


Цитата:

проблема всё же в MFT, а данные не затронуты?

Проблема в смещении содержимого относительно того, что указано в MFT. Что уж там сдвинуто - координаты в MFT иил содержимое файлов - неизвестно, это у авторов Акрониса спросите. Но резуль тат от этого не изменится. Если все так, как Вы говорите, то in-place восстановление невозможно.

9285

Цитата:

Не стоит вешать нос, а надо верить в лучшее

Да, я вижу, наш товарищ все еще верит в Акронис - всю ночь координаты разделов менял, патч MBR уж точно записывается быстрее.

Antech

Цитата:

Опять на кактус... Надо было просто залить патч, операция выполняется почти мгновенно. Вы опять что-то колбасили Акронисом...

Никакого Акрониса, с чего вы взяли? Операция выполнилась мгновенно, но после перезагрузки CHKDSK начал восстанавливать индексы и это заняло много часов. Disk Director я больше не запускал даже.

Цитата:

Партмагоидное смещение. Копируйте вначале по старым координатам, потом по новым, и собирайте исправные файлы.

Значит предположение было верным.

Цитата:

Проблема в смещении содержимого относительно того, что указано в MFT. Что уж там сдвинуто - координаты в MFT иил содержимое файлов - неизвестно, это у авторов Акрониса спросите. Но резуль тат от этого не изменится. Если все так, как Вы говорите, то in-place восстановление невозможно.

Спасибо за разъяснения.
И никакого Акрониса, честно)

Antech

Цитата:

аш товарищ все еще верит в Акронис

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

Svagrad

Цитата:

но после перезагрузки CHKDSK начал восстанавливать индексы

Вот предупредить о том, что не стоит допускать запуска chkdsk (о чём в теме про восстановление данных упоминается постояно) как то вылетело из головы. *посыпает голову пеплом*
Ну что же, будем верить в лучшее (я уже скрестил два пальца) - а имено в то, что чекдиск не сильно попортил сушествующие данные. Лог чекдиска можно глянуть (в журналах системы должен быть)?