Ru-Board.club
← Вернуться в раздел «Магнитные носители информации»

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

Автор: spbmax77
Дата сообщения: 27.10.2015 23:51
9285

Цитата:
Я же написал обнулить строку - то есть запись о дублирующем расширенном разделе в таблице разделов.

Это я сделал в MBR в нулевом секторе. М.б. надо было еще где-то?

Добавлено:
возник еще один вопрос. Я уже писал, что у меня есть целый работающий диск с Win 7 на 500 Гб.
Разбит он почти так же как и сбойный Samsung, только на дополнительном(расширенном) разделе - всего один диск (см. рисунок). На этом диске секторы с 1 по 2047 забиты нулями. А на моем Samsunge - какими-то данными. Принципиально, если я обнулю секторы на сбойном диске (руки чешутся)?
При этом, на обоих дисках, в 2048 секторе есть записи про NTLDR(WD 500 Gb) и BOOTMGR(Cбойный Samsung). Почему они разные и что это означает?
Автор: 9285
Дата сообщения: 28.10.2015 01:23
spbmax77

Цитата:
Это я сделал в MBR в нулевом секторе.

Если судить по скриншоту, то ничего ты не сделал, или сделал но не там.

Цитата:
руки чешутся

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

Цитата:
Почему они разные

Потому что в бутсекторе раздела прописано имя загрузчика, которому передаётся управление - про это очень хорошо расписано в теме про мультизагрузку.
Ты не в том направлении копаешь - проблема с винтом связана со сбойными секторами, а в последующем - с неправильным лечением.
Автор: Ph0eniX1991
Дата сообщения: 29.10.2015 13:12
Всем привет.Помогите восстановить инфу с жесткого.

Добавлено:
Дело было так.Акронисом решил увеличить системный диск и получился косяк
том после этого не определяется.форматнул.
и как добавить скрины в сообщение)))
Автор: 9285
Дата сообщения: 29.10.2015 13:55
Ph0eniX1991
Хинт. Выбираешь любое сообщение в котором есть изображение (если хочется именно так), выбираешь Редактировать и смотришь куда выкладывают и как это делается.
Автор: igor_me
Дата сообщения: 29.10.2015 15:15
sezranam
Модель диска принято указывать...
Автор: Ph0eniX1991
Дата сообщения: 29.10.2015 16:08
Извиняюсь.Сейчас будет...


Добавлено:
500 GB WDC WD5000BPVT-75HXZT3
http://rghost.ru/87Ltcjnvp/image.png
Автор: 9285
Дата сообщения: 29.10.2015 16:40
Ph0eniX1991
Не советую пользоваться ломанной версией.
Так в чём собственно проблема?
Понятно что у многих системный идёт первый, но бывает и по другому.
Какой размер был раньше? В чём выразился косяк?
И зачем форматнул? Чем? Если виндой, то быстрым или нет?
В любом случае, надо как минимум забирать букву у проблемного раздела, хотя в зависимости от того что случилось может надо и системный возвращать к прежнему размеру или вообще с диском не работать.
Автор: Ph0eniX1991
Дата сообщения: 29.10.2015 16:54
расширял диск С:, отрезал кусочек от Д: примерно 52 GB. резал Partition Magic. Том с тал недоступным. я его формотнул акронисом. поставил винду. ДМДЕ просканировал. он также определял том 392 GB, но атрибуты другие были и всю структуру тома я видел.Восстановил фотки.Решил остальную инфу на следующий день восстановить, а том уже не определяет(((только , что на фотке и в атрибутах здесь только С.Вот такая фигня.Мне главное данные вытянуть, если это еще реально.Но при первом скане он все поднял(ДМДЕ).
Автор: 9285
Дата сообщения: 29.10.2015 18:39
Ph0eniX1991

Цитата:
Том с тал недоступным. я его формотнул акронисом. поставил винду.

Я понимаю, что тебе всё это понятно, но со стороны это вовсе не так.
Недоступным стал какой? Форматнул какой? Или вообще не форматнул а переразбил?
Тем более что на (обрезанном скриншоте) есть два "тома", которые в сумме соотвествуют одному "новому". Это можно воспринимать как то, что от второго отрезан был кусок (но тогда не очень понятно откуда у него BCF - тоже форматнул?), а потом он добавлен к С. А можно и другие варианты предположить, причём не один.
Автор: Ph0eniX1991
Дата сообщения: 29.10.2015 19:16
Было 2 тома.50 и 400 GB. я от 400 отрезал 50 и присоединил к 50.а от которого отрезал стал недоступным.я его форматнул.сейчас он пустой. на 100 винда стоит.перед установкой винды том форматнул.
Автор: 9285
Дата сообщения: 29.10.2015 19:26
Ph0eniX1991

Цитата:
я его форматнул.сейчас он пустой

Сейчас не могу написать подробнее что делать - но успею:
- прекращай делать хуже
- забери букву у этого раздела
Автор: Ph0eniX1991
Дата сообщения: 29.10.2015 19:59
сори..я начал резать том....но произошла ошибка....и том стал недоступным.я его форматнул и отрезал 50 гб.потом присоединил к С этих 50гб.перед установкой винды форматнул созданный том

Добавлено:
а как забрать букву...у пустого нужно забрать????
Автор: 9285
Дата сообщения: 29.10.2015 23:39
Ph0eniX1991
Мне уже страшно подумать что ещё (более) деструктивное я узнаю в следующем сообщении.
И, исходя из уже имеющейся деструкции, уже можно говорить о том, что нужно прекращать любую работу с диском, или ужимать С (второй раздел) по максимуму и работать с фаршем бывшего D.
В принципе, можно составить [more=сценарий произошедшего]
Запуск Partition Magic привёл к тому что хвост C накрыл начало D = типичная ошибка которая элементарно лечится. Вместо этого был сделан формат после которого диск стал как бы чистым.
Далее есть нюансы с пониманием что всё таки было сделано, потому как отрезал обычно понимается как отрезать от конца (тем более что там и есть такой огрызок), но в контексте формата особой разницы не имеет. Потому что работа уже шла с пустым разделом. Соответственно, все данные, которые раньше были
в начале раздела остались на месте, потому как про них резальщик уже не знал. Ну а потом туда уже могли записаться данный новой винды.
Шанс восстановить есть, но только вопрос какой % и какого качества - да и муторно всё это, особенно если подумать о том, что прежняя MFT тоже могла пострадать. [/more].
Автор: KioShinsoo
Дата сообщения: 30.10.2015 02:52
Имеется раздел NTFS. Перестал монтироваться под Linux (использовал ntfs-3g). TestDisk сказал, что MFT и зеркало повреждены, поэтому восстановление невозможно.
Chkdsk проблем не нашел (из виртуалки, без /f), а в хостовой винде после загрузки, появился экран проверки диска, пропустил, т.к. уже встречался с похожей проблемой и тогда chkdsk сам затёр все файлы, пришлось восстанавливать c GetDataBack for NTFS.
Может можно восстановить MFT? 800 гигов инфы восстанавливать ещё раз не хочется.
HDD SATA ST31000524AS 1TB
[more=Таблица разделов]
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 104118271 103911424 49.6G 7 HPFS/NTFS/exFAT
/dev/sda3 104120320 1840863224 1736742905 828.1G 7 HPFS/NTFS/exFAT
/dev/sda4 1840865278 1953520064 112654787 53.7G f W95 Ext'd (LBA)
/dev/sda5 1840865280 1945710591 104845312 50G 83 Linux
/dev/sda6 1945712640 1953520064 7807425 3.7G 82 Linux swap / Solaris
[/more]
[more=SMART]
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 119 099 006 Pre-fail Always - 219092385
3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 099 099 020 Old_age Always - 1186
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail Always - 8972277713
9 Power_On_Hours 0x0032 079 079 000 Old_age Always - 18634
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1194
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 095 000 Old_age Always - 430
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 063 050 045 Old_age Always - 37 (Min/Max 23/37)
194 Temperature_Celsius 0x0022 037 050 000 Old_age Always - 37 (0 16 0 0 0)
195 Hardware_ECC_Recovered 0x001a 045 022 000 Old_age Always - 219092385
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 21641 (12 212 0)
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 3474277008
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 1147630002
[/more]
[more=ОС]
Windows 7 Enterprise SP1
Ubuntu Linux 15.10
[/more]
Автор: Ph0eniX1991
Дата сообщения: 30.10.2015 08:35
Но попробовать то можно.....Помоги, пожалуйста.....Иначе мне пипец будет....ТАк все и было...от конца Д отрезал кусок и его прилепил к С...Смысл такой
С чего нужно сейчас начинать?
Я весь во внимании...
Автор: 9285
Дата сообщения: 30.10.2015 09:04
KioShinsoo
В другой теме, в описании присутствовало Загрузился в Windows - диск абсолютно чистый.
Это о чём, о разделе или вообще о диске?
Понятное дело что трулинуксоиды работают не в GUI , но инфа лучше воспринимается визуально.
Познакомься с DMDE, причём желательно GUI версией - в основном анализирование данных и другие моменты делаются ей.
И сделай то, о чём писал в другой теме - дамп (или хотя бы скриншот содержимого) бутсектора проблемного раздела; насколько понимаю, его номер 104120320. Если будешь делать дамп, то можешь и последующие штук 20 добавить.
Автор: KioShinsoo
Дата сообщения: 30.10.2015 09:09

Цитата:
В другой теме, в описании присутствовало Загрузился в Windows - диск абсолютно чистый.
Это о чём, о разделе или вообще о диске?

Я сделал такой вывод изначально, т.к. при загрузке пользователя в Windows у меня была надпись "Подготовка рабочего стола" (папка Users была перенесена с системного диска на проблемный), а так как я с такой проблемой уже сталкивался, то и подумал, что диск чистый. Однако в виртуалке я увидел, что диск не открывается + не пишет про свободное и занятое место.
Автор: 9285
Дата сообщения: 30.10.2015 09:18
Ph0eniX1991
Начать нужно с того, что исключить любую запись на участок где раньше располагался D.
А для этого потребуется две вещи.
0. По нормальному - сделать посекторку, чтобы (если что не так сделаешь) можно было вернуть как было.

1. Записать текущие данные из таблицы разделов, после чего удалить в таблице запись нынешнего D. (*)

2. Если нет с чего другого работать.
2.1. В идеале, посмотреть что сейчас расположено на С в части "анексированной" у D.
2.2 Сжать С до размера, бывшего ранее. Причём желательно делать это средствами винды, и очень желательно не из самой винды, т.к. она успеет ещё что то привнести, а с того же загрузочного диска винды - в diskpart есть shrink.

(*) Удаление записи о разделе D защитит от случая, если работать будешь с этой виндой и она, при нехватке места после ужатия раздела, на автомате решит перебросить своп на другой раздел.

Далее - анализируй поляну бывшего D, ищи нужное (в том числе и по сигнатурам) и восстанавливай на другой носитель. Обязательно проверяй целостность восстановленного.
Автор: KioShinsoo
Дата сообщения: 30.10.2015 09:22

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

Вроде сделал как надо: Ссылка. Надеюсь файл доступен.
Автор: 9285
Дата сообщения: 30.10.2015 10:00
KioShinsoo
Файл доступен, в дамп MFT Mirror попало, поэтому можно сделать кое какие выводы.
1. Значения 10-го атрибута обнулены
2. Присутствует 20-й атрибут, что как бы намекает что MFT сильно фрагментирована и неизвестно насколько, потому что надо смотреть список фрагментов.
Причём за некоторое поседнее время, это уже третий случай когда фигурирует связка 20 атрибута и линукса. Чой то это меня настораживает.

Давай ещё посмотрим что в секторах 110411776+200, 104729856+10, 1323354472+8.
Пробовал в DMDE посмотреть содержимое раздела? Если чего то не находишь, да и вообще не помешает, сделай Поиск NTFS на участке проблемного раздела, сохрани лог (выложить его) и посмотри результаты поиска - открывай том с началом в секторе 104120320. После открытия зайди во Всё найденное+реконсрукция. Посмотри что найдено.
И всё так, что пишет чекдиск в режиме только чтения (без ключей)?

PS. Надеюсь ты прочёл (осмыслил) концовку моего сообщения http://forum.ru-board.com/topic.cgi?forum=84&topic=5014#3
PPS. Вечером загляну в тему.
Автор: Ph0eniX1991
Дата сообщения: 30.10.2015 10:09
Заранее извиняюсь, я в этих вопросах чайник(((
Как сделать посекторку....
Запись удалять "Новый том", где определяется 56 ГБ....
Смотреть на С, где Volume 07??
И как потом анализировать поляну Д.
И с чего лучше работать..Кроме ДМДЕ???
Автор: 9285
Дата сообщения: 30.10.2015 12:46
Ph0eniX1991
Сделать с помощью чего то, что делает настоящую посекторку - в той же DMDE. Более безопасно делать в файл - в случае деланья на другой винт есть шанс сделать обратное, и были случаи когда не понимая сути затирали данные на диске-приёмнике.
Если исходить из того что D ранее был 450 гигов, то Новый том, но 392 или вообще расширенный раздел.
Смотреть С который Noname $01.
Работать лучше с того (теми), что дадут лучший результат - причём он может быть обобщенный.
Автор: Ph0eniX1991
Дата сообщения: 30.10.2015 13:11
На С показывает файлы винды....
Сейчас нужно удалить новый том Д...
А как анализировать поляну Д потом???
Автор: 9285
Дата сообщения: 30.10.2015 13:18
Ph0eniX1991
Сейчас у меня небольшая оказия (наличие интернета), но она может оборваться в любой момент.
Поэтому сейчас вряд ли получится тебе описать суть.
Главное для тебя сейчас - не работать с этим диском вообще (если хочется узнать что может быть в конце нынешнего С), в противном случае нужно уменьшать С и только после этого работать с бывшей поляной D. Если не уменьшить С и работать с этой системой, или другой которая может писать на текущий С (такое тоже возможно), то остатки заголовка бывшего D могут перезаписываться - и особо критично если перезапишется бывшая MFT.
Автор: Ph0eniX1991
Дата сообщения: 30.10.2015 15:19
Понял 9285...
Автор: KioShinsoo
Дата сообщения: 30.10.2015 15:35

Цитата:
Давай ещё посмотрим что в секторах 110411776+200, 104729856+10, 1323354472+8.
Пробовал в DMDE посмотреть содержимое раздела? Если чего то не находишь, да и вообще не помешает, сделай Поиск NTFS на участке проблемного раздела, сохрани лог (выложить его) и посмотри результаты поиска - открывай том с началом в секторе 104120320. После открытия зайди во Всё найденное+реконсрукция. Посмотри что найдено.
И всё так, что пишет чекдиск в режиме только чтения (без ключей)?

Дампы:
Ссылка
Ссылка
Ссылка
Лог DMDE: Ссылка
Лог CHKDSK: Ссылка
В DMDE вижу практически всё, кроме папки Users, однако папки содержащиеся в ней также были найдены, но без своих имен.
Автор: Ph0eniX1991
Дата сообщения: 30.10.2015 16:03
9285, я отрезал 53 ГБ от С и удалил через ДМДЕ диск Д....
Больше ничего не делал....
Жду дальнейших указаний
Автор: spbmax77
Дата сообщения: 30.10.2015 19:44
9285


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

Да удалил же. Внизу картинка. Сверху видно, что на месте 4-ого раздела все нули, никакого EXT. Там еще красным бордюром выделено.


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

Как теперь дальше действовать? Или это все безнадежно и надо по новому систему ставить?






Автор: 9285
Дата сообщения: 30.10.2015 22:09
KioShinsoo
По логу видно что есть пропуск в записях MFT (24-77), хотя 24-25 в дампе имеются, да и в поиске они есть, но неопределённые.
Если бы не расширенный атрибут .... Не понимаю я его ещё полностью, поэтому сложно сказать что то.
Могу предложить две вещи - использовать более новую версию 3.х - у программы алгоритмы постоянно улучшаются - может что лучше получится. Лог тоже выложи.
Другой вариант - открой том в DMDE, сначала просто. Смотри в левое нижнее окно там должны будут видны записи MFT. Смотри номера записей, полистай дальше и посмотри есть ли "пропавшие" 26-87.
Как раз таки в тех записях есть и записи Users (42-я как минимум).
Если просто не получится, то можно попробовать через виртуальную реконструкцию.
И ещё один момент - 20 октября работал чекдиск и он что то подправил. Кстати, его записи в зоне где как бы могли быть от MFT. А результат его работы ("сирот") можно посмотреть в папке Found.000

Ph0eniX1991
Запускай поиск NTFS на свободном месте. Открывай тома (с наибольшим числом соответствий) и ищи свои файлы - причём пользуйся и поиском по именам (используй маски).
Если будешь использовать новую версию - 3.х, то ищи и в результатах RAW поиска.
Лог поиска выложи.
И ещё уточни - раньше чем форматировал D? Сейчас, насколько понял - акронисом?

spbmax77
Вообще то я обычно не смотрю в зад. На момент когда я тебе отвечал там не было скриншотов, и вопрос был об обнулении MBR. Зато на следующем (по времени) скриншоте две записи. Так что претензии обращай в зеркало.
Уменьши третий раздел средствами винды на пару мегабайт - четвёртый появится, но всё равно будет RAW
Автор: 9285
Дата сообщения: 31.10.2015 09:25
KioShinsoo
Вчера немного прозондировал про Atribute_List + немного размышлязмов и получается что чекдиск просто пролечил MFT по сути кастрировав по самое нехочу - 256 записей (а по логу вырисовывается 1 миллион 700 с чем то тысяч). Не ожидал я такого и не сразу обратил внимания на собщения в логе чекдиска - ххх of 256 file records processed. Но больше всего с толку сбило наличие 20-го атрибута, который по сути не нужен и, в моём понимании, должен был бы удалиться или очищен.
А ещё это подтверждает извлечённый из дампа лог чекдиска http://rghost.ru/78yPrmZmh
И да, нашлись "пропавшие" записи - фрагмент из записей 32-255 начинается в секторе 104729856.
Может кто и знает как восстановить прежнюю MFT (подозреваю что нужно как то прописать путь на расширенный список), но я нет.[more=(*)](*) Как то попался комп с системным разделом ХР имеющим MFT с 20-м атрибутом. Хотелось избавится от расширенного списка и (сделав посекторку раздела на другой диск) пробовал это сделать с помощью нескольких дефрагментаторов. Некоторые собрали в кучу фрагменты, но расширенный атрибут не удался - подозреваю что это в WinAPI заложено так. Собрал все фрагменты до кучи, записал их на свободный участок раздела, убрал "лишний" атрибут в 0-вой записи и прописал ранлист для сборки. Очистил MFTBitmap и запустил чекдиск на исправление - всё получилось зашибись.
Тем не менее, результат этого эксперимента не был применён на реальной системе, тем более что там была ещё ХР, которая не так замудрена на безопаности в ФС. Просто скопировал всю структуру раздела на другой том, отформатировал том и вернул всё назад. [/more]
К тому же она имеет дыру в записях и результат такого восстановления сложно предсказуем, тем более что в окончании лечения используется чекдиск (!), который видно как пролечил. Учитывая упоминания неверной длины (размера) MFT и огромаднейшее число записей, возникает мысль про какое то ограничение, при превышении которого система может и взбрыкнуться. В свете этого могу пооветовать задуматься об этом вопросе. У меня тоже есть огромное количество мелких файлов, и лично для себя я нашёл решение в виде контейнера TrueCrypt. Этакая коробочка, в которой хранятся не слишком критичные файлы - и в основной файловой системе это всего одна запись, а не сотня тысяч.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354

Предыдущая тема: Проблема HDD с востновлениям информациии


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.