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

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

Модерирует : Akam1, Dr_StandBy, vertex4

Akam1 (11-10-2015 05:48): http://forum.ru-board.com/topic.cgi?forum=84&topic=5006  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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

   

Akam1



Комса
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Восстановление разделов и информации на HDD
 
первая часть :: вторая часть :: третья часть:: четвертая часть :: пятая часть :: шестая часть


Внимание! Если у Вас возникли проблемы с доступом к информации на дисках большого объема (более 120 Гб) - пропала таблица разделов, система говорит, что нужно отформатировать диск и т.п., то сначала прочитайте эту ветку про LBA48.
 
Для операций с разделами на жестких дисках по-возможности используйте штатные средства ОС. Прежде, чем править разделы с помощью Acronis Partition Expert, Norton Partition Magic и им подобных программ, пробегите быстро по всем страницам всех частей этой темы и Вы увидите, что половина проблем из-за них! Если не хотите сами наступить на эти грабли, запомните несколько простых правил:
 
- перед использованием программ типа Partition Magic всегда сохраняйте резервные копии важных данных
- не забывайте проверять диски на ошибки и дефрагментировать их (может помочь позже, при восстановлении данных)
- не пытайтесь изменять разделы на дисках с ошибками или на которых имеются сбойные блоки
- на время правки разделов постарайтесь обеспечить бесперебойную работу компьютера
- никогда не прерывайте процесс изменения разделов, если он уже начался
- не проводите операций по изменению разделов на дисках забитых до отказа, т.к. это значительно увеличивает продолжительность таких операций, а следовательно и риск возникновения сбоев
 
Прочтите и передайте другим, которые заходят сюда, когда уже слишком поздно...

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

  • Общие рекомендации по самостоятельному восстановлению данных
     
  • Хороший совет по восстановлению, когда не уверен в своих знаниях
     
  • Список программ для восстановления информации
     
  • Статьи о восстановлении данных и жестких дисках
     
  • Восстановление данных из .chk файлов
    Обращаясь в тему за помощью, обязательно укажите информацию о диске: тип, емкость, способ подключения, информацию о разделах, SMART винта из MHDD / Victoria / HDDScan, наименование и мощность БП, возраст БП, результаты MemTest86, версию ОС и сервис-пака, а также обстоятельства краха - честное слово, толковым запросам и отвечать приятно. Здесь телепатов нет...
     

    Важно! Инструкция по чистке контактов на плате HDD


  • Всего записей: 26385 | Зарегистр. 20-04-2006 | Отправлено: 08:17 04-09-2013 | Исправлено: alexgr, 19:52 07-10-2014
    9285

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 03:46 14-09-2014
    evgen1137

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

    Всего записей: 9 | Зарегистр. 05-06-2009 | Отправлено: 15:21 14-09-2014
    south_man



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

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

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

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

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

    Всего записей: 935 | Зарегистр. 06-07-2012 | Отправлено: 15:35 14-09-2014 | Исправлено: south_man, 15:36 14-09-2014
    9285

    BANNED
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    evgen1137
    Я не знаю как сейчас, но в районе 2009 года у убунты (если говорить о её встроенном "менеджере" дисков) утиль соответствовала этому слову.
    Но я не занимался её исследованием. поэтому мне сложно сказать что она могла сделать отностельно безобидной операции поджатия конца раздела. Но, судя по результату (не уверен, но чекдиск к этому не причастен), скорей всего он сделал в стиле акрониса - начала передвигать и начало раздела. Возможно на те самые 6 секторов.  если это так, то процесс очень длительный, так как надо переписать практически все данные + ещё и пересчитать MFT. Соотвественно, если на каком то отрезке произошёл сбой, то действие не завершилось полностью. И при передвижках вполне обьяснимо начальное перемещение больших файлов - ведь маленькие потом проще рассовать по дыркам.
     
    Что касается результатов Photorec, то это ка бы подтверждение того, что есть тот самый сдвиг.
    А что касается имён и структуры каталогов, то он и не делает этого, так как не работает с ФС (даже если она идеальная).
    PS. Cовет не сказать чтобы хороший, но уж точно получше "легендарного" отформатировать раздел а потом искать. Хотя тут ещё надо разбираться чем это делать. А то может прога кроме удаления ещё и что то типа вайпинга сделает. В случае еже если нечто не удаляет ничего из структур ФС, то это почти равносильно MBR off, то есть исключает возможность работы винды с разделом - которая без этих действий может его заполнять новыми записями.

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 17:37 14-09-2014
    evgen1137

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

    Всего записей: 9 | Зарегистр. 05-06-2009 | Отправлено: 19:07 14-09-2014
    Alex_Green

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

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

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

    Всего записей: 283 | Зарегистр. 21-04-2013 | Отправлено: 00:29 15-09-2014
    9285

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

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

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

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

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 02:59 15-09-2014
    evgen1137

    Newbie
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    Вообще я не понимаю, почему 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, и начал просматривать файлы. Все картинки в порядке, даже структура папок вроде бы правильная, в смысле в линейном виде в правильном порядке идут они. Но только встаёт вопрос, как всё это дело аккуратно восстановить? Чтобы не накосячить там и всё не испортить...

    Всего записей: 9 | Зарегистр. 05-06-2009 | Отправлено: 13:33 15-09-2014
    9285

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

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

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 19:33 15-09-2014
    Skif_off

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

    Всего записей: 6601 | Зарегистр. 28-01-2008 | Отправлено: 00:34 16-09-2014 | Исправлено: Skif_off, 00:35 16-09-2014
    igor_me

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

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

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

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

    Всего записей: 5716 | Зарегистр. 27-12-2011 | Отправлено: 01:18 16-09-2014
    Skif_off

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

    Всего записей: 6601 | Зарегистр. 28-01-2008 | Отправлено: 01:50 16-09-2014 | Исправлено: Skif_off, 01:50 16-09-2014
    9285

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

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

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 11:15 16-09-2014
    Alex_Green

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

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

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

    Всего записей: 283 | Зарегистр. 21-04-2013 | Отправлено: 12:53 16-09-2014
    south_man



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

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

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

    Всего записей: 935 | Зарегистр. 06-07-2012 | Отправлено: 13:42 16-09-2014
    igor_me

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

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

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

    Всего записей: 5716 | Зарегистр. 27-12-2011 | Отправлено: 14:37 16-09-2014 | Исправлено: igor_me, 14:39 16-09-2014
    9285

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 14:47 16-09-2014
    south_man



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

    Всего записей: 935 | Зарегистр. 06-07-2012 | Отправлено: 15:00 16-09-2014
    9285

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

    Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 16:07 16-09-2014
    evgen1137

    Newbie
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    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? Заранее большое спасибо за помощь

    Всего записей: 9 | Зарегистр. 05-06-2009 | Отправлено: 17:29 16-09-2014
       

    Страницы: 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

    Компьютерный форум Ru.Board » Hardware » Магнитные носители информации » Восстановление разделов и информации на HDD (часть 7)
    Akam1 (11-10-2015 05:48): http://forum.ru-board.com/topic.cgi?forum=84&topic=5006


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

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

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru