Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Операционные системы » Microsoft Windows » Пропал диск. Восстановление таблицы разделов (не данных) - 2

Модерирует : KLASS, IFkO

KLASS (26-02-2017 16:06): Продолжение в Пропал диск. Восстановление таблицы разделов (не данных)-3  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181

   

vu1tur



Moderator-Saaber
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
предыдущие части: 1
ВНИМАНИЕ! В данной теме не восстанавливают данные. Кому восстановить данные сюда... там несколько частей темы, возможно, уже есть решение вашей проблемы. Внимательно читаем шапку.
---------------------------------------------------------------------------------------------
В помощь по данной теме:

Всего записей: 3690 | Зарегистр. 01-02-2003 | Отправлено: 16:26 08-04-2010 | Исправлено: KLASS, 17:42 16-08-2014
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
http://sderni.ru/73678

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 23:21 30-06-2011
Antech

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

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 10:50 01-07-2011
9285

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 11:03 01-07-2011
Antech

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

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 15:18 01-07-2011 | Исправлено: Antech, 15:20 01-07-2011
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
У меня хоть и есть винт на 500 гиг, но не для опытов. Зато есть VMware Player.

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 18:43 01-07-2011
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
9285
У всех есть VMWare Player . Просто мне удобнее внешник воткнуть.
Что-то наш клиент не отвечает...

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 19:08 01-07-2011
Svagrad



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Прошу прощения, всё время был в разъездах. 9285 благодарю за заливку архива!
Вот что пишет CHKDSK:
Цитата:
Тип файловой системы: NTFS.
Метка тома: OS.
 
ВНИМАНИЕ!  Параметр F не указан.
CHKDSK выполняется в режиме только чтения.
Повреждена основная таблица файлов. Выполнение CHKDSK прервано.


Всего записей: 27 | Зарегистр. 23-04-2007 | Отправлено: 19:30 01-07-2011
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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 секторов), а в бутсекторе - совсем другое смещение! И мы так долго ходили вокруг да около... И это гворит о том, что без партмагоида тут, похоже, не обошлось.

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 21:39 02-07-2011 | Исправлено: Antech, 21:44 02-07-2011
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 22:14 02-07-2011 | Исправлено: 9285, 22:16 02-07-2011
Svagrad



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

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

Всего записей: 27 | Зарегистр. 23-04-2007 | Отправлено: 23:57 02-07-2011 | Исправлено: Svagrad, 00:17 03-07-2011
Sphinx114



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

Всего записей: 1201 | Зарегистр. 26-03-2011 | Отправлено: 01:19 03-07-2011
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Svagrad
Когда делал переразбивку, акронис всё завершил штатно? Не знаю насчёт других, но я впервые встречаю подобный случай.
 
После нахождения причины проблемы, всё выглядит немного по другому.

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 09:49 03-07-2011
Svagrad



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
9285
Да, всё верно. Акронис завершил всё штатно и до создания раздела повреждения не было.
У меня тоже были подобные мысли по поводу возврата прежней разметки, так и сделаю.
Единственный вопрос — разъясните
Цитата:
(не программами, а значениями в РТ и бутсекторе)

Всего записей: 27 | Зарегистр. 23-04-2007 | Отправлено: 12:57 03-07-2011
9285

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

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 13:41 03-07-2011 | Исправлено: 9285, 13:41 03-07-2011
Antech

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

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

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

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 21:17 03-07-2011 | Исправлено: Antech, 21:27 03-07-2011
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Antech
Судя по скриншоту разделов, (409 гиговый смешён на 3 кластера) акронис оставил MFT на месте, но почему то не закончив остальные действия отраппортовал о завершении.
 
Нутром чую что делалось это из виндовой версии (ещё бы и версию узнать интересно).

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 21:35 03-07-2011
Svagrad



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
9285
Архив с секторами 19126872+ 8; 541515624 + 10; 909976968 + 10 — http://sderni.ru/74063
 

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

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

Всего записей: 27 | Зарегистр. 23-04-2007 | Отправлено: 12:55 04-07-2011
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Svagrad

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 13:14 04-07-2011 | Исправлено: 9285, 13:24 04-07-2011
Svagrad



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

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

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

Всего записей: 27 | Зарегистр. 23-04-2007 | Отправлено: 13:32 04-07-2011
Antech

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Svagrad

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

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

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

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

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

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

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

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

Всего записей: 3120 | Зарегистр. 26-12-2006 | Отправлено: 13:50 04-07-2011
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181

Компьютерный форум Ru.Board » Операционные системы » Microsoft Windows » Пропал диск. Восстановление таблицы разделов (не данных) - 2
KLASS (26-02-2017 16:06): Продолжение в Пропал диск. Восстановление таблицы разделов (не данных)-3


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru